GNU bug report logs - #67523
check-declare doesn't account for shorthands

Previous Next

Package: emacs;

Reported by: Joseph Turner <joseph <at> ushin.org>

Date: Wed, 29 Nov 2023 09:13:02 UTC

Severity: wishlist

Full log


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

From: João Távora <joaotavora <at> gmail.com>
To: Joseph Turner <joseph <at> ushin.org>
Cc: 67523 <at> debbugs.gnu.org, Adam Porter <adam <at> alphapapa.net>,
 Jonas Bernoulli <jonas <at> bernoul.li>
Subject: Re: bug#67523: check-declare doesn't account for shorthands
Date: Wed, 29 Nov 2023 09:56:32 +0000
On Wed, Nov 29, 2023 at 9:12 AM Joseph Turner <joseph <at> ushin.org> wrote:

> A potential solution could be to convert the longhand symbol into its
> shorthand form and pass that into re-search-forward.  This is tricky
> since there may be multiple different shorthands which could yield the
> same longhand form.  It might be more feasible to run re-search-forward
> on a known common suffix portion of the symbol name, then with point on
> the suspected definition, run `intern-soft' to get the full symbol name.

No, this is brittle.  Check-declare, if it's to be useful (is it?)
is probably meant to be as precise as possible.

> A workaround is to not use shorthands in function definitions.

That's letting the bad guys win :-)

> Thoughts?

As usual, my thoughts are that tools that read Lisp code
should use the Lisp reader, not regular expressions.

Here, check-declare should just walk the whole file.
When it finds a a symbol atom that matches a definition
form,  look in the next atom and check if it matches the probe.
If you don't want to intern all the symbols in the you can read
to a separate obarray I think.

João




This bug report was last modified 1 year and 175 days ago.

Previous Next


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