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

[Dmitry Gutov]

On 06/26/2015 05:35 AM, Paul Eggert wrote:

> 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.

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.

The "differences is display" is the wrong thing to look for, though, 
because the intent is to reproduce the current behavior, more or less.

> 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.

The patches can be very similar. In the source code, we'll not hide the 
escape sequences; that should be the main difference.

> 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.

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

> I don't see any wrong character there.  That part of the documentation
> is about curved single quotes, and that's what I see.

Hmm, okay. Guess I misread it.

> (Again, this appears to be a different topic than the abovementioned
> patch, so it's not clear what's being proposed here.)

Why don't we start with the help-mode patch (maybe even in the thread 
it's been posted to), and then return to the source buffers later.

The issue of curly quotes in Help and Info buffers seems to be the more 
important one.

> 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 the only heuristic we won't be able to reproduce is the fact 
that one can intentionally pass only some strings to 
`substitute-command-keys', but not the others.

Depending on the number of false positives created this way, we may or 
may not decide to turn the quote translation in the source buffer off by 
default.

Or else, decide we prefer to have false negatives and only translate 
quotes in strings that are in known docstring positions (like within a 
top-level `defun' form, after the arguments).

> 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.

"`'" will render as "‘’" in the Help buffer and the source buffer (if 
the quote translation is turned on).

"\\`\\'" will render as "`'" in the Help buffer and "\\`\\'" in the 
source buffer.

Looking at it now, these would generate quite a few false positives in 
regexps (if we don't eliminate this possibility in a different way). So 
we could use "\\~", for example ("\\~`" -> "`").

Or else, make the quote characters escape themselves.

Then, "``" would render as "`" in the Help buffer, and "''" as "'".

"```'''" would translate to "`‘'’", though.

> 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?

They Help and Elisp buffers can share the conversion function (with one 
or two modifier arguments), as well as the search regexp. The font-lock 
rule would have to be set in several places, that is correct.

> But
> I'm having trouble seeing what the three would have in common or how
> their combination would be documented.

What will need to be documented is the quoting syntax, as well as the 
escaping rules.

> For example, for a typical user
> what would font-lock do for info files that is not already being done?

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.

But if we were discussing the texinfo-mode buffers, then handling of 
quotes would be similar to Emacs Lisp source buffers (but necessarily 
different, because of different syntax).