emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] master c4151eb: Improve the optional translation of qu


From: Dmitry Gutov
Subject: Re: [Emacs-diffs] master c4151eb: Improve the optional translation of quotes
Date: Thu, 25 Jun 2015 15:52:35 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 06/24/2015 08:24 AM, Paul Eggert wrote:

As I mentioned earlier I never fully understood the font-lock proposal.
I could not easily decipher most of the abovementioned message.

Asking questions might help. I can't help but feel frustrated that you haven't made an informed decision. See the bottom of this email for the patch against f743819 (which was the version in master at the time). It only adds one line, the one I've mentioned in that message.

I'm not sure what more to explain, but the undesirable effect you've seen was due to http://www.gnu.org/software/emacs/manual/html_node/elisp/Syntactic-Font-Lock.html

Luckily, though, the abovementioned message briefly mentioned not using
font-locking and said of it "...but indeed, this approach could be the
simpler one." -- an assessmeent that seemed sound to me -- and so I took
the simpler approach.

I did say that, tentatively, and I've changed my mind since.

- Using font-lock will allow to change the output significantly in the future, without breaking the substitute-command-keys API.

- This functionality is closely related to linkification of identifiers between the quotes, also performed in Lisp (see the usages of help-xref-symbol-regexp). If substitute-command-keys handles escapes, help-xref-symbol-regexp (and the function using it) don't know whether a given quote was escaped or not). Especially if the source file can contain curly quotes, and substitute-command-keys also translates into them.

- "too tempting to implement complicated heuristics that would have been a pain to document" is not a good argument not to do something in a high-level language.

Now, there are still problems with that patch:

- It doesn't handle escaping either. Someone just needs to pick the escaping syntax, and we can handle it in Lisp just as well as in C. Why did we decide that "\\" isn't good enough?

- Like you said: "describe-variable should curve the quotes in the doc string, but not in the contents of the variable". The code that prints the value will need to add some text property to it ("verbatim"? "font-lock-ignore"?), and the font-lock rule can look it up and skip those regions. Nothing too hard.




reply via email to

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