From: Juanma Barranquero <lektu@terra.es>
Subject: ehelp woes, or why I hate a module that I love so much
Date: Tue, 25 Jun 2002 16:50:55 +0200 [thread overview]
Message-ID: <20020625155158.5935.LEKTU@terra.es> (raw)
I'm a big fan of electric buffers and windows; I mean that I like help
windows and temporary buffers to be as reduced and inobstrusive as
posible, and like the ability to dismiss temporary information with a
simple keystroke.
To that end I use ehelp and try to electric-helpify as many information
functions as I can (not counting lobbing module developers to use
`fit-window-to-buffer', `shrink-window-if-larger-than-buffer' and
`electric-helpify' :)
However, it seems like ehelp is not much used, and so not much
maintained, and it's suffering from several shortcomings.
A short list of current problems with ehelp:
- When an electric-helpify'ed function splits the current window
(because it was the only one), first it moves the cursor to the first
visible character in the window (to keep the buffer from scrolling, I think).
The cursor position is restored if the user (q)uits the function, but it
is *not* if the user exits the function by (r)etaining its output buffer.
- Also, (as stated in ehelp's comments), after (r)etaining, the
resulting buffer is not a *Help* buffer.
- If you electric-helpify a function whose output has text attributes,
those are not correctly shown. For example, with global-font-lock-mode
active, define
(defun my-describe-char ()
(interactive)
(electric-helpify #'describe-char))
and do M-x my-describe-char over a font-locked character. You'll get
something like:
> character: h (0150, 104, 0x68)
> charset: ascii (ASCII (ISO646 IRV))
> code point: 104
> syntax: w which means: word
> category: a:ASCII l:Latin
> buffer code: 0x68
> file code: 68 (encoded by coding system iso-latin-9-dos)
> font: -outline-Courier New-normal-r-normal-normal-12-90-96-96-c-70-iso8859-1
>
> There are text properties here:
> fontified t
> face font-lock-function-name-face
where "fontified" and "face" are shown int the default font. However,
if you (r)etain or otherwise bypass the electric-command-loop (like by
doing M-:), those strings are immediately shown in font-lock-face
(italic by default).
- Following links in the *Help* buffer does not work right. For example,
if you do
M-x electric-describe-function defun
and move the cursor over `interactive' and press Return, the buffer
changes to show the documentation of `interactive', and we still get
the message "Press SPC to scroll, q to exit, r to retain". However,
those keys do *not* work (q does not exit, r does not retain). Moreover,
following the [back] button moves back, and we get again the "Press q to
exit, r to retain" message, but the only way to exit cleanly is C-g.
- If you invoke an electric-helpify'ed function and then kill the buffer
(I do that mistake with surprising regularity), the
electric-command-loop remains active. Yes, that's probably not a bug,
but still is very annoying.
I'm not entirely sure what I'm ranting about here. I guess what I feel
is that perhaps ehelp should be less electric, in the sense that,
instead of having its own command-loop, it should define local
keybindings for (q)uitting, (r)etaining, etc. that would do the job just
fine and present less inconvenients...
/L/e/k/t/u
next reply other threads:[~2002-06-25 14:50 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-25 14:50 Juanma Barranquero [this message]
2002-06-25 15:06 ` ehelp woes, or why I hate a module that I love so much D. Goel
2002-06-25 15:41 ` Juanma Barranquero
2002-06-26 22:24 ` Richard Stallman
2002-06-27 17:11 ` Juanma Barranquero
2002-06-27 19:57 ` Stefan Monnier
2002-07-02 15:02 ` Juanma Barranquero
2002-07-02 15:18 ` Stefan Monnier
2002-07-02 15:50 ` Juanma Barranquero
2002-06-29 8:41 ` Richard Stallman
2002-07-02 15:15 ` Juanma Barranquero
2002-07-02 15:49 ` Eli Zaretskii
2002-07-03 11:16 ` Juanma Barranquero
2002-07-03 20:57 ` Richard Stallman
2002-07-03 21:32 ` Simon Josefsson
2002-07-04 5:09 ` Eli Zaretskii
2002-07-04 7:58 ` Juanma Barranquero
2002-07-04 10:13 ` Eli Zaretskii
2002-07-04 11:52 ` Juanma Barranquero
2002-07-06 10:38 ` Eli Zaretskii
2002-07-04 11:02 ` Simon Josefsson
2002-07-04 12:08 ` Juanma Barranquero
2002-07-04 12:19 ` Miles Bader
2002-07-04 13:31 ` Juanma Barranquero
2002-07-04 14:02 ` Simon Josefsson
2002-07-04 14:00 ` Simon Josefsson
2002-07-04 15:20 ` Juanma Barranquero
2002-07-17 2:58 ` emacs and guile (Re: ehelp woes, or why I hate a module that I love so much) Ken Raeburn
2002-07-17 7:13 ` Juanma Barranquero
2002-07-17 9:11 ` Kai Großjohann
2002-07-18 14:54 ` Richard Stallman
2002-07-18 21:45 ` Ken Raeburn
2002-07-18 14:55 ` Richard Stallman
2002-07-18 20:13 ` Ken Raeburn
2002-07-19 13:03 ` Andreas Schwab
2002-07-19 16:24 ` Ken Raeburn
2002-07-19 16:54 ` Richard Stallman
2002-07-19 17:51 ` Ken Raeburn
2002-07-18 14:56 ` Richard Stallman
2002-07-18 19:54 ` Ken Raeburn
2002-07-19 4:23 ` Stefan Monnier
2002-07-19 12:56 ` Ken Raeburn
2002-07-19 13:34 ` Stefan Monnier
2002-07-19 14:16 ` Andreas Schwab
2002-07-19 15:04 ` Stefan Monnier
2002-07-19 16:54 ` Richard Stallman
2002-07-19 17:48 ` Ken Raeburn
2002-07-19 18:25 ` Marius Vollmer
2002-07-20 0:35 ` Richard Stallman
2002-07-20 12:00 ` Marius Vollmer
2002-07-21 20:14 ` Richard Stallman
2002-07-19 16:54 ` Richard Stallman
2002-07-04 19:07 ` ehelp woes, or why I hate a module that I love so much Henrik Enberg
2002-07-05 0:49 ` Juanma Barranquero
2002-07-05 11:15 ` Per Abrahamsen
2002-07-05 10:48 ` Richard Stallman
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=20020625155158.5935.LEKTU@terra.es \
--to=lektu@terra.es \
/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).