Re: A simple solution to "Upcoming loss of usability ..."

[Paul Eggert]

Dmitry Gutov wrote:
> On 06/26/2015 05:35 AM, Paul Eggert wrote:
> > I just now tried it against the current master (commit
> > 99ad90dcb1beccde926d9b6475a393c6f8743f5c), and didn't notice any
> > difference in display.

> Like mentioned in the preceding email, that patch is against f743819.
>
> But if you were looking for changes to revert, those would be the uses of curly
> quotes as markup in the source code, the new `substitute-command-keys' calls, as
> well as the code in `substitute-command-keys' that performs quote replacement.

In that case I don't understand the patch being against f743819.  f743819 
already has some curved quotes in docstrings, to avoid ambiguities of using 
grave accent and apostrophe to quote.  So that patch against f743819 won't 
determine whether font-lock can address this issue without using curved quotes 
in docstrings.

Even with this in mind, though, the patch mishandles some quotes.  For example, 
the docstring for texinfo-format-verb contains:

  For example, @verb\{|@|\} results in @ and
  @verb\{+@'e?`!`+} results in @'e?`!`.

The patch displays this as:

  For example, @verb{|@|} results in @ and
  @verb{+@'e?`!‘+} results in @’e?`!`.

which is incorrect: those curved quotes should be grave accent and apostrophe.

It'd be impractical to work around this sort of problem entirely with clever 
font-lock regular expressions.  We will need some escape syntax to suppress 
transliteration for exceptional docstrings like the above.  I think you've 
mentioned the need for that sort of thing, but it's not clear what it would look 
like or how it would be implemented with font-lock.

Plus, as we've mentioned, the patch can mishandle user-supplied values that 
contain grave accent and apostrophe.

> It will be very easy to limit the conversion to only within strings.

As I understand it we gave up on transliteration of Elisp source code after you 
wrote the above, so for now I'll not comment on this point (or the other points 
of the message that talk about transliterating source code).

> Is Info actually relevant in this discussion? Looking at info.el, it seems to
> deal files where quotes have already been translated
> (Info-mode-font-lock-keywords indicates that), so maybe neither
> substitute-command-keys, nor the new font-lock rules, have to do anything about
> quotes there.

It's relevant, as it uses and displays the curved quotes that some users find 
objectionable, and did so even in 24.5.  But it's fine with me if we leave Info 
mode alone.  In practice it works reasonably well in 24.5.