GNU bug report logs - #50946
Emacs-28: Inadequate coding in hack-elisp-shorthands

Previous Next

Full log

Message #52 received at 50946 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 50946 <at> debbugs.gnu.org, joaotavora <at> gmail.com
Subject: Re: bug#50946: Emacs-28: Inadequate coding in hack-elisp-shorthands
Date: Sat, 02 Oct 2021 17:19:17 +0300

> Date: Sat, 2 Oct 2021 13:57:21 +0000
> Cc: joaotavora <at> gmail.com, 50946 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > 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

That is not part of the function in question, is it?  It's in
hack-local-variables--find-variables, which we use everywhere.

> not checking for lower-case in that variable being searched for

That's also in hack-local-variables--find-variables, right?

> not going back at least 3000 characters

That is now fixed, right?

> Additionally, the original code didn't check for a page boundary.

No longer relevant, right?

> What worries me is that this lack of attention to detail might extend to
> the new code in lread.c, or the documentation page.

You are welcome to point out specific issues with that.

> I still think somebody who isn't João and isn't me should check
> this.

I did that when reviewing the commit.

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

Why does it matter?

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

See above: I don't think I agree.

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

Please forget what happened before, and let's pick up from the above
points I mention.  What else needs to be fixed in shorthands.el, and
why?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.