From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: no-spam@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Assignment of misc packages for emacs Date: 15 May 2002 01:44:54 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xvg9qmgzt.fsf@kfs2.cua.dk> References: <200205050534.g455YfF01634@aztec.santafe.edu> <5xbsbumexh.fsf@kfs2.cua.dk> <200205141941.g4EJfud15293@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1021416326 23320 127.0.0.1 (14 May 2002 22:45:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 14 May 2002 22:45:26 +0000 (UTC) Cc: assign@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 177l2s-000641-00 for ; Wed, 15 May 2002 00:45:26 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 177lE7-0001lD-00 for ; Wed, 15 May 2002 00:57:03 +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 177l2g-00054g-00; Tue, 14 May 2002 18:45:14 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 177l1f-0004rs-00; Tue, 14 May 2002 18:44:11 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id EC8507C016; Tue, 14 May 2002 22:44:08 +0000 (GMT) Original-To: rms@gnu.org In-Reply-To: <200205141941.g4EJfud15293@aztec.santafe.edu> Original-Lines: 152 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3941 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3941 Richard Stallman writes: > Where M-x grep prompts for a command line, M-x match prompts for a > search pattern (offering the current word from the selected buffer as > default), a file pattern (with predefined abbreviations, e.g. `ch' > searches all .c and .h files), and a base directory where to start the > recursive search. > > Others have suggested such an interface, but I am not sure it is > really more convenient than the current interface. Why do you find it > better? I find it much easier to use (that's why I wrote it :-). Let me give you an example (based on CVS emacs sources): I'm visiting ~/fsf/emacs/lwlib/xlwmenu.c On line 1625, there is a call to the function x_free_dpy_colors. I want find out where it is defined & used elsewhere. I place the cursor on the name of the function and enters M-x match (I've bound it to H-m). It prompts me for the word to search for. Since the current word is the default, I just hit RET. It prompts me for the files to search in. It suggests `ch' (or whatever I used last), meaning all *.[ch] files. This is what I want, so I just hit RET again. It now prompts for the directory to base the search: The default is ~/fsf/emacs/lwlib/, but I want to search in all the emacs source files, so I use M-DEL to get ~/fsf/emacs/ and hit RET. As a result, it shows me this menu: cd ~/fsf/ebuild/ >./lwlib/xlwmenu.c:69:extern void x_free_dpy_colors __P ((Display *, Screen *, Colormap, ./lwlib/xlwmenu.c:1625: x_free_dpy_colors (dpy, screen, cmap, ./lwlib/xlwmenu.c:1635: x_free_dpy_colors (dpy, screen, cmap, ./lwlib/xlwmenu.c:1650: x_free_dpy_colors (dpy, screen, cmap, &mw->menu.top_shadow_color, 1); ./lwlib/xlwmenu.c:1661: x_free_dpy_colors (dpy, screen, cmap, ./lwlib/xlwmenu.c:1696: x_free_dpy_colors (dpy, screen, cmap, px, i); ./src/xfaces.c:708:x_free_dpy_colors (dpy, screen, cmap, pixels, npixels) ./src/xterm.c:3478: x_free_dpy_colors (DisplayOfScreen (screen), screen, cmap, ./src/xterm.h:1088:extern void x_free_dpy_colors P_ ((Display *, Screen *, Colormap, I find this very easy to use; compare: M-x match RET RET RET M-DEL RET to using e.g M-x grep-find RET x_free_dpy_colors RET The latter doesn't (easily) allow you to start the search in another directory, and it finds (duplicate) matches in backup files (such as xterm.c~), and IMO the prompt is _completely obscure_ unless you are a UNIX shell expert... > > I am not sure it is worth reading the directory rather than just using > the current directory. This is VERY useful (I use it very often), and to use the current directory, just hit RET. > > As a result, it presents a buffer with all the matching lines [like > M-x grep does], but it has a command set which is specifically > tailored to navigating through the matches, e.g. > > SPC, n - shows the next match in the other window (but keeps the match > buffer active). It temporarily highlights the matching text in the > other window. > > This feature seems to be orthogonal to the command argument interface. Yes, you could argue that this is a separate issue -- but I think the menu need to be efficient to get the maximum usability... > Perhaps you can add such features to Compilation mode. It would be > better not to use printing characters as commands, though. I could do that, but we had a lengthy discussion a while back on what commands to add to compilation mode, and I think there was some resistence to "improve" it. But I'll check up on that, and see what can be done (M-x match does use compile-internal). > > Enhanced C-a: > > The first C-a always jumps to the beginning of the line (even if the cursor is > already there -- this is so keyboard macros can consistenly depend on > where C-a moves). > > I don't like this. What don't you like? That C-a jumps between the beginning of line and indentation, or the specific behaviour you quote above. > > > - - minimenu.el [small] > > which provides simple menu prompting in the minibuffer > > > > Could you tell me more? > > It makes it easy for other packages to prompt with something like > > EMACS file: c)ommon u)ser i)nit p)re .)emacs cus(t)om l)isp e(x)ec s)rc > > in the minibuffer and then take different actions depending on whether > the user enters c, u, i, p, ., t, l, x, or s. > > This sounds like the existing feature for handling menus on character > ttys. Could you see how they compare? I can see the similarity in functionality, but for the simple use for which it is intended, I like mine better, as it is less intrusive and more similar to a keymap "with intermediate help in echo area". E.g. I have the following mini-menu bound to F8: QUERY: r)egexp s)tring t)ags ALL: R)egexp S)tring I.e. I only have to member that "replace" is on F8, instead of the following commands: F8 r => C-M-% (query-replace-regexp) F8 s => M-% (query-replace) F8 t => M-x tags-query-replace F8 R => M-x replace-regexp F8 S => M-x replace-string To achieve this, I use the following code: (defvar replace-mini-menu '( (:tag "QUERY:") (?r "r)egexp" query-replace-regexp) (?s "s)tring" query-replace) (?t "t)ags" tags-query-replace) (:tag " ALL:") (?R "R)egexp" replace-regexp) (?S "S)tring" replace-string))) (defun replace-menu () "Run a replace command specified in replace-commands." (interactive) (mini-menu replace-mini-menu))