bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#67455: Record source position, etc., in doc strings, and use this in


From: Alan Mackenzie
Subject: bug#67455: Record source position, etc., in doc strings, and use this in *Help* and backtraces.
Date: Mon, 4 Dec 2023 21:32:19 +0000

Hello, Stefan.

Thanks for such a quick response.

On Mon, Dec 04, 2023 at 13:33:25 -0500, Stefan Monnier wrote:
> > I've committed the first stage of this implementation in the new git
> > branch feature/positioned-lambdas.

> Haven't had enough time to look closely, so just some quick early comment.

> > It creates for compiled functions (but not yet for interpreted ones) doc
> > strings starting with a specially formatted string containing the
> > defining symbol, the source file name,

> Why include the file name?  Presumably we will rely on a `(FILE . POS)`
> to find that docstring so including FILE in there is rather redundant
> (and in addition to that, this file name can be wrong if it's absolute
> since files often get moved between compilation and use).

No, the (FILE . POS) is the .elc file, the one I'm putting into the new
info is the source file.  But you're right about an absolute name (as it
currently is) not being the Right Thing.  A lot of Emacs users will be
using binaries compiled by somebody else on a different machine, so an
absolute name is unhelpful, as well as divulging information about the
builder's file structure.  Maybe it should be
lisp/emacs-lisp/bytecomp.el rather than
/home/acm/emacs/emacs.git/sub-master-a/lisp/emacs-lisp/bytecomp.el.  At
least it would be shorter.

> > the position of the defining symbol in the file, and the position of
> > the lambda (should we be in one) in the file.

> Why two positions?
> Why not use the same position info as used in `byte-compile-warn-x`?

I'm not sure, yet, but I suspect both positions will be useful.  If not,
it's trivial to change the contents of the new info, at least it is now.

> > To instruct a defining macro to set a defining-symbol, it is only
> > necessary to add a clause like (defining-symbol 1)

> Sounds good.
> [ Hopefully we can eventually use that info for `font-lock` so we can
>   get rid of ad-hoc rules for `defun` and friends.  It would require an
>   additional piece of info (not only the position but also the kind of
>   definition, to distinguish `defun` from `defvar`).  ]

> > or (defining-symbol (if (consp struct) (car struct) struct))

> [ Haven't seen that yet.  ]

Have a look at cl-defgeneric and cl-defmethod in cl-generic.el.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]