Dear All, this might be a very stupid question as I'm not familiar with the internals of the Org export engine, but couldn't this change lead to problems with the Org-to-Org export of documents containing these "semantic separators"?
thanks and best wishes, András On Tue, 26 Jul 2022 at 16:52, Timothy <orgm...@tec.tecosaur.net> wrote: > > Hi Ihor, > > > I am attaching a tentative patch that will make Org export remove > > zero-width spaces when those spaces actually separate the object > > boundaries. > > > > Any objections? > > IMO this is an immanently sensible idea. I added an export filter like this to > my config basically as soon as I found out about zero-width spaces. > > One minor quibble, I find the name mildly misleading. When you say “escaped” I > think of escaped characters, which isn’t really connected to what the zero > width > does. I’d personally be inclined to call the zero width space an “invisible > semantic separator”. > > > +(defun org-export–remove-escaped (data info) > > + “Remove escape symbols from plain-text in DATA. > > +DATA is a parse tree or a secondary string. INFO is a plist > > +containing export options. It is modified by side effect and > > +returned by the function.” > > How about: > > ┌──── > │ (defun org-export--remove-semantic-separators (data info) > │ "Remove Org-specific semantic separators from plain-text in DATA. > │ DATA is a parse tree or a secondary string. INFO is a plist > │ containing export options. It is modified by side effect and > │ returned by the function." > └──── > > All the best, > Timothy
