[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: A simple solution to "Upcoming loss of usability ..."
Date: Thu, 25 Jun 2015 19:35:42 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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 

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.


I'll look into implementing that then, as this issue seems separable from the others.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]