bug#30217: Ambiguity in NEWS in emacs-26.0.91

[Noam Postavsky <npostavs@users.sourceforge.net>]

On Tue, Jan 23, 2018 at 10:53 AM, Drew Adams <drew.adams@oracle.com> wrote:

> An Emacs-Lisp file can contain pretty much anything,
> including lots of natural-language text.  Are we now
> issuing warnings even for "smart quotes" in comments
> and strings?

Errors will be issued, but only for those occurring at the beginning of
a symbol.  String and comment contents will remain unaffected.

>>   it produces an obscure error message.
>>
>> The Emacs 25 error for the expression in question is
>>   (wrong-number-of-arguments setq 31)
>
> Which tells you pretty much that setq is missing an
> argument or has too many, which makes you look at its
> arguments.  Not so obscure.  And accurate.

And yet, Alan said

    This has wasted a lot of time identifying the problem, and
    fruitlessly searching for a solution in the Emacs and Elisp manuals,
    etc.

So maybe it's accurate in a narrow technical sense, but not in a
practically useful one.

> (setq ’bar 42)
> (setq foo ’bar)
>
> That's perfectly fine Lisp, even if it might not be
> what some might expect.  But now, after your "fix",
> the first sexp raises an error - at read time, no less.

Yes, that code no longer works, you would have to write

(setq \’bar 42)
(setq foo \’bar)

I don't consider this a big loss.  As far as I can see, this will just
make it harder to write obfuscated lisp code (although there will remain
plenty of other ways to obfuscate lisp code).

>  And this still raises no error:
> (setq a’bar 42).

Yes, it would be more difficult implementation-wise to catch that case,
and it seems much less likely to come up in practice.

> Aside from the error/warning, such _escaping_ is another
> bad idea.  It too subtracts from Lisp (while adding
> nonsense to it).

Nothing about escaping has changed.

> IMHO, this "fix" - all of its parts - should be reverted
[...]
> To be clear, though, I'm in favor of neither of those
[...]
> To be really clear, the fix proposed should be removed.

Thanks for trying to be clear, but repeating yourself like this just
makes your message longer, and therefore harder to comprehend.

I would really appreciate it if you would write shorter and more focused
messages, with less emotional rhetoric.  Keep the "emotional
temperature" low (see https://freenode.net/changuide, which is about
IRC, but the same principles apply to email conversations).

>> Maybe everything in the "Unicode confusables" listing?  Practically
>> speaking, I've never heard of problems with other characters, except
>> perhaps in programming "puzzles", obfuscated code contents and the like.
>
> There are lots of chars that can be confused, especially
> given the possibility of different fonts.  I didn't even
> mention other variants of brackets (aka square brackets),
> braces (aka curly brackets), angle brackets, etc.
>
> Would you try to protect a user from the confusion of
> copy+pasting FULLWIDTH LEFT CURLY BRACKET FF5B｛ in place
> of LEFT CURLY BRACKET 7B { in a doc string ("... \\{...}")
> or in a regexp?  Or of using LEFT WHITE SQUARE BRACKET
> 301A 〚 in place of [ in a vector?

I don't plan to spend any effort towards that, no, although I wouldn't
necessarily be opposed to it.