From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 50946@debbugs.gnu.org, joaotavora@gmail.com
Subject: bug#50946: Emacs-28: Inadequate coding in hack-elisp-shorthands
Date: Sat, 2 Oct 2021 13:57:21 +0000 [thread overview]
Message-ID: <YVhlQWYSJXniDUeC@ACM> (raw)
In-Reply-To: <83pmsnbnci.fsf@gnu.org>
Hello, Eli.
On Sat, Oct 02, 2021 at 15:52:29 +0300, Eli Zaretskii wrote:
> > Date: Sat, 2 Oct 2021 12:38:58 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, 50946@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > I think that with hack-elisp-shorthands having been coded without
> > attention to detail, there is a good chance the rest of this feature is
> > similarly lacking in attention to detail, which is why I asked for an
> > independent person to check. Eli seems to think this isn't a problem.
> If you want me to take your critique seriously, please be specific:
> what are the aspects of that function that you think lack attention to
> detail, and what detail?
The five aspects I enumerated on my original bug report. Not checking
for a properly formatted Local Variables: section, not checking for
lower-case in that variable being searched for, not going back at least
3000 characters, etc. Additionally, the original code didn't check for
a page boundary.
That, to me, is detail that should have been checked, even tested, but
clearly wasn't.
> We _are_ having a technical discussion of a Lisp program, and quite a
> short one at that, right? If so, it shouldn't be hard for you to
> provide the details of what worries you there.
I think I did that in the original bug report. I also stated in detail
in one of the followups why the patch the João committed didn't entirely
fix the bug. It took me quite a bit of time to put that followup
together.
There were 6 individual bugs in hack-elisp-shorthands (the five in my
original bug report plus not checking for a page boundary). They
weren't difficult complicated things, they were things obvious to me
just perusing the code. They ought to have been obvious to João, too.
This was unusually bad coding. There's been no (public) explanation for
this from João, though I suggested one to him.
What worries me is that this lack of attention to detail might extend to
the new code in lread.c, or the documentation page. I still think
somebody who isn't João and isn't me should check this. I think I saw
you making a small amendment to the code in lread.c, so maybe you have
already checked that bit.
I worry, to a lesser degree, it is not entirely clear whether setting
the elisp-shorthands variable in the first line of a short file should
be valid or not. I don't think the current hack-elisp-shorthands is
careful enough about this.
> And while at that, please try to distinguish between general problems
> of hack-local-variables--find-variables, which affect all of Emacs,
> and hack-elisp-shorthands, which is specific to this feature.
I think all the things I've said in this bug report are about
hack-elisp-shorthands and the other new code/doc in this feature.
> > You haven't fixed this bug. When you first closed it this afternoon, I
> > assumed you did so by accident, since the -done@debbugs.gnu.org was on
> > the Cc:. Your recent closing of this unfixed bug was clearly
> > deliberate.
> Which bug (or bugs) is that?
Bug #50946. I have pointed out unfixed edge cases in this thread.
> > I'm not going to get into a childish game with you, opening and closing
> > this bug repeatedly. Instead, I invite you to calm down, think it over
> > over the next few days, and consider whether such unfixed bugs are
> > really the right thing for Emacs.
> I don't think you are calm enough, either.
I'm not. When I submit a bug report, I expect it and me to be treated
with respect. That hasn't happened in this case.
> So the invitation to calm down goes both ways here. Please focus on
> technical issues and leave ad-hominem out of this, okay?
Is this bug to be fixed completely, or are the edge cases just to be
ignored as unimportant? That is the current technical issue as I see
it. I really don't want to fix the bug myself, but am prepared to do so
if nobody else is. If you think the bug indeed needs completely fixing,
please reopen it - there's no point in me trying to reopen it again. If
you don't, just leave things the way they are.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2021-10-02 13:57 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 17:10 bug#50946: Emacs-28: Inadequate coding in hack-elisp-shorthands Alan Mackenzie
2021-10-01 17:53 ` Eli Zaretskii
2021-10-01 21:15 ` João Távora
2021-10-02 6:10 ` Eli Zaretskii
2021-10-02 0:48 ` João Távora
2021-10-02 10:50 ` Alan Mackenzie
2021-10-02 11:13 ` João Távora
2021-10-02 11:38 ` João Távora
2021-10-02 12:38 ` Alan Mackenzie
2021-10-02 12:52 ` Eli Zaretskii
2021-10-02 13:57 ` Alan Mackenzie [this message]
2021-10-02 14:19 ` Eli Zaretskii
2021-10-02 14:45 ` Alan Mackenzie
2021-10-02 15:00 ` Eli Zaretskii
2021-10-02 20:07 ` Alan Mackenzie
2021-10-03 11:45 ` Eli Zaretskii
2021-10-03 12:10 ` bug#50946: insert-file-contents can corrupt buffers. [Was: bug#50946: Emacs-28: Inadequate coding in hack-elisp-shorthands] Alan Mackenzie
2021-10-03 12:40 ` Eli Zaretskii
2021-10-03 13:33 ` Alan Mackenzie
2021-10-03 15:04 ` bug#50946: insert-file-contents can corrupt buffers Alan Mackenzie
2021-10-03 15:25 ` Eli Zaretskii
2021-10-03 17:21 ` Alan Mackenzie
2021-10-03 17:36 ` Eli Zaretskii
2021-10-03 18:19 ` Alan Mackenzie
2021-10-03 15:34 ` bug#50946: insert-file-contents can corrupt buffers. [Was: bug#50946: Emacs-28: Inadequate coding in hack-elisp-shorthands] João Távora
2021-10-03 15:42 ` João Távora
2021-10-03 15:56 ` Eli Zaretskii
2021-10-03 16:02 ` João Távora
2021-10-03 16:20 ` Eli Zaretskii
2021-10-03 17:05 ` João Távora
2021-10-03 17:56 ` Eli Zaretskii
2021-10-03 18:59 ` João Távora
2021-10-03 19:51 ` Eli Zaretskii
2021-10-03 19:59 ` João Távora
2021-10-02 15:02 ` bug#50946: Emacs-28: Inadequate coding in hack-elisp-shorthands João Távora
2021-10-04 0:14 ` Richard Stallman
2021-10-02 14:47 ` João Távora
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=YVhlQWYSJXniDUeC@ACM \
--to=acm@muc.de \
--cc=50946@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=joaotavora@gmail.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).