From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: ehelp woes, or why I hate a module that I love so much Date: Tue, 25 Jun 2002 16:50:55 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <20020625155158.5935.LEKTU@terra.es> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1025016671 1141 127.0.0.1 (25 Jun 2002 14:51:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2002 14:51:11 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17Mrex-0000II-00 for ; Tue, 25 Jun 2002 16:51:11 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17Mrgd-0003qx-00 for ; Tue, 25 Jun 2002 16:52:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17Mrez-00085z-00; Tue, 25 Jun 2002 10:51:13 -0400 Original-Received: from [62.22.27.141] (helo=mail.peoplecall.com) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17Mrei-00084y-00 for ; Tue, 25 Jun 2002 10:50:57 -0400 Original-Received: from [62.22.27.143] (jbarranquero.ofi.peoplecall.com [62.22.27.143]) by mail.peoplecall.com (8.11.6/8.11.6) with ESMTP id g5PEotY31105 for ; Tue, 25 Jun 2002 16:50:55 +0200 Original-To: emacs-devel@gnu.org X-Mailer: Becky! ver. 2.05 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5194 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5194 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