bug#30217: Ambiguity in NEWS in emacs-26.0.91

[Drew Adams <drew.adams@oracle.com>]

> The OP of Bug#2967 says
>     I think it would be good if emacs looked for smart
>     quotes in .emacs files and gave a warning or notice
>     if it detected them. This would help troubleshooting.
>     Which is exactly what's being done now.

It's not necessarily appropriate to satisfy every
suggestion offered in every bug report. ;-)

I'm not sure such a warning is good, rather than bad.
I think not.  If a warning was printed for each "smart
quote" occurrence in a file that would surely be bad,
IMO.

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?  That would definitely be a mistake.

In any case, I don't care much about byte-compiler
warnings - they are not the problem I responded to.
They can be ignored when they are not particularly
relevant.  The fact that they can sometimes represent
noise is at most an annoyance, not a real problem.

> The OP of Bug#23425 says
>   When this output is fed back into Emacs with M-:,

That represents pilot error, no doubt.

For `M-:' we _might_ try to provide an error message
that says you included a "smart quote" and say you
might want to check that that's what you intended.

I'm not suggesting we do that - I prefer not.  But
it's conceivable, if someone is really gung ho about
solving the purported problem.

I doubt that would be a good idea even for `M-:'.
But it would surely not be appropriate for other
contexts.

And even for `M-:' it's not obvious that we would
come up with a good test for the cases where it
would be helpful rather than confusing.

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

> In Emacs 26.0.91, it is
>   (invalid-read-syntax "strange quote" "’")

Which is completely obscure, IMO.  Invalid read
syntax when reading what?  What's invalid about it?

In fact, it is not invalid.  It has never been invalid,
and it shouldn't suddenly be considered invalid now.

Confusion, not understanding an accurate error msg,
is not the same thing as Lisp itself having a bug
because such a character is included in a symbol.

> I think this is an improvement, since it does, in fact,
> indicate there is a problematic use of ’.

There is NOT any problematic use of ’ there.  The
user's understanding might be problematic, but that
read syntax is not problematic for Lisp.

Help users if we can, but don't screw Lisp in the
process.

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

This is just wrong, IMO.  You've redefined Lisp
evaluation, taking away some of the importance of
symbols.  And this still raises no error:
(setq a’bar 42).

> Why do you think the signalling an error in this case
> is a bad idea?

Because it is.  Ms Lisp all her users are being
treated unfairly.  See above, and see my previous msg.

’bar is a fine symbol.  ’ has NO special meaning in
Lisp - it is NOT like ' or ` or ( or ) or . or , or @.

Now you've given it a special meaning: when in a
context where ' is special, raise an error because
it is not '.

That's plain wrong and confusing, and it subtracts
from Lisp (while adding nonsense to it).

> > If no one has a real fix for such bugs yet then please just
> > leave them open until someone comes up with a good idea.
> > This "fix" is not a good idea - for those bugs at least.
> >
> > If this fix has some other purpose, then let's please
> > know what that is and talk about it.
> >
> > But if such problems are the only reason for this "fix"
> > then please consider getting rid of such silly and useless
> > escaping and just change the error message
> 
> I don't quite understand what you mean by "getting rid of... escaping"
> but keeping the error message.  It sounds like a you are contradicting
> yourself.

I didn't say keep the error msg.  I said that if you
really think that some warning or error msg is important
here then fine.  But then improve the msg.

But I do NOT think that an error msg or warning is good
here.  A warning maybe, but not an error, which prevents
evaluation.  (But I doubt that warnings can be used here
accurately and without sowing ever more confusion.) 

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

IMHO, this "fix" - all of its parts - should be reverted
ASAP.  If you want to add some better error messaging
where we already raise an error, and if we can really
distinguish the cases where the better messaging should
be used, fine.  And if you want to add some warnings,
and if we can really distinguish the cases where the
warnings would be appropriate - accurately, fine.

To be clear, though, I'm in favor of neither of those
things.  Just leave it alone.  Using (mistakenly or
purposefully) such characters in symbol names is just
another potential gotcha.

There are plenty of them.  Users need to learn, e.g.,
that . is a symbol-constituent char in Lisp - so you
can have a symbol `a.b'.  And (a.b) is not the same
as (a . b).  Will you start requiring users to escape
the . in the symbol `a.b'?

To be really clear, the fix proposed should be removed.
Such characters, even if perhaps sometimes confusing
to some users, are legitimate symbol characters.  They
should just be left alone.  At _most_, and only if the
analysis were super-accurate and crystal clear, we
could consider adding warnings here or there.  We must
certainly not change Lisp here - no error-raising.

Starting to special-case such characters will get us
in a world of trouble - mark my words.

And as I said, there's no limit to the supply of such
chars.

> Changing the error message is always possible, of course.  I'm not sure
> if bringing "ascii" into it would make things clearer though.  Concrete
> suggestions welcome.

See above.  Please drop this attempted "fix" altogether.
It's just misguided, IMO.

At most, if you are persuaded that something needs to be
done about such "bugs" (warning pilots about such possible
pilot error) then please bring it up in emacs-devel.  You
are modifying Lisp itself in a basic way.  This should be
a no-no.

> > And besides - where do you stop doing this kind of thing?
> >
> > Do we do something similar for characters that can
> > be mistaken for a period, in case you use one in an
> > attempt at dotted-pair syntax?
> >
> > Do we do something similar for chars that can be
> > mistaken for a comma, inside backquoted sexps?
> >
> > Do we do something similar for chars that can be
> > mistaken for a backquote?  An at-sign?  Ordinary
> > parentheses?
> 
> 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?

Lisp is simple - and its use can be complicated.  You are
complicating Lisp itself immensely here.  Will you provide
fancy analysis for all of the possible contexts where such
char confusion could arise?

This is a big mistake - a crack in the foundation, IMO,
even if you think of it now only as helping a user with
a copy+paste error (pilot error).

> > I really hope you reconsider this.  To me it looks
> > like an ugly hack that can bring only harm (including
> > more, not less, confusion), not good.
> 
> Do you have any specific harms/confusion in mind?

See above.

This is *harmful* for our nice, clean Lisp - and YAGNI.