Hrvoje Niksic <hniksic(a)iskon.hr> writes:
> I don't think we need 1. since XEmacs has multiple help
> just don't know the best way to handle 2, so it describes function
> part only. Perhaps it should prompt for user to choose function or
> variable. Or it should do the same with FSF Emacs.
The latter would be quite acceptable.
You mean showing both function and variable documentation?
FSF Emacs shows them in the same buffer. XEmacs doesn't
have handy way to do that. Using separate buffers is easy
but popping up two buffer is annoying to me.
You might consider implementing a context-sensitive menu that
the user to choose between function and variable documentation. Also
note that the same symbol can denote a face, a charset, etc. More
stuff for the context menu.
There's no function to describe a face, a charset, a keymap.
I think I should implement describe-face, describe-charset,
etc. I think it is useful if C-h v emacs-lisp-mode-map
makes link from #<keymap emacs-lisp-mode-map 4 entries
0x1449> to an actual keymap.
> This patch will make C-h b a bit slower but more useful.
How much slower?
(let ((start (time-to-seconds (current-time)))
(while (> i 0)
(setq i (1- i)))
(- (time-to-seconds (current-time)) start))
FSF Emacs 20.5
It might be improved a little bit if it is changes to do
regexp search at inserting time because more specific regexp
can be used. But I haven't tested them yet.
> + ;; #### This relies heavily on current output format.
> + ;; When it's changed, this won't work.
You could fix this by having the help.el functions attach
context-sensitive extents to important parts of the text. Then you
could add highlighting and stuff by mapping over those extents. This
would be less error-prone and would survive gettextization.
Thanks. I'll implement that way.
Umm, no, please don't do this. It's a bit nicer to just
face you want to use with the right properties, like this:
If you want compatibility with FSF Emacs, you can create a
`help-highlight-face' variable that points to the face. You could
also suggest the same change to the FSF developers.
Acutually, I don't care much about compatibility so I'll
just remove that variable.
I'll rewrite them the way you suggested in this weekend.