[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: Dmitry Gutov
Subject: Re: A simple solution to "Upcoming loss of usability ..."
Date: Fri, 26 Jun 2015 15:06:21 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

I think the most recent patch you sent is in
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*

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.

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

reply via email to

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