unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: 45443@debbugs.gnu.org
Cc: rms@gnu.org, mardani29@yahoo.es
Subject: bug#45443: 28.0.50; Can't find definition of compilation--message->loc
Date: Sun, 27 Dec 2020 19:40:47 +0000	[thread overview]
Message-ID: <xjfmtxzkpfk.fsf@sdf.org> (raw)
In-Reply-To: <m15z4n6oau.fsf@yahoo.es> ("Daniel Martín via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\""'s message of "Sun, 27 Dec 2020 20:28:57 +0100")

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
>
>>>
>>> Why do we need to expand macros? isn't it enough to find the defstruct
>>> itself, by looking for a partial match?
>>
>> I haven't look at the patch, but I think the approach of macro expanding
>> is more general as should be able to track any function definition that
>> is synthesized by any macro.
>>
>
> Yes, my patch tried a more general approach, which would not only find
> function definitions, but also defvars like the hooks that are
> synthesized by define-major-mode, for example.
>
> There's some opportunities to do less work, though.  For example, I
> think it does not make sense to expand defuns because those were handled
> in a previous step.  I think that'd reduce the search space
> significantly.
>
> Another possible approach for this problem is to search textually for
> just the things that we're typically interested in (like, cl-defstruct
> or define-derived-mode), and expand only those to see if they synthesize
> the symbol we are looking for.  It will be a less general solution, but
> it will be faster.  We may add more cases in the future, if needed.
>
> Thoughts?

I personally like the generic approach.  Also considered should be
running only when the regexp based one is failing and therefore with no
performance hit in most cases but only fixing the broken ones.

  Andrea





  reply	other threads:[~2020-12-27 19:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<E1kt6ez-0000D4-0e@fencepost.gnu.org>
     [not found] ` <<83a6u0n8y7.fsf@gnu.org>
2020-12-26 18:58   ` bug#45443: 28.0.50; Can't find definition of compilation--message->loc Drew Adams
2020-12-27  0:51     ` Unknown
2020-12-27  8:07       ` Lars Ingebrigtsen
2020-12-27 17:40       ` Eli Zaretskii
2020-12-27 17:59         ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-12-27 18:05           ` Eli Zaretskii
2020-12-27 19:28           ` Unknown
2020-12-27 19:28           ` Unknown
2020-12-27 19:40             ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2020-12-26 10:18 Richard Stallman
2020-12-26 10:44 ` Eli Zaretskii
2020-12-27  5:38   ` Richard Stallman

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=xjfmtxzkpfk.fsf@sdf.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=45443@debbugs.gnu.org \
    --cc=akrl@sdf.org \
    --cc=mardani29@yahoo.es \
    --cc=rms@gnu.org \
    /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).