GNU bug report logs - #45443
28.0.50; Can't find definition of compilation--message->loc

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45443 in the body.
You can then email your comments to 45443 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Richard Stallman <rms <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Can't find definition of compilation--message->loc
Date: Sat, 26 Dec 2020 05:18:53 -0500

Trying to debug a bug in compile-goto-error on Rmail files,
I typed C-h f compilation--message->loc RET
then clicked on the file name -- which is supposed to find the definition
of that function.

It did not find the definition; instead it said,

    Unable to find location in file

I also tried M-x find-function RET compilation--message->loc RET.
It found a call to compilation--message->loc, not the definition.

I searched for that name in the file and did not find a definition.
I will try grepping for it.



In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32, cairo version 1.15.10)
 of 2020-12-08 built on freetop
Repository revision: 0155bd0fdb166c97a2ce76cc5bc64fd195a676d3
Repository branch: master
System Description: Trisquel GNU/Linux Etiona (9.0)

Configured using:
 'configure --with-gnutls=ifavailable 'CFLAGS=-O0 -g''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 XDBE XIM MODULES THREADS PDUMPER

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Help

Minor modes in effect:
  shell-dirtrack-mode: t
  gpm-mouse-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(completion dos-w32 find-cmd find-dired whitespace cl-print debug
backtrace rmail-spam-filter rmailedit rmailsort undigest tramp-gvfs
zeroconf tramp-cache bug-reference shortdoc help-fns radix-tree
descr-text help-at-pt ispell unrmail time-stamp texinfo url-http
url-auth url-gw nsm tramp tramp-loaddefs trampver tramp-integration
tramp-compat ls-lisp arc-mode archive-mode srecode/srt-mode
semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn
semantic/db semantic/format srecode/template srecode/srt-wy
semantic/wisent semantic/wisent/wisent semantic/ctxt srecode/ctxt
semantic/tag-ls semantic/find srecode/compile srecode/dictionary
srecode/fields srecode/table srecode eieio-base semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw
mode-local cedet pcmpl-unix rect compare-w novice kmacro etags
fileloop xref project quail mail-extr pp shadow emacsbug smerge-mode
diff log-edit pcvs-util add-log org-element avl-tree generator ol-eww
ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-search eieio-opt
speedbar ezimage dframe gnus-art mm-uu mml2015 mm-view mml-smime smime
dig gnus-sum gnus-group gnus-undo gnus-start gnus-dbus dbus gnus-cloud
nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int
gnus-range gnus-win ol-docview doc-view jka-compr image-mode exif
ol-bibtex bibtex ol-bbdb ol-w3m org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob-core ob-eval org-table ol org-keys org-compat
org-macs org-loaddefs format-spec find-func cal-menu calendar
cal-loaddefs cl-extra parse-time iso8601 mhtml-mode css-mode smie eww
xdg url-queue mm-url gnus nnheader wid-edit color js imenu cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs sgml-mode help-mode mule-util shell pcomplete
thingatpt files-x grep compile comint ansi-color ring misearch
multi-isearch epa-mail rmailkwd rmailsum vc-mtn vc-hg vc-git diff-mode
easy-mmode vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc vc-dispatcher
shr kinsoku svg xml dom rmailout dabbrev mailalias sendmail qp rmailmm
message rmc puny rfc822 mml mml-sec epa epg epg-config gnus-util
text-property-search time-date mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader mail-parse rfc2231 rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils dired-aux dired dired-loaddefs t-mouse term/linux view
derived paren cus-start cus-load advice finder-inf package easymenu
browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode
elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet
lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese composite charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 1190950 169604)
 (symbols 48 45903 20)
 (strings 32 226599 25400)
 (string-bytes 1 5447911)
 (vectors 16 76348)
 (vector-slots 8 2114801 141195)
 (floats 8 441 551)
 (intervals 56 152476 898)
 (buffers 984 297))
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 45443 <at> debbugs.gnu.org
Subject: Re: bug#45443: 28.0.50;
 Can't find definition of compilation--message->loc
