* bug#8297: Request: Better Emacs self-documentation for customization @ 2011-03-20 0:07 Florian Beck 2011-03-21 22:00 ` Stefan Monnier 0 siblings, 1 reply; 4+ messages in thread From: Florian Beck @ 2011-03-20 0:07 UTC (permalink / raw) To: 8297 Emacs integrates any function I write into its documentation; the help function provides a link to the source. 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. - 'describe-variable', on the other hand, remembers the original definition, but doesn't remember the place where I changed the value. - `describe-key' only provides a link to the function, not to the place the key was defined. 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. -- Florian Beck ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8297: Request: Better Emacs self-documentation for customization 2011-03-20 0:07 bug#8297: Request: Better Emacs self-documentation for customization Florian Beck @ 2011-03-21 22:00 ` Stefan Monnier 2011-03-22 6:59 ` Lennart Borgman 2011-03-23 8:59 ` Florian Beck 0 siblings, 2 replies; 4+ messages in thread From: Stefan Monnier @ 2011-03-21 22:00 UTC (permalink / raw) To: Florian Beck; +Cc: 8297 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8297: Request: Better Emacs self-documentation for customization 2011-03-21 22:00 ` Stefan Monnier @ 2011-03-22 6:59 ` Lennart Borgman 2011-03-23 8:59 ` Florian Beck 1 sibling, 0 replies; 4+ messages in thread From: Lennart Borgman @ 2011-03-22 6:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: Florian Beck, 8297 On Mon, Mar 21, 2011 at 11:00 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > >> - `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. That would be good. I have a hack that at least try to guess the map where a key is defined. This is the function `describe-key-and-map-briefly' in ourcomments-util.el in nXhtml. (It is a replacement for `describe-key-briefly'.) ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8297: Request: Better Emacs self-documentation for customization 2011-03-21 22:00 ` Stefan Monnier 2011-03-22 6:59 ` Lennart Borgman @ 2011-03-23 8:59 ` Florian Beck 1 sibling, 0 replies; 4+ messages in thread From: Florian Beck @ 2011-03-23 8:59 UTC (permalink / raw) To: 8297 On 03/21/2011 11:00 PM, Stefan Monnier wrote: > Note that for your case, another option is to use a defadvice, and > indeed defadvice should also add a hyperlink to the advice. Right. So that one is not so urgent. It is only that I already have quite some redefined functions (from the emacs source or from third-party packages) and finding the original definition can be surprisingly difficult. > >> - '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. Understood. Again, unfortunatly `setq' is what I have. Perhaps an old-fashioned but definitly valid way of customizing. > 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). That would be great indeed. > >> - `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. This one, on the other hand, is a major annoyance. Say, I use `global-set-key' to customize a key binding. I continue working with my emacs session, maybe for day. But the next time I start emacs, the binding is overwritten, because I defined the same key in some other file. > >> 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 > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-03-23 8:59 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-20 0:07 bug#8297: Request: Better Emacs self-documentation for customization Florian Beck 2011-03-21 22:00 ` Stefan Monnier 2011-03-22 6:59 ` Lennart Borgman 2011-03-23 8:59 ` Florian Beck
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).