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

[Paul Eggert]

Dmitry Gutov wrote:

> This is just hand-waving. I gave you a patch, feel free to criticize it, ask to
> support different cases, etc.
I think the most recent patch you sent is in 
<http://lists.gnu.org/archive/html/emacs-devel/2015-06/msg00547.html>.  I just 
now tried it against the current master (commit 
99ad90dcb1beccde926d9b6475a393c6f8743f5c), and didn't notice any difference in 
display.  I suppose you intended the patch to be combined with reverting some 
recent changes to the master, but I don't know which changes those would be.
Also, as I understand it this part of the thread was about display of Elisp 
source code, whereas that patch seems to about display of *Help* buffers.
> You can display a wrong character with sustitute-command-keys just as well.
Yes, of course.  But in practice the effect of substitute-command-keys is 
limited to strings displayed in *Help* buffers.  This makes its misbehavior less 
likely (and when it happens, less of a problem) than a font-lock approach 
designed to display arbitrary Elisp source code.
> Like in its own docstring currently ("Each ‘ and ’ are replaced by...").
I don't see any wrong character there.  That part of the documentation is about 
curved single quotes, and that's what I see.
> With substitute-command-keys, you can't control the way the characters look
> in the source buffer (which Oleh's patch was for)

OK, in that case I agree that the font-lock approach should give more control on 
how source code is displayed, whereas substitute-command-keys does not affect 
source-code display.  I still don't see how font-lock would work with 
source-code strings containing quotes, though; I expect it will mishandle 
display in a significant number of practical cases.  (Again, this appears to be 
a different topic than the abovementioned patch, so it's not clear what's being 
proposed here.)
> > No straightforward conversion will work, I'm afraid.
> The logic can follow along the lines of the new parts in 
> substitute-command-keys.
That would be plausible if we were talking about *Help* buffer contents, 
although there's still the matter of dealing with user string contents (which 
the current master handles but the abovementioned patch seemingly would 
mishandle).  But this part of the thread was about arbitrary Elisp source-code 
strings, and the substitute-command-keys heuristics won't work there.
> I think we could use "\\", though. Or else, something like "\\=", although that
> exact sequence is already taken (substitute-command-keys would eat it).
I'm afraid I'm lost now.  I don't know what you're proposing here.  Your other 
comments suggest you're talking about escapes that can appear in any Elisp 
source-code string, but I don't know what the escapes look like or what they 
would do.
> font-lock runs in the help buffers, as well as info (if I'm not mistaken), so 
> that approach can be used in those too.
This makes it sounds like you want one font-lock solution for help buffers, 
another font-lock solution for info buffers, and a third font-lock solution for 
Elisp source-code files.  Is that the idea?  But I'm having trouble seeing what 
the three would have in common or how their combination would be documented. 
For example, for a typical user what would font-lock do for info files that is 
not already being done?
> > OK, that can be the format-message function already discussed.
> Indeed.
I'll look into implementing that then, as this issue seems separable from the 
others.