* [LONG] Some thougths and a patch for the search menu-bar functions
@ 2002-09-10 8:42 Damien Terrier
2002-09-10 11:36 ` Robert J. Chassell
` (4 more replies)
0 siblings, 5 replies; 16+ messages in thread
From: Damien Terrier @ 2002-09-10 8:42 UTC (permalink / raw)
Hi, (sorry it's going to be a bit long -- about 110 lines. I want to
be precise.)
I'm currently writing a serie of six to seven tutorials for Emacs
aimed at the new to average user. They are still on my hard drive and
I don't have all the tutorials yet. The fourth tutorial is dedicated
to the search functions in Emacs. Since I want to be understood by a
new user I started writing that "in this article, we'll start by
looking at the graphical menu provided. In the menu there is a basic
search, you can do forward, backwards, with regexp or not " Most of
them will not have an Emacs version with the new isearch menu, so I
don't even talk about it. My article again : "But, Ladies and
Gentlemen, there is a second search function, even better, very
spectacular, very fun to use but you can only reach it with the
keyboard. and in this great search function, you will be able to use
the 'old' search with a weird key sequence". It's not very easy to
understand. I would prefer a very clear menu with a nice layout.There
are "only" sixteen search functions
(incremental/regexp/repeat/direction/ -> 2^4) and every search
function have a very precise meaning and a very precise task. There's
must be a way to display them in a very clear menu. Then, I thought :
"The menu-bar for for the search tools is only for the new user. The
average to good user has to use the key sequences. The new user is
learning so he loses time but he will save some later. It's the Emacs
and the UNIX philosophy. So, if the menu-bar is just a bit slower for
a search, but, in the same time, is much easier to understand, and
affects in a good way the new user, then it's a win."
I was stuck because put that way, a new search menu would never
happened.
So I decided to do it myself (I love making my own changes to a
software). I never learned elisp and at first sight, it looks really
awkward. So I did "C-h k" to see what was behind, managed to make my
way inside the source, asked myself "What if I change this to that ?",
I started cutting and pasting things over, made some new functions,
etc. A few minutes later (a few hours actually), I had something that
I liked. By the way, thinking in elisp is quite pleasant. After a few
minutes^w hours, I enjoyed it just like PHP or Perl.
The patch is 13K long. I wanted to join it to this mail, but it might
be a bit too long and it's a bit boring (when rereading myself, I
wonder if this mail is not already a bit too long and a bit boring :),
so I made a small webpage located here
(http://www.diabolus-ex-machina.com/emacs/menu-bar/index.html).This
page has a link to the diff
(http://www.diabolus-ex-machina.com/emacs/menu-bar/menu-bar.diff), a
link to my last CVS file and a link to my menu-bar.el already patched.
I also put four screenshots to show what I've done. Each of them is a
PNG file and is about 15K.
[half mail]
Basically I did the following changes : First I changed "Incremental
Search" to "Interactive Search" (in the display only). It won't change
anything to the long Emacs' user but maybe the meaning of
"Interactive" will have more sense than "Incremental" to the new
user. In the source, I kept "incremental" and "isearch", it's only for
the display that it's called "Interactive". Maybe the manual would
have to change but a sentence like "For historical reasons,
'Incrementenal Search', was used before 'Interactive Search'. The old
term is used in the manual. But it's really the same thing.". Or
"Incremental" could stay. Anyway, it's not very long to change. I
also renamed the old "Search" to "Non Interactive Search" because this
way a new user understand why there are two search functions in Emacs
and what are their real difference.
The most significant change was in the organisation of the search
functions. Four items in the last sub-menu is enough and it is much
easier to click on the right one. That's what I don't like in the old
menu, it starts to be a bit populated. Then, I divided in two and
then, in two again. That's why the new version asks "Interactive
Search or Non Interactive Search ?", then "forward or backwards ?"
then, the choice for one of four item "Search/Repeat Search // Search
Regepx/Repeat Search Regexp". It very consistent between "Interactive
Search" and "Non Interactive search". There are eight new functions
(for my version, only six for the last CVS version) in the same menu
and it doesn't take a lot more space. The new user also has a chance
to quickly understand very precisely the true differences between all
the sixteen different search functions. The old "Replace" and "Tagged
files" are still there at the same level than "Interactive/ Non
Interactive". The menu entry for search is called "Search and
Replace" because anyone now expects to find the search functions
"near" the replace functions. It was already the case with my Emacs's
version except that the "search and replace area" was just called
"Search...". I think that's it for the menu-bar changes. I would
like to add I'm a student in (French) linguistics. That's why I may
seems picky "just about" computer language (I also love problems
involving HIC).
I don't know if you will accept my patch, and I have no idea of the
Emacs GUI policy (where I can find it ?). it's not some very big
programming, its long and boring, but it works and I think the the new
search menu is really better than the old one.
I noticed that you had added I-search in the menu bar since the
release date of my Emacs' version (21.1.1 I think). My patch is made
with the last CVS version. I looked at the new menu, I still prefer
mine: it is easier to understand and is much more complete. I clearly
understand you may not want the accept this patch because of my crappy
patch (I just don't know elisp) or because of something I may not
know.
Coming back to my tutorials I've almost finished the search one and I
wrote "I really wish Emacs had a more convenient way to use with the
mouse the search facilities". Instead, I would looove writing to the
readers : "I sent a mail to the Emacs developing team, they replied
'the search tools in the menu-bar would change'".
So, could you check my patch and, _please_, update Emacs to reflect
what I want to write? ;)
Ok, now you know everything relevant to that patch. I hope this wasn't
too long, I hope you didn't waste your time. I tried to make something
entertaining and interesting, but English is not my mother tongue, and
I just described something that is finally only just basic hacking.
Thank you for reading me.
Damien Terrier
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-10 8:42 [LONG] Some thougths and a patch for the search menu-bar functions Damien Terrier
@ 2002-09-10 11:36 ` Robert J. Chassell
2002-09-10 19:30 ` Thien-Thi Nguyen
2002-09-10 11:47 ` Robert J. Chassell
` (3 subsequent siblings)
4 siblings, 1 reply; 16+ messages in thread
From: Robert J. Chassell @ 2002-09-10 11:36 UTC (permalink / raw)
Cc: emacs-devel
More documentation is great, especially for people who start knowing
little. However, there is a conceptual hole near the beginning of
what you say
First I changed "Incremental Search" to "Interactive Search" (in
the display only). It won't change anything to the long Emacs'
user but maybe the meaning of "Interactive" will have more sense
than "Incremental" to the new user.
This change is a mistake! "Incremental Search" is accurate and a
notion to learn! Worse, you cannot distinguish among commands with
the word interactive; all are interactive, including "Non-incremental
Search".
Incremental vrs non-incremental is a major user interface issue. Even
after all these years, incremental search still provides the most
comfortable human interface for navigation. The user does *not* have
to think up a useful string length ahead of time. He or she simply
starts typing the string or regexp, until point lands on the desired
text. The user types only as much as necessary. Because the cursor
moves as he or she types, the user does not have that terrible sense
of `waiting'.
Put in more high-faluting language, with an incremental search, the
man-machine combination makes use of the most efficient, shortest
search string for the context, since the combined partners of this
association do only what is needed, and nothing more.
Perhaps you could add the phrase "Interactive' to "Incremental Search"
to create the explanatory phrase "Interactive Incremental Search".
That may be all right, although on second thoughts, I wonder why
bother, since all menu and keyboard commands are interactive. Put
another way, what is different about `C-s' and `M-x grep'? Both are
interactive commands, but only one of them is incremental.
"Non-incremental Search", `C-s <RET> STRING <RET>', is also
Interactive. Interactivity is not a distinguishing feature.
v
In the source, I kept "incremental" and "isearch", it's only for
the display that it's called "Interactive". Maybe the manual would
have to change but a sentence like "For historical reasons,
'Incrementenal Search', was used before 'Interactive Search'. The old
term is used in the manual. But it's really the same thing.". Or
"Incremental" could stay. Anyway, it's not very long to change. I
also renamed the old "Search" to "Non Interactive Search" because this
way a new user understand why there are two search functions in Emacs
and what are their real difference.
--
Robert J. Chassell bob@rattlesnake.com bob@gnu.org
Rattlesnake Enterprises http://www.rattlesnake.com
Free Software Foundation http://www.gnu.org GnuPG Key ID: 004B4AC8
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-10 11:36 ` Robert J. Chassell
@ 2002-09-10 19:30 ` Thien-Thi Nguyen
0 siblings, 0 replies; 16+ messages in thread
From: Thien-Thi Nguyen @ 2002-09-10 19:30 UTC (permalink / raw)
Cc: damien_terrier, emacs-devel
"Robert J. Chassell" <bob@rattlesnake.com> writes:
Put in more high-faluting language, with an incremental search, the
man-machine combination makes use of the most efficient, shortest
search string for the context, since the combined partners of this
association do only what is needed, and nothing more.
also, backtracking is under user control.
thi
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-10 8:42 [LONG] Some thougths and a patch for the search menu-bar functions Damien Terrier
2002-09-10 11:36 ` Robert J. Chassell
@ 2002-09-10 11:47 ` Robert J. Chassell
2002-09-10 12:24 ` Robert J. Chassell
` (2 subsequent siblings)
4 siblings, 0 replies; 16+ messages in thread
From: Robert J. Chassell @ 2002-09-10 11:47 UTC (permalink / raw)
Cc: emacs-devel
The most significant change was in the organisation of the search
functions.
... the new version asks "Interactive Search or Non Interactive Search
?",
then "forward or backwards ?"
then, the choice for one of four item "Search/Repeat Search // Search
Regepx/Repeat Search Regexp".
This order teaches novices poorly. Usually, non-incremental,
interactive search is a mistake. Please place the Non-incremental
search an option at the lowest level in a location where it can safely
be ignored.
Almost everyone who uses Emacs avoids Non-incremental search (what I
think you are calling `non-interactive search') since Incremental
search is so much more pleasant and efficient.
(I presume you have renamed `Incremental' to `Interactive' even though
all these commands are `Interactive')
Please do not offer Non-incremental search as an always-necessary
choice near or at the top level of a set of questions, but as a
mostly-to-be-ignored option in a menu, near or at the bottom, where it
can be safely forgot by any one who tries it more than once or twice.
--
Robert J. Chassell bob@rattlesnake.com bob@gnu.org
Rattlesnake Enterprises http://www.rattlesnake.com
Free Software Foundation http://www.gnu.org GnuPG Key ID: 004B4AC8
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-10 8:42 [LONG] Some thougths and a patch for the search menu-bar functions Damien Terrier
2002-09-10 11:36 ` Robert J. Chassell
2002-09-10 11:47 ` Robert J. Chassell
@ 2002-09-10 12:24 ` Robert J. Chassell
2002-09-11 1:13 ` Miles Bader
2002-09-11 20:46 ` Kim F. Storm
4 siblings, 0 replies; 16+ messages in thread
From: Robert J. Chassell @ 2002-09-10 12:24 UTC (permalink / raw)
Cc: emacs-devel
I'm currently writing a serie of six to seven tutorials for Emacs
aimed at the new to average user. ....
That is wonderful!
Are you teaching an average user how to define his or her keyboard
more usefully? In particular, are you teaching an average user how to
set his or her control key so that it works when you press the key to
the left of the `a' key on the main row? With this setting, the
"Incremental Search" command is easy to type.
Many US (and I think many French) keyboards label the key to the left
of the `a' key on the main row as `Caps_Lock'. This is an upper-case,
lower-case toggle command taken from the old days of manual
typewriters. It is an ancient carry over from the days when a
`computer' was a human being who did computations, rather than an
electronic device.
For example, the keyboard I am now using has this labeling on its main row:
Caps_Lock A S D F G H J K L ; ' RET
By default, computers with `Caps_Lock' on the label of a key set that
key to run the upper-case, lower-case toggle command.
But a much better command for the key to the left of the `a' key is
`Control'.
In particular, `C-s' (isearch) is easy to type when the little finger
is at the far left of the main row and the first finger is on the key
third from the left on the main row.
On my keyboard, the default position for the key labeled `Ctrl' is
second from the left on the lowest row. This position is fairly
common. (Sometimes that key is farthest left on the bottom row.)
Either way, when the control key is located at the lower left, the
`C-s' (isearch) interactive command is hard to type. Either you must
twist your hand to the left so the little finger can reach the key or
you must use some other finger, such as your thumb. (I find that I can
move my thumb to press the key labeled `Alt' which is to the right of
the key labeled `Ctrl', but that I have a hard time moving it far
enough to reach the key to its left.)
Either way it is typed, the lower left key location provides for a
poor user interface. Consequently, that key location on the lower
left should be used only for rarely pressed key strokes.
Unfortunately, because some keyboard makers have not yet left the
mechanical typewriter era, they produce keyboards, like mine, that
have the wrong labeling and the wrong defaults for a decent user
interface.
A novice Emacs user who does not know how to redefine keybindings will
be hurt by such defaults.
Does your tutorial tell such a user how to define his or her keyboard
more usefully? Could you show us the section and the various commands
for people using keyboards different layouts?
--
Robert J. Chassell bob@rattlesnake.com bob@gnu.org
Rattlesnake Enterprises http://www.rattlesnake.com
Free Software Foundation http://www.gnu.org GnuPG Key ID: 004B4AC8
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-10 8:42 [LONG] Some thougths and a patch for the search menu-bar functions Damien Terrier
` (2 preceding siblings ...)
2002-09-10 12:24 ` Robert J. Chassell
@ 2002-09-11 1:13 ` Miles Bader
2002-09-11 20:46 ` Kim F. Storm
4 siblings, 0 replies; 16+ messages in thread
From: Miles Bader @ 2002-09-11 1:13 UTC (permalink / raw)
Cc: emacs-devel
I agree with Bob that `Incremental' is a better name, and that it
should be first.
I also think it's a mistake to first prompt for a search string and
_then_ start isearch. It should simply start isearch in the same way
that it does if you type C-s or whatever (thus there's no need for all
the various command wrappers you define; just use the real functions).
Other than that, it seems like a reasonable change.
-Miles
--
`...the Soviet Union was sliding in to an economic collapse so comprehensive
that in the end its factories produced not goods but bads: finished products
less valuable than the raw materials they were made from.' [The Economist]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-10 8:42 [LONG] Some thougths and a patch for the search menu-bar functions Damien Terrier
` (3 preceding siblings ...)
2002-09-11 1:13 ` Miles Bader
@ 2002-09-11 20:46 ` Kim F. Storm
2002-09-12 16:41 ` Richard Stallman
4 siblings, 1 reply; 16+ messages in thread
From: Kim F. Storm @ 2002-09-11 20:46 UTC (permalink / raw)
Cc: emacs-devel
Damien Terrier <damien_terrier@yahoo.com> writes:
> The most significant change was in the organisation of the search
> functions. Four items in the last sub-menu is enough and it is much
> easier to click on the right one. That's what I don't like in the old
> menu, it starts to be a bit populated. Then, I divided in two and
> then, in two again. That's why the new version asks "Interactive
> Search or Non Interactive Search ?", then "forward or backwards ?"
> then, the choice for one of four item "Search/Repeat Search // Search
> Regepx/Repeat Search Regexp".
I don't use the menus for searches, but I tend to agree that your
approach makes more sense that the current mess (IMHO).
However, your menu strings seems overly verbose to me.
Here is a your proposed menu structure:
Edit
-> Search and Replace
-> Incremental Search
-> Forward
-> I-Search Forward ...
-> I-Search Regexp Forward ...
-> Backwards
-> I-Search Backwards ...
-> I-Search Regexp Backwards ...
-> Non-Incremental Search
-> Forward
-> Search Forward ...
-> Search Regexp Forward ...
-> Backwards
-> Search Backwards ...
-> Search Regexp Backwards ...
-> Replace
-> Replace ...
-> Replace regexp ...
-> Search and replace in tagged files
-> Search in all tagged files
-> Replace in all tagged files
-> Continue Tag Search/Replace
I think this can be further reorganized and simplified:
Edit
-> Search
-> Incremental
-> Forward
-> String ...
-> Regexp ...
-> Backwards
-> String ...
-> Regexp ...
-> Non-Incremental
-> Forward
-> String ...
-> Regexp ...
-> Backwards
-> String ...
-> Regexp ...
-> In tagged files
-> Replace
-> String ...
-> Regexp ...
-> In all tagged files
-> Continue Next Tag
I think this is better in line with many other applications which
separate Search and Replace into two items on the Edit menu.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-11 20:46 ` Kim F. Storm
@ 2002-09-12 16:41 ` Richard Stallman
2002-09-12 21:26 ` Kim F. Storm
0 siblings, 1 reply; 16+ messages in thread
From: Richard Stallman @ 2002-09-12 16:41 UTC (permalink / raw)
Cc: damien_terrier, emacs-devel
Each additional level of menu makes a command harder to invoke.
It is a major practical nuisance.
The current menu scheme puts many of the search commands in the menu 2
levels down, and the rest at level 3. By contrast, this scheme
Edit
-> Search and Replace
-> Incremental Search
-> Forward
-> I-Search Forward ...
-> I-Search Regexp Forward ...
-> Backwards
-> I-Search Backwards ...
-> I-Search Regexp Backwards ...
-> Non-Incremental Search
-> Forward
-> Search Forward ...
-> Search Regexp Forward ...
-> Backwards
-> Search Backwards ...
-> Search Regexp Backwards ...
puts the most important commands 4 levels down.
That is a big step for the worse.
By the way, I now remember why we made the nonincremental search
commands more prominent in the menus. It is because this is the sort
of search command that beginners are accustomed to from other editors.
We figured that people doing a search with the mouse would prefer to
get something they are used to, and that people who want incremental
search would invoke it from the keyboard.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-12 16:41 ` Richard Stallman
@ 2002-09-12 21:26 ` Kim F. Storm
2002-09-13 7:40 ` Urban Engberg
2002-09-13 19:33 ` Richard Stallman
0 siblings, 2 replies; 16+ messages in thread
From: Kim F. Storm @ 2002-09-12 21:26 UTC (permalink / raw)
Cc: damien_terrier, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> Each additional level of menu makes a command harder to invoke.
> It is a major practical nuisance.
I agree.
>
> The current menu scheme puts many of the search commands in the menu 2
> levels down, and the rest at level 3. By contrast, this scheme
> [...]
> puts the most important commands 4 levels down.
> That is a big step for the worse.
Definitely. But that doesn't mean that we cannot restructure the
Search submenus to make them more logical without increasing
the depth (quite the opposite!).
> We figured that people doing a search with the mouse would prefer to
> get something they are used to, and that people who want incremental
> search would invoke it from the keyboard.
That sound perfectly reasonable -- activating I-search through a menu
doesn't make much sense IMO.
Here is a proposal for a new organization which I find more intuitive:
First we put separate "Search" and "Replace" items directly on the
"Edit" menu; this is common practice in other editors:
Edit
...
Search >
Replace >
The "Search" submenu first presents the non-interactive search
choices, then the tags search, and finally the Incremental search
which leads to a submenu with the I-search related searches
Edit
Search > Forward String
Backward String ...
Forward Regexp ...
Backward Regexp ...
------------------
Repeat search (string or regexp!)
Repeat backwards (string or regexp!)
------------------
Search tagged files ...
Continue search
------------------
Incremental search > Forward String
Backward String ...
Forward Regexp ...
Backward Regexp ...
Replace > Replace String ...
Replace Regexp ...
-----------------------
Replace in tagged files
Continue replace
With this layout, all search and replace commands are on level 2
except for Isearch which is on level 3.
IMHO this is a change to the better - fewer levels overall and much
simpler to navigate than the current "Edit->Search" submenu.
WDYT?
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-12 21:26 ` Kim F. Storm
@ 2002-09-13 7:40 ` Urban Engberg
2002-09-13 19:33 ` Richard Stallman
1 sibling, 0 replies; 16+ messages in thread
From: Urban Engberg @ 2002-09-13 7:40 UTC (permalink / raw)
Cc: rms, damien_terrier, emacs-devel
Kim Storm writes:
> With this layout, all search and replace commands are on level 2
> except for Isearch which is on level 3.
In my opinion, incremental search is a major selling factor of Emacs
-- it's always one of the first things I show people, when introducing
them to Emacs, and which most people tend to understand very quickly.
On the other hand, regular expressions are seldom something new users
will be using. So, I think an even better layout would be:
Edit
Search > Forward...
Backward...
Forward Incremental...
Backward Incremental...
-----------------------
Repeat Forward
Repeat Backward
-----------------------
Search Tagged Files...
Continue Search
-----------------------
Regexp Search > Forward...
Backward...
Forward Incremental...
Backward Incremental...
Replace > Replace String...
Replace Regexp...
-----------------------
Replace in tagged files
Continue replace
i.e., with all search and isearch commands on level 2 and regexp on
level 3.
(I would even put incremental search at the top, persuading new users
to try it out -- but that's not overly important).
--
Urban Engberg * ue@ccieurope.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-12 21:26 ` Kim F. Storm
2002-09-13 7:40 ` Urban Engberg
@ 2002-09-13 19:33 ` Richard Stallman
2002-09-15 22:40 ` Kim F. Storm
1 sibling, 1 reply; 16+ messages in thread
From: Richard Stallman @ 2002-09-13 19:33 UTC (permalink / raw)
Cc: damien_terrier, emacs-devel
Edit
Search > Forward String
Backward String ...
Forward Regexp ...
Backward Regexp ...
------------------
Repeat search (string or regexp!)
Repeat backwards (string or regexp!)
------------------
Search tagged files ...
Continue search
------------------
Incremental search > Forward String
Backward String ...
Forward Regexp ...
Backward Regexp ...
Replace > Replace String ...
Replace Regexp ...
-----------------------
Replace in tagged files
Continue replace
I like this.
The tooltip string for Incremental Search can say why it is better
and recommend using the keyboard to run it.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [LONG] Some thougths and a patch for the search menu-bar functions
2002-09-13 19:33 ` Richard Stallman
@ 2002-09-15 22:40 ` Kim F. Storm
2002-09-16 13:43 ` Kai Großjohann
2002-09-17 19:14 ` Damien Terrier
0 siblings, 2 replies; 16+ messages in thread
From: Kim F. Storm @ 2002-09-15 22:40 UTC (permalink / raw)
Cc: damien_terrier, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> Edit
>
> Search > Forward String
> Backward String ...
> Forward Regexp ...
> Backward Regexp ...
> ------------------
> Repeat search (string or regexp!)
> Repeat backwards (string or regexp!)
> ------------------
> Search tagged files ...
> Continue search
> ------------------
> Incremental search > Forward String
> Backward String ...
> Forward Regexp ...
> Backward Regexp ...
>
> Replace > Replace String ...
> Replace Regexp ...
> -----------------------
> Replace in tagged files
> Continue replace
>
>
> I like this.
I took that as a "go ahead" - and changed it.
>
> The tooltip string for Incremental Search can say why it is better
> and recommend using the keyboard to run it.
I think this is a good idea, but I couldn't find a tool tip text which
was both short and informative, so I didn't do this.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2002-09-18 17:26 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-10 8:42 [LONG] Some thougths and a patch for the search menu-bar functions Damien Terrier
2002-09-10 11:36 ` Robert J. Chassell
2002-09-10 19:30 ` Thien-Thi Nguyen
2002-09-10 11:47 ` Robert J. Chassell
2002-09-10 12:24 ` Robert J. Chassell
2002-09-11 1:13 ` Miles Bader
2002-09-11 20:46 ` Kim F. Storm
2002-09-12 16:41 ` Richard Stallman
2002-09-12 21:26 ` Kim F. Storm
2002-09-13 7:40 ` Urban Engberg
2002-09-13 19:33 ` Richard Stallman
2002-09-15 22:40 ` Kim F. Storm
2002-09-16 13:43 ` Kai Großjohann
2002-09-17 15:53 ` Richard Stallman
2002-09-17 19:14 ` Damien Terrier
2002-09-18 17:26 ` Richard Stallman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.