Date: Sat, 26 Dec 2020 12:44:00 +0200

> From: Richard Stallman <rms <at> gnu.org>
> Date: Sat, 26 Dec 2020 05:18:53 -0500
> 
> Trying to debug a bug in compile-goto-error on Rmail files,
> I typed C-h f compilation--message->loc RET
> then clicked on the file name -- which is supposed to find the definition
> of that function.
> 
> It did not find the definition; instead it said,
> 
>     Unable to find location in file
> 
> I also tried M-x find-function RET compilation--message->loc RET.
> It found a call to compilation--message->loc, not the definition.
> 
> I searched for that name in the file and did not find a definition.
> I will try grepping for it.

It's a general problem with uses of cl-defstruct and similar
constructs: they generate functions and macros that the Help functions
are unable to find.  In this case, see this part of compile.el:

  (cl-defstruct (compilation--message
	      (:constructor nil)
	      (:copier nil)
	      ;; (:type list)                ;Old representation.
	      (:constructor compilation--make-message (loc type end-loc rule))
	      (:conc-name compilation--message->))
    loc type end-loc rule)

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, rms <at> gnu.org
Cc: 45443 <at> debbugs.gnu.org
Subject: RE: bug#45443: 28.0.50; Can't find definition of
 compilation--message->loc
Date: Sat, 26 Dec 2020 10:58:21 -0800 (PST)

> It's a general problem with uses of cl-defstruct and similar
> constructs: they generate functions and macros that the Help functions
> are unable to find.

Yep.  It's a big doc/help problem, IMO.  And
we've moved more and more stuff to things like
`cl-defstruct' (which in itself is fine).

I don't see a good general solution to this
problem.  But it is, I think, something
important for the quintessential
"self-documenting" editor.  I truly hope that
some smart and ambitious hacker tackles this.

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, rms <at> gnu.org, 45443 <at> debbugs.gnu.org
Subject: Re: bug#45443: 28.0.50; Can't find definition of
 compilation--message->loc
Date: Sun, 27 Dec 2020 01:51:29 +0100

[Message part 1 (text/plain, inline)]

Drew Adams <drew.adams <at> oracle.com> writes:

>> It's a general problem with uses of cl-defstruct and similar
>> constructs: they generate functions and macros that the Help functions
>> are unable to find.
>
> Yep.  It's a big doc/help problem, IMO.  And
> we've moved more and more stuff to things like
> `cl-defstruct' (which in itself is fine).
>
> I don't see a good general solution to this
> problem.  But it is, I think, something
> important for the quintessential
> "self-documenting" editor.  I truly hope that
> some smart and ambitious hacker tackles this.

One possible approach is, if the regular expression code fails to find a
location, we can fall back to expand macros until we find the definition
(a defalias in the case of a function, or a defvar in the case of a
variable), or we reach the end of the file.

I attach a first implementation of this approach, with some tests for
the function definition that Richard wanted to find.  I'm sure there are
still missing cases that are interesting (closures?).  Give it a try and
see if there are still relevant symbols whose definition Emacs is unable
to locate.  I'm also open to feedback about the macro expansion logic.
Could it be more efficient?  Thanks.

[0001-Improve-find-definition-in-Help-buffers.patch (text/x-patch, attachment)]

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

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45443 <at> debbugs.gnu.org
Subject: Re: bug#45443: 28.0.50;
 Can't find definition of compilation--message->loc
