Re: Assignment of misc packages for emacs

[Kim F. Storm]

Richard Stallman <address@hidden> 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))