unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Noam Postavsky <npostavs@users.sourceforge.net>
To: Drew Adams <drew.adams@oracle.com>
Cc: Alan Mackenzie <acm@muc.de>, 30217@debbugs.gnu.org
Subject: bug#30217: Ambiguity in NEWS in emacs-26.0.91
Date: Tue, 23 Jan 2018 07:54:34 -0500	[thread overview]
Message-ID: <871sigohv9.fsf@users.sourceforge.net> (raw)
In-Reply-To: <132fe701-a996-4708-bf39-4ee95230b8fa@default> (Drew Adams's message of "Mon, 22 Jan 2018 22:07:18 -0800 (PST)")

Drew Adams <drew.adams@oracle.com> writes:

>> To give a less confusing error in cases like Bug#2967 and Bug#23425.
>
> Seriously?  This is an absolutely horrible "fix" for each
> of those problems.  This "cure" is worse than either of
> those diseases, and as we all know, I think such diseases
> are pretty awful.
>
> The error message seems to be _super_ confusing.  It gives
> no indication of problems such as those bugs, and it does
> not begin to enlighten anyone about the confusion at their
> heart.

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.  The OP of Bug#23425 says

    When this output is fed back into Emacs with M-:, it produces an obscure
    error message.

The Emacs 25 error for the expression in question is

    (wrong-number-of-arguments setq 31)

In Emacs 26.0.91, it is

    (invalid-read-syntax "strange quote" "’")

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

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

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

> to make clear just what confusion it is meant to address: say that the
> character is not an ascii apostrophe or whatever, if that confusion is
> the real problem this is trying to solve.

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.

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

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






  parent reply	other threads:[~2018-01-23 12:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22 22:17 bug#30217: Ambiguity in NEWS in emacs-26.0.91 Alan Mackenzie
2018-01-22 22:42 ` Drew Adams
2018-01-23  0:42   ` Noam Postavsky
2018-01-23  0:56     ` Drew Adams
2018-01-23  1:40       ` Noam Postavsky
2018-01-23  6:07         ` Drew Adams
2018-01-23  6:21           ` Drew Adams
2018-01-23 12:54           ` Noam Postavsky [this message]
2018-01-23 15:53             ` Drew Adams
2018-01-23 23:00               ` Noam Postavsky
2018-01-23 23:19                 ` Drew Adams
2018-01-24  0:02                   ` Noam Postavsky
2018-01-28 15:52                     ` Noam Postavsky
2018-02-02 18:52                       ` Drew Adams
2018-02-02 19:08                         ` Noam Postavsky
2018-02-02 21:37                           ` Drew Adams
2018-02-02 22:14                             ` Ista Zahn
2018-02-02 22:35                               ` Noam Postavsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871sigohv9.fsf@users.sourceforge.net \
    --to=npostavs@users.sourceforge.net \
    --cc=30217@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).