Date: Sun, 27 Dec 2020 00:38:17 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's a general problem with uses of cl-defstruct and similar
  > constructs: they generate functions and macros that the Help functions
  > are unable to find.  In this case, see this part of compile.el:

  >   (cl-defstruct (compilation--message

What causes the problem?  There has to be a way to fix it.

Does the fact that the defining form name does not start with `def'
have anything to do with it?  We could call it `def-cl-struct'.

There is also this:

            (:conc-name compilation--message->))

Years have taught me that enabling a definition to be a little shorter
by making names by concatenation is a bad idea.  It makes the code
harder to understand because there are references to these names that
you can't find with simple searching.

Is there a way to rewrite that definition so it does not concatenate
names?

If there is none, can we create one?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: mardani29 <at> yahoo.es
Cc: rms <at> gnu.org, Drew Adams <drew.adams <at> oracle.com>, 45443 <at> debbugs.gnu.org
Subject: Re: bug#45443: 28.0.50; Can't find definition of
 compilation--message->loc
Date: Sun, 27 Dec 2020 09:07:06 +0100

Unknown <unknown <at> unknown.invalid> writes:

> I attach a first implementation of this approach, with some tests for
> the function definition that Richard wanted to find.  I'm sure there are
> still missing cases that are interesting (closures?).  Give it a try and
> see if there are still relevant symbols whose definition Emacs is unable
> to locate.  I'm also open to feedback about the macro expansion logic.
> Could it be more efficient?  Thanks.

This is something I've wanted for a long time, so I went ahead and
pushed it to Emacs 28.  :-)  I tried it on a couple cl-defstructs, and
it seems to work well for me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: rms <at> gnu.org, drew.adams <at> oracle.com, 45443 <at> debbugs.gnu.org
Subject: Re: bug#45443: 28.0.50; Can't find definition of
 compilation--message->loc
Date: Sun, 27 Dec 2020 19:40:54 +0200

> From: Daniel Martín <mardani29 <at> yahoo.es>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  rms <at> gnu.org,  45443 <at> debbugs.gnu.org
> Date: Sun, 27 Dec 2020 01:51:29 +0100
> 
> One possible approach is, if the regular expression code fails to find a
> location, we can fall back to expand macros until we find the definition
> (a defalias in the case of a function, or a defvar in the case of a
> variable), or we reach the end of the file.

Why do we need to expand macros? isn't it enough to find the defstruct
itself, by looking for a partial match?

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45443 <at> debbugs.gnu.org, rms <at> gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45443: 28.0.50; Can't find definition of
 compilation--message->loc
Date: Sun, 27 Dec 2020 17:59:09 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Martín <mardani29 <at> yahoo.es>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  rms <at> gnu.org,  45443 <at> debbugs.gnu.org
>> Date: Sun, 27 Dec 2020 01:51:29 +0100
>> 
>> One possible approach is, if the regular expression code fails to find a
>> location, we can fall back to expand macros until we find the definition
>> (a defalias in the case of a function, or a defvar in the case of a
>> variable), or we reach the end of the file.
>
> 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.

  Andrea

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 45443 <at> debbugs.gnu.org, rms <at> gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#45443: 28.0.50; Can't find definition of
 compilation--message->loc
Date: Sun, 27 Dec 2020 20:05:24 +0200

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: Daniel Martín <mardani29 <at> yahoo.es>,  rms <at> gnu.org,
>   45443 <at> debbugs.gnu.org
> Date: Sun, 27 Dec 2020 17:59:09 +0000
> 
> > 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.

It is also more expensive and complicated.

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 45443 <at> debbugs.gnu.org, rms <at> gnu.org,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#45443: 28.0.50; Can't find definition of
 compilation--message->loc
Date: Sun, 27 Dec 2020 20:28:57 +0100

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> 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?

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Daniel Martín via "Bug reports for GNU Emacs, the Swiss
 army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Daniel Martín <mardani29 <at> yahoo.es>, rms <at> gnu.org,
 45443 <at> debbugs.gnu.org
Subject: Re: bug#45443: 28.0.50; Can't find definition of
 compilation--message->loc
Date: Sun, 27 Dec 2020 19:40:47 +0000

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

> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> 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

Previous Next

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