Patch v4 (4b40a28d) of org-protocol.org rewrite. > I have noticed that some lines added by your patch have trailing white space > characters. "git show" (or "git diff") in console highlights them. > Some sections have multiple blank lines at the end.
Ran `whitespace-cleanup’ and audited document for multiple line spaces. > > I like "<<-EOF" shell feature for here-docs that allows to keep text block > indented, but I do not consider zero indent in elisp strings as a really > annoying issue. It is unclear to me what are complications with debugging. Do > you mean that `string-join' allows to comment out specific lines by > prepending them with ";"? I do find zero indent strings to be annoying for readability, particularly as this is used for a template. Also because this string is a template, I find it annoying to audit embedded ‘\n’ characters. I find that breaking it up into string fragments that can be joined together makes it more comprehensible and maintainable. As a side note, this practice was influenced by DOCT (https://github.com/progfolio/doct) which allows for specification of a list for a template. All that said, Max, are your concerns a block? > >> #+HTML_HEAD_EXTRA: </script> >> +# #+HTML_HEAD: <link rel="stylesheet" href="../style/worg.css"> >> #+HTML_LINK_UP: index.html > > The added line is commented out. That commented insertion was for locally debugging an exported HTML document that would include the worg.css file. I do not know otherwise how to export WORG so that the TOC is turned into a menu. That said, I’ve removed that line. > > You changed verbatim markup to code. Strictly speaking, "store-link" is not > code, so =store-link= should be a bit better. Changed/reverted, although I think it is subject to interpretation what “code” is here with respect to protocol names. > > "nee"? Definition: originally or formerly called. https://www.merriam-webster.com/dictionary/n%C3%A9e > > Warning here is a bit long here to my taste, have you considered "blindtext" > instead? An alternative may be a brief warning like "The following text in > this section applies to macOS versions prior to Ventura" and normal text > below. Changed to blindtext. > I am confused by "selected text" here. On the other hand all fields including > body are described in the table a bit below. > Amended to “Body”. > > I had in mind > > | Protocol | Old style | New style > | > |--------------+---------------------------------------+--------------------------------------------------------| > | =store-link= | =org-protocol:/store-link:/URL/TITLE= | > =org-protocol://store-link?url=URL&title=TITLE= | > | =capture= | =org-protocol:/capture:/URL/TITLE= | > =org-protocol://capture?url=URL&title=TITLE&body=BODY= | > > Do you expect issues with too wide table on narrow smartphone screens? I first tried to show old and new styles side-by-side in a table, however the browser layout engine would break hyphens into multiple lines even for desktop much less mobile due to page width constraints designed in by WORG’s CSS usage. I think this makes it less readable than showing old and new on top of each other. > >> *** Obsolete Protocols >> The ~remember~ protocol is /obsolete/. Users should migrate any >> configuration relying on it to the ~capture~ protocol. > > From my point of view *obsolete* should be still available while "remember" > has been completely *removed*. Changed to use “removed” instead of obsolete. My conventional (and arguably dated) understanding of obsolete and deprecated is reflected in this MDN document (https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Experimental_deprecated_obsolete) where “obsolete” meant unsupported and “deprecated” meant no longer recommended. That said, given the ambiguity of “obsolete”, have made this change. > I find the following fragments at the end of sections for specific OSes > almost identical > I would consider moving a single instance to the common part. A remark on > macOS should not be annoying or distracting for Linux and Windows users. Those sections have been consolidated into the common section.
0001-org-protocol.org-Rewrite-for-2025.patch
Description: Binary data
— Charles Y. Choi, Ph.D. kickingve...@gmail.com
