emacs-devel
[Top][All Lists]
Advanced

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

Re: Escaping quotes in docstrings, Was: A simple solution to "Upcoming l


From: Dmitry Gutov
Subject: Re: Escaping quotes in docstrings, Was: A simple solution to "Upcoming loss of usability ..."
Date: Sun, 2 Aug 2015 15:51:33 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

On 08/02/2015 09:56 AM, Paul Eggert wrote:

Yes, and one can come up with other contrived examples that fail even
without putting curved quotes into the name.  Elisp function names can
contain any character: apostrophe, grave accent, newline, parenthesis,
space, etc., and I'm sure many of these other special characters also
cause problems in help buffers.

But we have an escaping syntax! Yet, Elisp doesn't know what's escaped and what isn't, so even this won't help:

(defun ’‘ (a b c)
 "It's called `\\=’\\=‘'."
  (+ 1 2 3))

While it might be worthwhile to fix this, it's an independent issue.  If
it is fixed, I expect you're right that substitute-command-keys will
need to be teased apart;

It's also a matter of readability. Take the latest related commit that you pushed. Sometime later, someone will come along and wonder: why do we need to substitute command keys in widget options? Who would put keys in there?

this is not just because of curved quotes, but
also because its other substitutions can generate characters that also
need special treatment.

You might want to give an example. But in general, those characters also could have `escaped' put on them. Or `substituted', for instance.

If someone wants to take on that task, that's
great, so long as it doesn't get in the way of ordinary use of *Help*
buffers.

As long as that task involves rearranging C code, you're excluding a significant portion of Emacs developers from contributing, myself included.

In particular, users should be able to type ‘C-h f length
RET’, see this in a *Help* buffer:

   To get the number of bytes, use ‘string-bytes’.

and if they save and later yank this text into a source-code buffer they
should get what they see, not a bowdlerized version with ASCII
approximations.

First, it's an arbitrary condition that you've set yourself, and we've discussed it already. If you asked all Emacs users, I suspect the majority won't care, and the rest won't reach a unanimous decision. Personally, I'd prefer that ‘string-bytes’, after copying and pasting to a "normal" buffer, turned into the original markup, which, in this case, is `string-bytes'. But that seems non-trivial to implement.

Second, as long as font-lock isn't used for translation (and we've pretty much agreed that it won't), why wouldn't a Lisp solution work like you describe?



reply via email to

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