From: no-spam@cua.dk (Kim F. Storm)
Cc: assign@gnu.org, emacs-devel@gnu.org
Subject: Re: Assignment of misc packages for emacs
Date: 15 May 2002 01:44:54 +0200 [thread overview]
Message-ID: <5xvg9qmgzt.fsf@kfs2.cua.dk> (raw)
In-Reply-To: <200205141941.g4EJfud15293@aztec.santafe.edu>
Richard Stallman <rms@gnu.org> 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))
next prev parent reply other threads:[~2002-05-14 23:44 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200205050534.g455YfF01634@aztec.santafe.edu>
2002-05-05 22:02 ` Assignment of misc packages for emacs Kim F. Storm
2002-05-06 23:07 ` Alex Schroeder
2002-05-08 1:16 ` Miles Bader
2002-05-08 1:47 ` Stefan Monnier
2002-05-09 2:45 ` Richard Stallman
2002-05-07 14:08 ` Kai Großjohann
2002-05-08 13:58 ` Richard Stallman
2002-05-08 1:31 ` Miles Bader
2002-05-08 6:23 ` Thien-Thi Nguyen
2002-05-14 19:41 ` Richard Stallman
2002-05-14 19:41 ` Richard Stallman
2002-05-14 23:44 ` Kim F. Storm [this message]
2002-05-15 1:08 ` Miles Bader
2002-05-15 21:37 ` Kim F. Storm
2002-05-16 1:19 ` Miles Bader
2002-05-17 19:29 ` Richard Stallman
2002-05-17 21:42 ` Kim F. Storm
2002-05-17 19:29 ` Richard Stallman
2002-05-17 21:31 ` Kim F. Storm
2002-05-16 7:22 ` Richard Stallman
2002-05-16 23:41 ` Kim F. Storm
2002-05-15 4:51 ` Eli Zaretskii
2002-05-15 8:41 ` Andreas Schwab
2002-05-15 10:20 ` Eli Zaretskii
2002-05-15 11:08 ` Andreas Schwab
2002-05-15 21:41 ` Kim F. Storm
2002-05-15 19:27 ` Stefan Monnier
2002-05-15 20:37 ` Andreas Schwab
2002-05-16 23:39 ` Kim F. Storm
2002-05-16 22:49 ` Stefan Monnier
2002-05-17 6:27 ` Eli Zaretskii
2002-05-17 7:10 ` Miles Bader
2002-05-17 9:21 ` Andreas Schwab
2002-05-17 11:13 ` Miles Bader
2002-05-17 9:40 ` Eli Zaretskii
2002-05-17 11:15 ` Miles Bader
2002-05-17 10:47 ` Kim F. Storm
2002-05-17 10:08 ` Stefan Monnier
2002-05-17 11:20 ` Miles Bader
2002-05-17 12:07 ` Kim F. Storm
2002-05-17 11:28 ` Miles Bader
2002-05-18 18:48 ` Richard Stallman
2002-05-18 21:39 ` Kim F. Storm
2002-05-19 19:40 ` Richard Stallman
2002-05-18 22:37 ` Stefan Monnier
2002-05-19 19:40 ` Richard Stallman
2002-05-16 23:07 ` Miles Bader
2002-05-18 18:48 ` Richard Stallman
2002-05-19 11:57 ` Miles Bader
2002-05-19 14:41 ` Stefan Monnier
2002-05-19 15:12 ` Miles Bader
2002-05-20 6:38 ` Miles Bader
2002-05-20 9:57 ` Alex Schroeder
2002-05-20 10:06 ` Kai Großjohann
2002-05-20 21:34 ` Richard Stallman
2002-05-21 9:54 ` Mario Lang
2002-05-21 10:23 ` Miles Bader
2002-05-22 22:29 ` Richard Stallman
2002-05-21 10:20 ` Miles Bader
2002-05-22 22:27 ` Richard Stallman
2002-05-23 7:08 ` Miles Bader
2002-05-23 16:49 ` Mario Lang
2002-05-23 22:21 ` Miles Bader
2002-06-04 17:27 ` Miles Bader
2002-06-05 14:42 ` Stefan Monnier
2002-06-06 1:07 ` Miles Bader
2002-06-06 1:37 ` Stefan Monnier
2002-06-06 1:46 ` Miles Bader
2002-06-06 7:57 ` Miles Bader
2002-06-07 0:45 ` Richard Stallman
2002-06-07 0:45 ` Richard Stallman
2002-06-05 23:10 ` Kim F. Storm
2002-06-06 1:09 ` Miles Bader
2002-06-06 1:24 ` Miles Bader
2002-06-07 0:45 ` Richard Stallman
2002-06-07 23:26 ` Kim F. Storm
2002-06-08 1:09 ` Miles Bader
2002-06-08 19:15 ` Richard Stallman
2002-06-06 12:04 ` Richard Stallman
2002-06-06 12:41 ` Miles Bader
2002-06-06 13:37 ` Stefan Monnier
2002-06-06 13:45 ` Miles Bader
2002-06-07 23:23 ` Richard Stallman
2002-06-08 4:06 ` Miles Bader
2002-06-09 15:19 ` Richard Stallman
2002-06-10 14:35 ` Stefan Monnier
2002-06-11 19:25 ` Richard Stallman
2002-07-07 22:46 ` What happened to the key-menu patch? Kim F. Storm
2002-07-09 7:00 ` Miles Bader
2002-07-09 13:58 ` Stefan Monnier
2002-07-10 2:43 ` Miles Bader
2002-07-10 18:12 ` Stefan Monnier
2002-07-10 10:43 ` Richard Stallman
2002-07-11 17:13 ` Stefan Monnier
2002-07-12 17:37 ` Richard Stallman
2002-07-12 18:07 ` Stefan Monnier
2002-07-13 14:20 ` Richard Stallman
2002-07-13 17:37 ` Stefan Monnier
2002-07-15 1:09 ` Richard Stallman
2002-07-09 18:51 ` Richard Stallman
2002-07-10 2:45 ` Miles Bader
2002-07-10 19:20 ` Richard Stallman
2002-05-20 14:48 ` Assignment of misc packages for emacs Richard Stallman
2002-05-18 18:48 ` Richard Stallman
2002-05-18 20:07 ` Kim F. Storm
2002-05-19 19:40 ` Richard Stallman
2002-05-16 7:21 ` Richard Stallman
2002-05-16 7:21 ` Richard Stallman
2002-05-15 7:44 ` D. Goel
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=5xvg9qmgzt.fsf@kfs2.cua.dk \
--to=no-spam@cua.dk \
--cc=assign@gnu.org \
--cc=emacs-devel@gnu.org \
/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).