[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ehelp woes, or why I hate a module that I love so much

From: Juanma Barranquero
Subject: ehelp woes, or why I hate a module that I love so much
Date: Tue, 25 Jun 2002 16:50:55 +0200

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]