bug#29812: 27.0.50; electric-quote-replace-double misbehaves in Lisp strings

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am So., 31. Dez. 2017 um 16:51 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 30 Dec 2017 22:07:16 +0000
> > Cc: 29812@debbugs.gnu.org
> >
> >    emacs -Q
> >    M-x electric-quote-mode RET
> >    M-x set-variable RET electric-quote-replace-double RET t RET
> >
> >  Type:
> >
> >    "foo \"foo\""
> >
> >  You get this in the buffer:
> >
> >    "foo \”foo\”"
> >
> >  I expected "foo \“foo\”" instead.
> >
> > I think it's not completely clear what to expect here. After all,
> electric quote is for human-language text, which
> > normally doesn't contain backslashes.
>
> AFAIK, electric-quote-replace-double is supposed to work in comments
> and strings in buffers under programming language modes, not only in
> text modes.  And it works correctly for me in C modes and also in Lisp
> comments, so why not in Lisp strings?
>

Does it work as expected for you in C strings? I see the same behavior in C
strings as in Lisp.


>
> > At least in the context of Emacs Lisp strings, I'd expect "foo \"foo\""
> here, i.e., ASCII quotes. The non-ASCII
> > quotes don't need to be escaped, so presumably escaping means that the
> user intended to type an ASCII
> > quote.
>
> Typing just a quote in a Lisp string terminates the string, so I
> wouldn't expect that to produce curved quotes.  And a backslash just
> quotes the next character, so there's nothing wrong with having it
> before curved quotes.
>

True, but why would you quote a character that doesn't need quoting? Doing
so could be taken as a hint that the character doesn't need quoting.


>
> Anyway, if this feature is not supposed to work reliably in
> programming language strings, perhaps we shouldn't try?  Having it
> sometimes work and sometimes not is IMO confusing.
>

It should work in comments and strings, yes. However, given that the
behavior is heuristic in all cases it's hard to define what the correct
behavior should be.
It seems that the behavior you expect should be relatively easy to
implement, though. I'll try to send a patch.

[-- Attachment #2: Type: text/html, Size: 3075 bytes --]