unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Florian Beck <fb@miszellen.de>
Cc: 8297@debbugs.gnu.org
Subject: bug#8297: Request: Better Emacs self-documentation for customization
Date: Mon, 21 Mar 2011 18:00:09 -0400	[thread overview]
Message-ID: <jwvtyewgn3a.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <4D854552.6000509@miszellen.de> (Florian Beck's message of "Sun,  20 Mar 2011 01:07:46 +0100")

severity 8297 wishlist
thanks

> What I would like is for Emacs to track my customisations:

>  - When I redefine an Emacs function I would like a link to the
> previous/original definition, `describe-function' only provides a link to
> the current one.

I'd like to improve the support for redefinition of functions, indeed.
I'm more interested in getting unload-feature to work more reliably, but
it could work for this as well: basically remember the
previous definitions.

Note that for your case, another option is to use a defadvice, and
indeed defadvice should also add a hyperlink to the advice.

>  - 'describe-variable', on the other hand, remembers the original
> definition, but doesn't remember the place where I changed the value.

That might turn out to be more difficult to track, but at least for some
simple cases (e.g. when the vlue is changed via `custom' functions rather
than via `setq') that should definitely be doable.  If the var was set
via `setq' it's more difficult since `setq' is a very low-level
primitive that needs to run fast.  But maybe we could somehow handle
`setq' outside of functions in a special way (these shouldn't impact
performance since they can't be in loops).

>  - `describe-key' only provides a link to the function, not to the place the
> key was defined.

That's also more difficult because OT1H `define-key' does not get much
information (it can check load-file-name, but it doesn't know the line
number, nor the name of the map it receives and neither does it know
reliably what the key description looks like in the source file, so it's
hard to do a regexp-search), and OTOH there's no place currently to
store that information, tho I guess we could keep it in some side
hash-table.

> Obviously, this is not easy, because evaluations don't necessarily
> have a fixed place and key bindings can be defined in many ways. Regardless,
> I think this is something on which Emacs could improve.

Agreed.  It's not high on my todo list, but I'll be happy to take
patches for those.  For defadvice it should be pretty easy, and for
function re-definitions it shouldn't be too hard either.


        Stefan





  reply	other threads:[~2011-03-21 22:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-20  0:07 bug#8297: Request: Better Emacs self-documentation for customization Florian Beck
2011-03-21 22:00 ` Stefan Monnier [this message]
2011-03-22  6:59   ` Lennart Borgman
2011-03-23  8:59   ` Florian Beck

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=jwvtyewgn3a.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=8297@debbugs.gnu.org \
    --cc=fb@miszellen.de \
    /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).