* 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).