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

["João Távora" <joaotavora@gmail.com>]

Eli,

You can reopen this bug if you want.  Eventually, hack-elisp-shorthands will
go into load-with-code-conversion or something just before it evaluates the
buffer (and thus calls 'read').  I just didn't do it yet because this is really
the most puny of issues right now, IMO.  Stefan is also thinking that l-w-c-c
needs to be updated regarding the lexical-binding local variable, too.
And doing that will also enable shorthands to be configured in other parts
of the buffer, not just the end section.

João

On Sat, Oct 2, 2021 at 3:19 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Sat, 2 Oct 2021 13:57:21 +0000
> > Cc: joaotavora@gmail.com, 50946@debbugs.gnu.org
> > From: Alan Mackenzie <acm@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?



-- 
João Távora