[LONG] Some thougths and a patch for the search menu-bar functions

[LONG] Some thougths and a patch for the search menu-bar functions

[Damien Terrier]

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

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Robert J. Chassell]

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

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Robert J. Chassell]

    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

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Robert J. Chassell]

    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

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Thien-Thi Nguyen]

"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

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Miles Bader]

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]

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Kim F. Storm]

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

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Richard Stallman]

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.

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Kim F. Storm]

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

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Urban Engberg]

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

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Richard Stallman]

     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.

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Kim F. Storm]

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

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> 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.

"Gives feedback on (partial) search strings as they are typed."

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Richard Stallman]

    > 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.

    "Gives feedback on (partial) search strings as they are typed."

I wrote a tool tip for it, partly inspired by that text.
Thanks.

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Damien Terrier]

--- "Kim F. Storm" <storm@cua.dk> wrote:
> Richard Stallman <rms@gnu.org> writes:
> > 
> > I like this.
> 
> I took that as a "go ahead" - and changed it.

Thank you all for your work

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com

Re: [LONG] Some thougths and a patch for the search menu-bar functions

[Richard Stallman]

    Thank you all for your work

Thank you for helping it...would you perhaps like to help more?