From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#50946: Emacs-28: Inadequate coding in hack-elisp-shorthands Date: Sat, 2 Oct 2021 14:45:52 +0000 Message-ID: References: <831r54einq.fsf@gnu.org> <871r54xnds.fsf@gmail.com> <87ee933bcj.fsf@gmail.com> <83pmsnbnci.fsf@gnu.org> <83k0ivbjbu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1893"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50946@debbugs.gnu.org, joaotavora@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 02 16:46:15 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mWgHG-0000HG-R7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Oct 2021 16:46:14 +0200 Original-Received: from localhost ([::1]:50516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWgHF-0007wb-IV for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Oct 2021 10:46:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWgH4-0007su-44 for bug-gnu-emacs@gnu.org; Sat, 02 Oct 2021 10:46:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mWgH3-0007QW-RX for bug-gnu-emacs@gnu.org; Sat, 02 Oct 2021 10:46:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mWgH3-000519-PG for bug-gnu-emacs@gnu.org; Sat, 02 Oct 2021 10:46:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Oct 2021 14:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50946 X-GNU-PR-Package: emacs Original-Received: via spool by 50946-submit@debbugs.gnu.org id=B50946.163318596119278 (code B ref 50946); Sat, 02 Oct 2021 14:46:01 +0000 Original-Received: (at 50946) by debbugs.gnu.org; 2 Oct 2021 14:46:01 +0000 Original-Received: from localhost ([127.0.0.1]:60200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWgH2-00050s-Hv for submit@debbugs.gnu.org; Sat, 02 Oct 2021 10:46:00 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:43776 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mWgH1-00050e-9S for 50946@debbugs.gnu.org; Sat, 02 Oct 2021 10:46:00 -0400 Original-Received: (qmail 46114 invoked by uid 3782); 2 Oct 2021 14:45:53 -0000 Original-Received: from acm.muc.de (p4fe15ae2.dip0.t-ipconnect.de [79.225.90.226]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 02 Oct 2021 16:45:52 +0200 Original-Received: (qmail 14401 invoked by uid 1000); 2 Oct 2021 14:45:52 -0000 Content-Disposition: inline In-Reply-To: <83k0ivbjbu.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:216161 Archived-At: Hello, Eli. On Sat, Oct 02, 2021 at 17:19:17 +0300, Eli Zaretskii wrote: > > Date: Sat, 2 Oct 2021 13:57:21 +0000 > > Cc: joaotavora@gmail.com, 50946@debbugs.gnu.org > > From: Alan Mackenzie > > > 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. It is now. It wasn't when I raised the bug a day or two ago. > > not checking for lower-case in that variable being searched for > That's also in hack-local-variables--find-variables, right? It is now. It wasn't when I raised the bug > > not going back at least 3000 characters > That is now fixed, right? No, it's not. In certain edge cases, it will go back fewer than 3000 characters. > > Additionally, the original code didn't check for a page boundary. > No longer relevant, right? No longer relevant. > > 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. In other words, I should do the review myself, you mean? I really don't want to do this. I am not at all enthusiastic about the shorthands feature and think somebody with more enthusiasm should do it. > > I still think somebody who isn't Joćo and isn't me should check > > this. > I did that when reviewing the commit. Ah, good! Thanks! > > 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? Because the first line definition should either be valid or not valid. Currently it works for a sufficiently small file, but not for a normal sized file. This, I think, is a bug. > > > 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. I've largely been talking about the version of hack-elisp-shorthands I raised the bug on. > > > 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? I documented those carefully in my post to this thread this morning. Here are some excerpts from that: ######################################################################### Say you have a file 3150 bytes long, which is less than 3000 characters in Emacs. Your function will load only 3100 bytes, less than 3000 characters, into the temporary buffer. It thus may fail to find a Local Variables section, even if this scenario is highly unusual. Have you checked that things work if the first byte in your temporary buffer isn't at the start of a character? Also, it is unclear whether the elisp-shorthands symbol on the first line of a file is valid. I think the intention is that it not be valid. However, the current version of the code will read it from the first line of a sufficiently small file. You should look at this. Possibly this needs to be clarified in the documentation for shorthands. ######################################################################### -- Alan Mackenzie (Nuremberg, Germany).