Suggestions for the temporary windows used from the minibuffer

Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

For many commands using the minibuffer an extra temporary window is 
used, for example with C-h ? or with completions. I think it would be 
very nice if in all these the same keyboard command was used to scroll 
that extra window and to move into that window.

How about using <prior> and <next> (on w32 that is Page Up/Down) for 
scrolling that extra window? Could C-M-x o be used to move to that extra 
(other) window? Or maybe Tab since that is easier to type? (For 
completions an extra Tab could be used.)

RE: Suggestions for the temporary windows used from the minibuffer

[Drew Adams]

On a slightly related subject -

Commands scroll-other-window and scroll-other-window-down manipulate the
"other" window, if it exists. If it doesn't, they do nothing. That makes
sense for the commands, but not for the keys they are bound to.

Keys are limited, and handy pairs of keys like (<M-next>, <M-prior>) and
(C-M-v, C-M-S-v) are even more limited. It's a shame to bind such keys to
commands that do nothing when there is no "other" window. Especially for
people who use non-nil pop-up-frames. (Yes, of course people can rebind the
keys, but...)

What about:

For keys that are bound to commands that manipulate the "other" window (not
commands that open another window, but commands that use an existing one),
bind them instead to commands that do the same thing when there is another
window, but let the user do something else, otherwise? For instance, instead
of binding C-M-v and M-next to scroll-other-window, bind them to something
like scroll-other-window-or-*:

(defun scroll-other-window-or-* (&optional arg)
  "If other window, scroll-other-window; else, s-o-w-alternate."
  (interactive "p")
  (if (or (not (one-window-p)) other-window-scroll-buffer)
      (scroll-other-window arg)
    (funcall 's-o-w-alternate arg)))

Then, users and libraries can do (setq s-o-w-alternate-fn 'foo-command).
They don't have to rebind the various keys to foo-command, and they don't
lose the other-window functionality whenever it is truly available.

I know this smells like a crazy, ugly hack, but perhaps it could be useful?

Of course, instead of creating a scroll-other-window-or-* command, the
original command could be changed in the same way: instead of doing nothing
when no other window, run another command (~hook).

Another, weirder possibility would be to treat the existence of an open
other window as a minor mode, and bind the scroll-other-* commands only in
that mode.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    For keys that are bound to commands that manipulate the "other" window (not
    commands that open another window, but commands that use an existing one),
    bind them instead to commands that do the same thing when there is another
    window, but let the user do something else, otherwise? For instance, instead
    of binding C-M-v and M-next to scroll-other-window, bind them to something
    like scroll-other-window-or-*:

The basic idea that these keys could do something else as a
possibly-useful fallback might be good.  I don't like that specific
proposal because it is rather complex to use.  I'd rather have something
that is natural and useful for beginners.

RE: Suggestions for the temporary windows used from the minibuffer

[Drew Adams]

        For keys that are bound to commands that manipulate the
        "other" window, bind them instead
        to commands that do the same thing when there is another
        window, but let the user do something else, otherwise?

    The basic idea that these keys could do something else as a
    possibly-useful fallback might be good.  I don't like that specific
    proposal because it is rather complex to use.  I'd rather have something
    that is natural and useful for beginners.

I agree, actually.

If, instead of creating new commands, the existing command definitions were
simply changed to effect an alternative behavior (~ a hook) when there is no
"other" window, then that would simplify the implementation, at least.

If the "hook" (alternative behavior) were null by default, then beginners
would not be affected at all - they would not be aware of the new
possibility. If the "hook" had, instead, a reasonable default behavior, then
that could be natural for beginners, although they might not know how to
change the alternative behavior (nor would they need to).

But if the keys have different behavior, depending on whether or not there
is an "other" window, that in itself could be confusing to beginners - I
think that's your point. One solution is that mentioned above: the
alternative behavior would be null, by default - that is natural for
beginners, but it is no more useful to them than the current behavior.

How else to make it natural for the same keys to have different behavior,
depending on the circumstances? Use a mode: the presence of an "other"
window would manifest a different mode (minor). Modes are not 100% natural
to beginners, but they are fairly common in Emacs.

But of course the existence or absence of an "other" window is not the usual
way of toggling a minor mode - that could be confusing.

Confusion could be minimized if the alternative commands were complementary
in their use to the current commands, in some way. For example, if they only
made sense when there is no "other" window, then no one would mistakenly use
one when trying to use the other. However, I can't think of any commands
that make sense only when there is no "other" window.

Anyone have a good idea for this?

If we find no good alternative behavior for beginners, would it hurt to at
least redefine the commands to allow non-beginners to supply alternative
behaviors (e.g. via a quasi-hook)? That is, use a null behavior by default,
but let people supply an alternative.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    If, instead of creating new commands, the existing command definitions were
    simply changed to effect an alternative behavior (~ a hook) when there is no
    "other" window, then that would simplify the implementation, at least.

Such a hook is not worth adding.  A specific useful fallback behavior
might be worth adding.

But please let's wait until after the release to discuss this.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

     I think it would be 
    very nice if in all these the same keyboard command was used to scroll 
    that extra window and to move into that window.

Isn't that already the case?  C-M-v should always scroll it.

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Richard M. Stallman wrote:

>    Rob Davenport has made MS Windows icons for Emacs from the current logo 
>    by Luise Fernandes.
>
>Sorry, what does "the current logo by Luise Fernandes" mean?
>  
>
Sorry, I spelt his name wrong. It should be "Luis Fernandes". He has 
made the logo in red and blue that you see if you open emacs with "emacs 
-q --no-site-file" on a window system (or at least in w32).

>You say "icons", plural.  For what purposes do you intend to use thes
>icons?  And why can't we use the icons that are already installed in
>Emacs?
>  
>
Rob Davenport has made icons from the logo. It is not very easy to make 
good logos since they are so small. On w32 an icon file my contain 
images of different sizes, normally 16x16 pixels, 32x32 and sometimes 
48x48. Often 16x16 is what you most often see.

Because of struggle with this and to be helpful I guess Rob has made 
several versions based on the logo. They use different parts of the logo 
and different colors. There is also one including the whole logo, but do 
not think it is not recognizeable when it small as icons are.

To give a view of them I have uploaded screen shots to 
http://ourcomments.org/Emacs/NewIcons.html.

My purpose was to include the icon in emacs.exe etc on w32. The current 
icon is also shown on the page above.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    Sorry, I spelt his name wrong. It should be "Luis Fernandes".

Surely you don't expect me to remember the name of the person who made
the icon!  The reliable way to identify this image is "the image
displayed in the Emacs fancy start-up screen".  (If I understand you
correctly, that is.)

    Rob Davenport has made icons from the logo. It is not very easy to make 
    good logos since they are so small.

Icons are used to give users something to click on.  How do you
propose to use these icons?  Where will they be displayed?  What will
they do, when the user clicks on them?

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Richard M. Stallman wrote:

>    Sorry, I spelt his name wrong. It should be "Luis Fernandes".
>
>Surely you don't expect me to remember the name of the person who made
>the icon!  The reliable way to identify this image is "the image
>displayed in the Emacs fancy start-up screen".  (If I understand you
>correctly, that is.)
>  
>
Yes.

>    Rob Davenport has made icons from the logo. It is not very easy to make 
>    good logos since they are so small.
>
>Icons are used to give users something to click on.  How do you
>propose to use these icons?  Where will they be displayed?  What will
>they do, when the user clicks on them?
>
Maybe they are not only there to click on? Are they not also a tool for 
organising the visiual view and to give an impression?

On w32 the icons would be stored in emacs.exe and emacsclient.exe. Those 
icon then shows up in a lot of situations:

1) When you view a w32 directory list or file box that includes them.
2) When you view any such list or file box with files that are 
"associated" with any of those exe files. Clicking on them will 
(hopefully) take the action tied to the association (like opening the 
files with emacsclient).
3) On the w32 shortcuts pointing to the exe files. On those you can 
click to start running the exe files. You may most often also use drag 
and drop.

I am not sure if this answer is helpful to you, but since the 
communication delay is quite long I preferred to bit what I think is a 
bit elaborate.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    Maybe they are not only there to click on? Are they not also a tool for 
    organising the visiual view and to give an impression?

The term "icon" normally means an image that you click on and it does
something.  Images that aren't used this way usually aren't called
"icons".

    On w32 the icons would be stored in emacs.exe and emacsclient.exe. Those 
    icon then shows up in a lot of situations:

    1) When you view a w32 directory list or file box that includes them.
    2) When you view any such list or file box with files that are 
    "associated" with any of those exe files. Clicking on them will 
    (hopefully) take the action tied to the association (like opening the 
    files with emacsclient).

I think I understand now.  Thanks for the explanation.  It sounds like
these ARE icons, in the sense I thought the word meant; clicking on
these images opens or activates the files, right?

I don't think Emacs should features on Windows that are not supported
on GNU/Linux.  That would distort Emacs into a Windows application
and defeat the purpose of our work.

Does GNOME have a similar feature which could use the same icons?

Re: Suggestions for the temporary windows used from the minibuffer

[Jan D.]

>
>     On w32 the icons would be stored in emacs.exe and  
> emacsclient.exe. Those
>     icon then shows up in a lot of situations:
>
>     1) When you view a w32 directory list or file box that includes  
> them.
>     2) When you view any such list or file box with files that are
>     "associated" with any of those exe files. Clicking on them will
>     (hopefully) take the action tied to the association (like  
> opening the
>     files with emacsclient).
>
> I think I understand now.  Thanks for the explanation.  It sounds like
> these ARE icons, in the sense I thought the word meant; clicking on
> these images opens or activates the files, right?
>
> I don't think Emacs should features on Windows that are not supported
> on GNU/Linux.  That would distort Emacs into a Windows application
> and defeat the purpose of our work.
>
> Does GNOME have a similar feature which could use the same icons?

The GNOME file handler lets you associate icons with applications so  
in principle the same images can be used for this.  GNOME already has  
a gnome-emacs icon though.


     Jan D.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    The GNOME file handler lets you associate icons with applications so  
    in principle the same images can be used for this.  GNOME already has  
    a gnome-emacs icon though.

That is good to know.  (Can you email me the gnome-emacs icon image?)

Re: Suggestions for the temporary windows used from the minibuffer

[Jan D.]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]


>     The GNOME file handler lets you associate icons with  
> applications so
>     in principle the same images can be used for this.  GNOME  
> already has
>     a gnome-emacs icon though.
>
> That is good to know.  (Can you email me the gnome-emacs icon image?)

Attached.

     Jan D.

[-- Attachment #2: gnome-emacs.png --]
[-- Type: image/png, Size: 4589 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    > That is good to know.  (Can you email me the gnome-emacs icon image?)

That image is a picture of a gnu.  That is not really right for this
purpose, which is to distinguish Emacs within a context including
other GNU programs (such as GNOME itself).

So it would be good to replace this; however, I am not sure with what.
There is no particular logo associated with Emacs.

Re: Suggestions for the temporary windows used from the minibuffer

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > That is good to know.  (Can you email me the gnome-emacs icon image?)
>
> That image is a picture of a gnu.  That is not really right for this
> purpose, which is to distinguish Emacs within a context including
> other GNU programs (such as GNOME itself).
>
> So it would be good to replace this; however, I am not sure with what.
> There is no particular logo associated with Emacs.

There is some sort of kitchen sink icon somewhere, but it is really
ugly, and I doubt that people associate Emacs with that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Richard M. Stallman wrote:

>    > That is good to know.  (Can you email me the gnome-emacs icon image?)
>
>That image is a picture of a gnu.  That is not really right for this
>purpose, which is to distinguish Emacs within a context including
>other GNU programs (such as GNOME itself).
>
>So it would be good to replace this; however, I am not sure with what.
>There is no particular logo associated with Emacs.
>  
>
With my earlier mail there where two suggestions from different people. 
One of these where based on the splash screen that we can see in CVS 
Emacs today. I thought that the picture there was an Emacs logo?

When considering new icons for Emacs please keep in mind that those must 
be able to make very small. On w32 the small icons are just 16x16 
pixels. That very small icon is shown in the upper left of every window 
(Emacs frame). Big size icons on w32 are 32x32 (or even 48x48 
sometimes). What sizes are they on GNU/Linux?

If anyone can not see them on the webpage where I have put them then I 
can mail the pictures.

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

Richard M. Stallman wrote:

>    > That is good to know.  (Can you email me the gnome-emacs icon image?)
>
>That image is a picture of a gnu.  That is not really right for this
>purpose, which is to distinguish Emacs within a context including
>other GNU programs (such as GNOME itself).
>
>So it would be good to replace this; however, I am not sure with what.
>There is no particular logo associated with Emacs.
>  
>
I have attached pictures of some icons. These tries to combine the 
splash logo found today in Emacs with some ideas from Drew. The icons 
needs some finishing though.

[-- Attachment #2: gnu-m-x-small.jpg --]
[-- Type: image/jpeg, Size: 4787 bytes --]

[-- Attachment #3: gnu-m-x-big.jpg --]
[-- Type: image/jpeg, Size: 7130 bytes --]

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

Thanks for taking a stab at it.  I am not sure that M-x is the best
way to indicate Emacs; but it occurs to me that if M-x can be included
visibly in an icon, then we could have an icon that says

  EM
  ACS

(although I'd center the top line above the second line)

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

Richard M. Stallman wrote:

>Thanks for taking a stab at it.  I am not sure that M-x is the best
>way to indicate Emacs; but it occurs to me that if M-x can be included
>visibly in an icon, then we could have an icon that says
>
>  EM
>  ACS
>
>(although I'd center the top line above the second line)
>  
>
I have attached an 16x16 image using this idea. It is quite hard to make 
it readable.

Personally I am not very fond of it but I send it for discussion. It 
looks rather boring to me and the connection with GNU is removed, but 
the advantage is perhaps that it is clear and that it uses the wellknown 
name Emacs.

[-- Attachment #2: emacs-txt-5.png --]
[-- Type: image/png, Size: 643 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Suggestions for the temporary windows used from the minibuffer

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Richard M. Stallman wrote:
>
>>Thanks for taking a stab at it.  I am not sure that M-x is the best
>>way to indicate Emacs; but it occurs to me that if M-x can be included
>>visibly in an icon, then we could have an icon that says
>>
>>  EM
>>  ACS
>>
>>(although I'd center the top line above the second line)
>>  
>>
> I have attached an 16x16 image using this idea. It is quite hard to
> make it readable.
>
> Personally I am not very fond of it

Me neither.  Not because of your artwork, but because I find the
design uninspiring, to say the least.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

David Kastrup wrote:

>Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>  
>
>>Richard M. Stallman wrote:
>>
>>    
>>
>>>Thanks for taking a stab at it.  I am not sure that M-x is the best
>>>way to indicate Emacs; but it occurs to me that if M-x can be included
>>>visibly in an icon, then we could have an icon that says
>>>
>>> EM
>>> ACS
>>>
>>>(although I'd center the top line above the second line)
>>> 
>>>
>>>      
>>>
>>I have attached an 16x16 image using this idea. It is quite hard to
>>make it readable.
>>
>>Personally I am not very fond of it
>>    
>>
>
>Me neither.  Not because of your artwork, but because I find the
>design uninspiring, to say the least.
>  
>
Yes, more inspiration needed. I have uploaded what has been suggested so 
far to http://ourcomments.org/Emacs/NewIcons.html. Personally i like the 
gnu+M-x best (but that is maybe because I made it ;-). Though the gnu 
reminds me a bit of a dog. Nothing bad with dogs but the image needs 
some finishing.

It is quite tought making anything with 16x16 pixels actually - don't 
know whether that is good or bad for inspiration and creativity here 
;-)  -- To me ideas for a logo should be thought of together with the 
icon. I do not know how other people feel about the splash logo now, but 
I like it. That does not mean there are other good alternatives of course!

Re: Suggestions for the temporary windows used from the minibuffer

[Frank Schmitt]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> It is quite tought making anything with 16x16 pixels actually - don't 
> know whether that is good or bad for inspiration and creativity here 
> ;-)  -- To me ideas for a logo should be thought of together with the 
> icon. I do not know how other people feel about the splash logo now, but 
> I like it. That does not mean there are other good alternatives of course!

Perhaps we should let other people who more often design icons have a
stab on it also. Have a look at how e.g. the KDE project handles this:
http://www.kde-look.org/index.php?xcontentmode=43

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Emacs icons

[Juri Linkov]

> Perhaps we should let other people who more often design icons have
> a stab on it also. Have a look at how e.g. the KDE project handles
> this: http://www.kde-look.org/index.php?xcontentmode=43

Don't let KDE people design Emacs icons.  They will create icons
with the program name changed to EMAKS :-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

The .png file that you sent has EM and ACS, but it also has a file name
or something that makes it much bigger.  Why did you include that?

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Richard M. Stallman wrote:

>The .png file that you sent has EM and ACS, but it also has a file name
>or something that makes it much bigger.  Why did you include that?
>  
>
So you can see how it actually can look in some situations where it is 
used. But to get a really good view you have to consider more situations 
so maybe it was unnecessary.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    >The .png file that you sent has EM and ACS, but it also has a file name
    >or something that makes it much bigger.  Why did you include that?
    >  
    >
    So you can see how it actually can look in some situations where it is 
    used.

Ah, now I understand.

The EM ACS icon seems ok to me, but maybe just an E will be better.

Re: Suggestions for the temporary windows used from the minibuffer

[Frank Schmitt]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

"Jan D." <jan.h.d@swipnet.se> writes:

>>> The GNOME file handler lets you associate icons with applications
>>> so in principle the same images can be used for this.  GNOME already
>>> has a gnome-emacs icon though.
>>
>> That is good to know.  (Can you email me the gnome-emacs icon image?)
>
> Attached.

Just for the sake of completeness: In KDE, emacs has an icon attached
too, it's 


[-- Attachment #2: emacs.png --]
[-- Type: image/png, Size: 2752 bytes --]

[-- Attachment #3: Type: text/plain, Size: 322 bytes --]



-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Suggestions for the temporary windows used from the minibuffer

[David Kastrup]

Frank Schmitt <ich@frank-schmitt.net> writes:

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>>>> The GNOME file handler lets you associate icons with applications
>>>> so in principle the same images can be used for this.  GNOME already
>>>> has a gnome-emacs icon though.
>>>
>>> That is good to know.  (Can you email me the gnome-emacs icon image?)
>>
>> Attached.
>
> Just for the sake of completeness: In KDE, emacs has an icon attached
> too, it's

[GNU head]

Maybe one should put a pen into the gnu's mouth.  But that is more
reminiscent of word processing rather than editing.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggestions for the temporary windows used from the minibuffer

[Frank Schmitt]

David Kastrup <dak@gnu.org> writes:

> [GNU head]
>
> Maybe one should put a pen into the gnu's mouth.  But that is more
> reminiscent of word processing rather than editing.

I'd rather go the line of what makes Emacs a special editor. Something
like a Gnu had floating above some typical key combinations like "C-c
M-x C-M-\" or one could go for the lisp, e.g. by a Gnu head enclosed in
two big parentheses.

Thinking again about it, I think I'd really like the second idea better.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Suggestions for the temporary windows used from the minibuffer

[David Kastrup]

Frank Schmitt <ich@frank-schmitt.net> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> [GNU head]
>>
>> Maybe one should put a pen into the gnu's mouth.  But that is more
>> reminiscent of word processing rather than editing.
>
> I'd rather go the line of what makes Emacs a special editor. Something
> like a Gnu had floating above some typical key combinations like "C-c
> M-x C-M-\" or one could go for the lisp, e.g. by a Gnu head enclosed in
> two big parentheses.
>
> Thinking again about it, I think I'd really like the second idea
> better.

Gnu horns are already like parentheses.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Emacs icons (was: Suggestions for the temporary windows used from the minibuffer)

[Drew Adams]

    I'd rather go the line of what makes Emacs a special editor. Something
    like a Gnu had floating above some typical key combinations like "C-c
    M-x C-M-\" or one could go for the lisp, e.g. by a Gnu head enclosed in
    two big parentheses.

Why not just text? No sinks, antelopes or genetically modified 'shrooms.

How about  ESC M-a   (EMaCS, jumbled)

           s
Or  E = m c          (for relativity fans)
         a

Or  e M-a C-s GNU    (recherche GNU desesperemment?)

             gnu
Or  e M-a C-s        (to the power of GNU)


Or just  e M-a C-s   (it's a simple editor)


(or C-/ vi? - nah, we're way beyond that)

Re: Emacs icons (was: Suggestions for the temporary windows used from the minibuffer)

[Richard M. Stallman]

	       s
    Or  E = m c          (for relativity fans)
	     a

It is a nice idea, but can that much be expressed clearly in so few
pixels?  I think probably not.

RE: Emacs icons (was: Suggestions for the temporary windows usedfrom the minibuffer)

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2392 bytes --]

    	             s
        Or  E = m c          (for relativity fans)
    	           a

    It is a nice idea, but can that much be expressed clearly in so few
    pixels?  I think probably not.

No, surely not. I was partly kidding.

My serious 2 cents:

- Understandability and recognizability are #1 for icons. Representativeness
is #2. Aesthetics is #3 - it works only if #1 & 2 work. Forget about Grandma
Moses; aim for clear, simple, and catchy.

- Icons are not logos - you can only show so much in an icon. Save the fancy
gnu for an Emacs logo, perhaps combining it with something that represents
Emacs itself (see below).

- There is no reason to put a gnu on the Emacs icon. There is no room; it
won't be recognizable; it's not necessary. GNU will ultimately have lots of
apps and features - it makes no sense to put a gnu on the icon for each. If
GNU itself were an app, it could have a gnu icon (if it could be made
recognizable).

- Complex images don't work in icons. Remember the gnu that became a
mushroom - great folklore, but otherwise, not a great icon. Firefox's icon
is also bad, as an example - you can't recognize the animal etc.

- The best symbol for Emacs is plain, typewriter-font _text_. A single
letter is good as a representation of a text editor (no flames about how
Emacs is so much more). "E" for Emacs is good, clear, and recognizable.
Don't add anything else (no pencils, notepads, or gnus). Make it stand out,
so it screams "EMACS" - nothing else. The icon's tooltip can say "GNU
Emacs" - no need to show "GNU" or a gnu on the icon itself.

- An Emacs logo (not an icon) along the lines I suggested earlier
(relativity, e M-a Cs, M-x, etc.) would be OK, but it would not make a good
icon (too small - see attached). Possible logo: a large "E" and a small
"M-x" under it (or a small "M-a C-s" under it). If such a logo is used
everywhere for Emacs (e.g. splash screen), then the corresponding icon
should have just the "E", and it should use the same font and color scheme.

- I like a red E on a bright green background. In a year, RMS would have a
green T-shirt with a HUGE red E on the front and a prancing gnu on the back
with the Emacs relativity equation (or with just "M-x").

- Some E icons are attached. (Also two e M-a C-s icons, showing that the
text is just too small. It would be the same for "relativity Emacs".) Sorry
for the GIF format.



[-- Attachment #2: emacs-E-embossed-brightgreen.gif --]
[-- Type: image/gif, Size: 876 bytes --]

[-- Attachment #3: emacs-E-red-green-boxed.gif --]
[-- Type: image/gif, Size: 863 bytes --]

[-- Attachment #4: emacs-E-red-green-split-horiz.gif --]
[-- Type: image/gif, Size: 858 bytes --]

[-- Attachment #5: emacs-E-red-green-split-vert.gif --]
[-- Type: image/gif, Size: 865 bytes --]

[-- Attachment #6: emacs-E-red-green.gif --]
[-- Type: image/gif, Size: 856 bytes --]

[-- Attachment #7: emacs-M-x-C-s-16x16.gif --]
[-- Type: image/gif, Size: 941 bytes --]

[-- Attachment #8: emacs-M-x-C-s-16x16-black.gif --]
[-- Type: image/gif, Size: 934 bytes --]

[-- Attachment #9: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs icons (was: Suggestions for the temporary windows usedfrom the minibuffer)

[Richard M. Stallman]

    - The best symbol for Emacs is plain, typewriter-font _text_. A single
    letter is good as a representation of a text editor (no flames about how
    Emacs is so much more). "E" for Emacs is good, clear, and recognizable.

Just an E is an idea worth trying.  For the usual reasons, we can't
use the icons that you made, but others could make E icons.

    - I like a red E on a bright green background. In a year, RMS would have a
    green T-shirt with a HUGE red E on the front and a prancing gnu on the back
    with the Emacs relativity equation (or with just "M-x").

No, because I don't wear shirts with words on them.

RE: Emacs icons (was: Suggestions for the temporary windowsusedfrom the minibuffer)

[Drew Adams]

        - The best symbol for Emacs is plain, typewriter-font _text_.
          A single letter is good as a representation of a text editor
          (no flames about how Emacs is so much more). "E" for Emacs
          is good, clear, and recognizable.
    
    Just an E is an idea worth trying.  For the usual reasons, we can't
    use the icons that you made, but others could make E icons.

Right; I expected that.
Anyone's E is at least as good as mine, anyway ;-).
    
        - I like a red E on a bright green background. In a year, 
          RMS would have a green T-shirt with a HUGE red E on the
          front and a prancing gnu on the back
          with the Emacs relativity equation (or with just "M-x").
    
    No, because I don't wear shirts with words on them.

So particular! (Nor wordy tatoos, no doubt.)
But I like the idea that "M-x" is a word.    

Re: Emacs icons

[Esben Stien]

"Drew Adams" <drew.adams@oracle.com> writes:

> Why not just text? 

I think this is really bad. No icons or logos' should ever just use
text (or even characters at all); it's too hard to distinguish if more
and more apps do this. An icon should not be read. It's supposed to be
an image which you combine with something very quickly. Also, it
should be a SVG vector file. Gnome is supposedly moving to a vector
graphics only desktop.

-- 
Esben Stien is b0ef@e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
          [sip|iax]:   e     e 
           jid:b0ef@    n     n

Re: Emacs icons

[Lennart Borgman]

Esben Stien wrote:

>"Drew Adams" <drew.adams@oracle.com> writes:
>
>  
>
>>Why not just text? 
>>    
>>
>
>I think this is really bad. No icons or logos' should ever just use
>text (or even characters at all); it's too hard to distinguish if more
>and more apps do this. An icon should not be read. It's supposed to be
>an image which you combine with something very quickly. Also, it
>should be a SVG vector file. Gnome is supposedly moving to a vector
>graphics only desktop.
>  
>
I think you are right, but I believe the intention was perhaps not to 
have text that should be read. It should be more like a logo. The 
problem is however to get some good ideas for a logo that can be 
realized as such small images that icons normally are (16x16 pixels on 
w32). Suggestions and examples are welcome. I will try to put them all 
here: http://ourcomments.org/Emacs/NewIcons.html

Can vector graphics be scaled to such small images ( is the result 
good)? What tools are used to create the SVG files?

Re: Emacs icons

[Esben Stien]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Can vector graphics be scaled to such small images

Well, it's vector;)

> What tools are used to create the SVG files?

inkscape

-- 
Esben Stien is b0ef@e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
          [sip|iax]:   e     e 
           jid:b0ef@    n     n

Re: Emacs icons

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

Esben Stien wrote:

>"Drew Adams" <drew.adams@oracle.com> writes:
>
>  
>
>>Why not just text? 
>>    
>>
>
>I think this is really bad. No icons or logos' should ever just use
>text (or even characters at all); it's too hard to distinguish if more
>and more apps do this. An icon should not be read. It's supposed to be
>an image which you combine with something very quickly. Also, it
>should be a SVG vector file. Gnome is supposedly moving to a vector
>graphics only desktop.
>  
>
Some more suggestions. Don't look at them as finished images. Think 
instead that we are in a creative phase. I have also added them to the 
web page I mentioned earlier. If someone has suggestions just mail me 
the images and I will put them there.

[-- Attachment #2: more-2.png --]
[-- Type: image/png, Size: 2815 bytes --]

[-- Attachment #3: more-1.png --]
[-- Type: image/png, Size: 1334 bytes --]

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs icons

[Richard M. Stallman]

The idea of using an E on a gnu is ok semantically.  Whether it looks
better than just an E, I am not sure.

Re: Emacs icons

[David Ponce]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

Richard M. Stallman wrote:
> The idea of using an E on a gnu is ok semantically.  Whether it looks
> better than just an E, I am not sure.

Attached is an idea ;-)
It don't look too bad when resized as a 16x16 icon.

David

[-- Attachment #2: emacs48x48-4.xpm --]
[-- Type: image/x-xpixmap, Size: 8204 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs icons

[Lennart Borgman]

David Ponce wrote:

> Richard M. Stallman wrote:
>
>> The idea of using an E on a gnu is ok semantically.  Whether it looks
>> better than just an E, I am not sure.
>
>
> Attached is an idea ;-)
> It don't look too bad when resized as a 16x16 icon.
>
> David

If you have not seen the web page it is here: 
http://ourcomments.org/Emacs/NewIcons.html

I have put both your original icons there and some mangles I have done 
of them.

Re: Emacs icons

[Richard M. Stallman]

The E is too hard to see.

It would be better to have just an E.

RE: Emacs icons

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

    > The idea of using an E on a gnu is ok semantically.  Whether it looks
    > better than just an E, I am not sure.

    Attached is an idea ;-) It don't look too bad when resized as a 16x16
icon.

This could make an attractive _logo_, but it would _not_ work as a 16x16
icon, IMO (see attached). Clever combination of E with gnu head - bravo!
But, as Richard pointed out, that makes it hard to distinguish the E.

Let's not forget the story of "The Gnu Who Became a Mushroom" - that's an
invaluable icon lesson. If shrinking a gnu head can turn it into a mushroom,
there is no hope for shrinking E-gnus and other such artistic subtleties. In
particular, shrunken heads seldom appear brilliant.

16x16 is a hard nut to crack.

[-- Attachment #2: ponce-emacs-16x16.gif --]
[-- Type: image/gif, Size: 927 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs icons

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

Drew Adams wrote:

>    > The idea of using an E on a gnu is ok semantically.  Whether it looks
>    > better than just an E, I am not sure.
>
>    Attached is an idea ;-) It don't look too bad when resized as a 16x16
>icon.
>
>This could make an attractive _logo_, but it would _not_ work as a 16x16
>icon, IMO (see attached). Clever combination of E with gnu head - bravo!
>But, as Richard pointed out, that makes it hard to distinguish the E.
>
>Let's not forget the story of "The Gnu Who Became a Mushroom" - that's an
>invaluable icon lesson. If shrinking a gnu head can turn it into a mushroom,
>there is no hope for shrinking E-gnus and other such artistic subtleties. In
>particular, shrunken heads seldom appear brilliant.
>
>16x16 is a hard nut to crack.
>  
>
Maybe it is possible to shrink it. I made several versions of Robs gnu 
head in the size of 16x16 (together with M-x).

Here are some variations of Davids suggestion where I have tried to make 
the E more visible.

[-- Attachment #2: emacs48x48-3.png --]
[-- Type: image/png, Size: 3344 bytes --]

[-- Attachment #3: emacs48x48-4.png --]
[-- Type: image/png, Size: 3360 bytes --]

[-- Attachment #4: emacs48x48-5.png --]
[-- Type: image/png, Size: 3327 bytes --]

[-- Attachment #5: emacs48x48-8.png --]
[-- Type: image/png, Size: 3455 bytes --]

[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs icons

[Frank Schmitt]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Here are some variations of Davids suggestion where I have tried to make 
> the E more visible.

Those look all really nice, especially the third one.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Emacs icons

[Richard M. Stallman]

    Maybe it is possible to shrink it. I made several versions of Robs gnu 
    head in the size of 16x16 (together with M-x).

Please don't get diverted onto this.  There is no need for a gnu head
in an Emacs icon.  Its job is to say "Emacs", not "GNU".

Re: Emacs icons

[Werner LEMBERG]

> Maybe it is possible to shrink it. I made several versions of Robs
> gnu head in the size of 16x16 (together with M-x).

Congrats!  Those icons a *really* good IMHO.  I suggest that you stay
with the same red/blue color combination as used for the Emacs splash
screen.


    Werner

Re: Emacs icons

[Gian Uberto Lauri]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

Hmm... I use the attached image with WindowMaker, it's the splash image shrinked
to 48x48.

I add a reduced 16x16 icon...

-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

[-- Attachment #2: emacs.png --]
[-- Type: image/png, Size: 3330 bytes --]

[-- Attachment #3: emacs-16.png --]
[-- Type: image/png, Size: 940 bytes --]

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs icons

[Lennart Borgman]

Gian Uberto Lauri wrote:

>Hmm... I use the attached image with WindowMaker, it's the splash image shrinked
>to 48x48.
>
>I add a reduced 16x16 icon...
>  
>
Thanks. I have added your icon suggestions to 
http://ourcomments.org/Emacs/NewIcons.html . That web page is growing, I 
had to fix it a bit to make it readable again ... ;-)

Re: Emacs icons

[Richard M. Stallman]

    Hmm... I use the attached image with WindowMaker, it's the splash image s=
    hrinked
    to 48x48.

This approach is going in the wrong direction.  It is too hard to see,
and it doesn't focus on the important thing, which is "Emacs".

I ask everyone to please NOT send any more proposed icons that are
based on a picture of a gnu.  All such pictures are too complex, and
unusable.  Please save your time and mine by not proposing such
pictures.  The most that might work is the partial gnu picture
combined with an E.

By the way, I see people sending both 48x48 and 16x16 icons.
When is the 48x48 used, and when is the 16x16 used?

Re: Emacs icons

[Lennart Borgman]

Richard M. Stallman wrote:

>    Hmm... I use the attached image with WindowMaker, it's the splash image s=
>    hrinked
>    to 48x48.
>
>This approach is going in the wrong direction.  It is too hard to see,
>and it doesn't focus on the important thing, which is "Emacs".
>
>I ask everyone to please NOT send any more proposed icons that are
>based on a picture of a gnu.  All such pictures are too complex, and
>unusable.  Please save your time and mine by not proposing such
>pictures.  The most that might work is the partial gnu picture
>combined with an E.
>
>By the way, I see people sending both 48x48 and 16x16 icons.
>When is the 48x48 used, and when is the 16x16 used?
>  
>
I can only answer this for w32:

- In many cases the user can decide wether to use a small 16x16 icon or 
a bigger. This is for example the case in the w32 file manager called 
Explorer (or Windows Explorer).

- On the desktop a larger icon is used (32x32 or 48x48 I believe, maybe 
other size can be used too?).

- When switching between applications a larger icon is used.

- In the start menu you can choose. In the part showing active 
applications I think small icons are used.

- If file open/save dialog the small icons are normally used.

I believe the most common larger icon format is 32x32 but it might be 
bigger on XP, don't know.

Re: Emacs icons

[Gian Uberto Lauri]

>>>>> "RMS" == Richard M Stallman <rms@gnu.org> writes:

RMS> This approach is going in the wrong direction.  It is too hard to
RMS> see, and it doesn't focus on the important thing, which is
RMS> "Emacs".

Indeed, I did not notice it since I *knew* it was Emacs.

RMS> By the way, I see people sending both 48x48 and 16x16 icons.
RMS> When is the 48x48 used, and when is the 16x16 used?

Hmmm, I see 48x48 icons  in WindowMaker and GNUStep (applications) and
in Gnome and KDE icon sets. Mac OS X could use even larger ones.

As far I  remember, 16x16 are used in menus, "the  bar with start" and
in the task manager in Windows. If I'm not wrong KDE and GNOME use
them in their "start menu" and 16x16 is included in their icon sets.

-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e coltivatore diretto di software

Re: Emacs icons

[Frank Schmitt]

"Richard M. Stallman" <rms@gnu.org> writes:

> By the way, I see people sending both 48x48 and 16x16 icons.
> When is the 48x48 used, and when is the 16x16 used?

This is highly dependent on the window- or file manager used and
normally configurable to a certain degree by a user. Commonly used sizes
are:

16x16  20x20/  24x24  32x32  36x36  48x48  64x64  96x96

I'm really wondering that people are creating the icons as bitmap
images. The major desktop environments under Gnu Linux (Gnome, KDE,
XFCE) are currently switching to vector based images (svg) and as far as
I know the next version of MS Windows will do so to. (Using a mangled
version of the open format svg which will differ just so much to be
incompatible)

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Emacs icons

[Lennart Borgman]

Frank Schmitt wrote:

>"Richard M. Stallman" <rms@gnu.org> writes:
>  
>
>This is highly dependent on the window- or file manager used and
>normally configurable to a certain degree by a user. Commonly used sizes
>are:
>
>16x16  20x20/  24x24  32x32  36x36  48x48  64x64  96x96
>
>I'm really wondering that people are creating the icons as bitmap
>images. The major desktop environments under Gnu Linux (Gnome, KDE,
>XFCE) are currently switching to vector based images (svg) and as far as
>I know the next version of MS Windows will do so to. (Using a mangled
>version of the open format svg which will differ just so much to be
>incompatible)
>  
>
Thanks for the information. I did not know that SVG was going to be used 
everywhere. Then it looks like I good idea to make both bitmap and SVG 
versions. Do you have any idea of how to handle this?

I have seen there is an SVG plugin for Gimp. However I do not know about 
the internal format for Gimp, if that is a bitmap format and/or a vector 
format. If Gimp can make both SVG files, png and w32 ico format files 
from the same picture then we can solve this easily I guess. But that 
depends on how well Gimp can handle this. There may of course also be 
other options. Do you know anything about this?

Re: Emacs icons

[Frank Schmitt]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Thanks for the information. I did not know that SVG was going to be used 
> everywhere. Then it looks like I good idea to make both bitmap and SVG 
> versions. Do you have any idea of how to handle this?
>
> I have seen there is an SVG plugin for Gimp. However I do not know about 
> the internal format for Gimp, if that is a bitmap format and/or a vector 
> format. If Gimp can make both SVG files, png and w32 ico format files 
> from the same picture then we can solve this easily I guess. But that 
> depends on how well Gimp can handle this. There may of course also be 
> other options. Do you know anything about this?

If you want to create images in a vector format, you have to use a vector
based drawing tool, that means you have to leave Gimp behind and use
tools like Inkscape (this is the only mature free vector drawing program
I know but I'm no expert in this area).

Generally I still think we should give other groups a chance to offer
their ideas about the new icon. I mean, emacs-devel is read by coders
and not by artists. Of course many of the icons presented look really
nice, so there are people here who are both but still if you look at
the development of Gnome and KDE programs you will find out that there
are many people with exceptional artistic talents but with no talent for
(or no joy in) coding who like to contribute to free software
development.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Emacs icons

[Lennart Borgman]

Frank Schmitt wrote:

>If you want to create images in a vector format, you have to use a vector
>based drawing tool, that means you have to leave Gimp behind and use
>tools like Inkscape (this is the only mature free vector drawing program
>I know but I'm no expert in this area).
>  
>
And Incscape seems to be GNU too ;-)

>Generally I still think we should give other groups a chance to offer
>their ideas about the new icon. I mean, emacs-devel is read by coders
>and not by artists. Of course many of the icons presented look really
>nice, so there are people here who are both but still if you look at
>the development of Gnome and KDE programs you will find out that there
>are many people with exceptional artistic talents but with no talent for
>(or no joy in) coding who like to contribute to free software
>development.
>  
>
A very good suggestion. But can you tell us where to send such an 
inquiry? Or perhaps you can do that yourself? As you know I have 
currently put up a web page with the ideas we have had so far. I guess 
that could be a useful starting point.

Re: Emacs icons

[Frank Schmitt]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> A very good suggestion. But can you tell us where to send such an 
> inquiry? Or perhaps you can do that yourself? As you know I have 
> currently put up a web page with the ideas we have had so far. I guess 
> that could be a useful starting point.

I'm a bit short off time ATM since I'll marry tomorrow, but I'll look
into it on Monday.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Emacs icons

[Richard M. Stallman]

    And Incscape seems to be GNU too ;-)

No, it's not a GNU package.  In the Free Software Directory
it is listed as a non-GNU package.

What led you to think it "seems to be GNU too"?
That kind of confusion is common, and we need to track down
the cause of it.

Re: Emacs icons

[Karl Chen]

>>>>> On 2005-08-19 16:08 PDT, Richard M Stallman writes:

    rms> What led you to think it "seems to be GNU too"?  That
    rms> kind of confusion is common, and we need to track down
    rms> the cause of it.

It is probably the confusion between "programs licensed under the
GNU GPL" and "programs from the GNU Project".

-- 
Karl 2005-08-19 16:22

Re: Emacs icons

[Lennart Borgman]

Karl Chen wrote:

>>>>>>On 2005-08-19 16:08 PDT, Richard M Stallman writes:
>>>>>>            
>>>>>>
>
>    rms> What led you to think it "seems to be GNU too"?  That
>    rms> kind of confusion is common, and we need to track down
>    rms> the cause of it.
>
>It is probably the confusion between "programs licensed under the
>GNU GPL" and "programs from the GNU Project".
>  
>
Yes, and it seems like I need to be more careful with my words here. And 
I need to learn something about this too. Exactly what does the second 
term mean? I guess it would have been ok if I had wrote "it is licensed 
GPL"?

Inkscape is very short about the license, they just say "Copyright 
1999-2004 by Authors. Inkscape is free software; you can redistribute it 
and/or modify it under the terms of the GPL":

   http://www.inkscape.org/doc/inkscape-man.html#copyright_and_license

Re: Emacs icons

[Richard M. Stallman]

    >It is probably the confusion between "programs licensed under the
    >GNU GPL" and "programs from the GNU Project".
    >  
    >
    Yes, and it seems like I need to be more careful with my words here. And 
    I need to learn something about this too. Exactly what does the second 
    term mean?

See http://www.gnu.org/philosophy/categories.html for definitions
of this and other such categories.

    Inkscape is very short about the license, they just say "Copyright 
    1999-2004 by Authors. Inkscape is free software; you can redistribute it 
    and/or modify it under the terms of the GPL":

Does each source file have a license notice?  If not, it would be
useful to write to them and suggest they add one.

Re: Emacs icons

[David Ponce]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

> I ask everyone to please NOT send any more proposed icons that are
> based on a picture of a gnu.  All such pictures are too complex, and
> unusable.  Please save your time and mine by not proposing such
> pictures.  The most that might work is the partial gnu picture
> combined with an E.

Hi,

Attached you will find two more ideas for an Emacs icon ;-)

Sincerely,
David


[-- Attachment #2: emacs16x16-B.png --]
[-- Type: image/png, Size: 607 bytes --]

[-- Attachment #3: emacs48x48-B.png --]
[-- Type: image/png, Size: 529 bytes --]

[-- Attachment #4: emacs48x48-B.xcf --]
[-- Type: image/x-xcf, Size: 2864 bytes --]

[-- Attachment #5: emacs16x16-A.png --]
[-- Type: image/png, Size: 605 bytes --]

[-- Attachment #6: emacs48x48-A.png --]
[-- Type: image/png, Size: 524 bytes --]

[-- Attachment #7: emacs48x48-A.xcf --]
[-- Type: image/x-xcf, Size: 2930 bytes --]

[-- Attachment #8: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs icons

[Richard M. Stallman]

    Attached you will find two more ideas for an Emacs icon ;-)

The E can be seen.  I don't see anything bad about this, but since I
am not an expert on icons, I wonder what others think.

Re: Emacs icons

[Ralf Angeli]

* Richard M. Stallman (2005-08-24) writes:

>     Attached you will find two more ideas for an Emacs icon ;-)
>
> The E can be seen.  I don't see anything bad about this, but since I
> am not an expert on icons, I wonder what others think.

Like Frank I think that something like an icon should be designed by
an artist, not by a coder.  One could ask somebody like Jakub Steiner
who made a lot of icons for Gnome and OpenOffice if he would like to
design something for Emacs as well.  I don't know how he deals with
such inquiries, but maybe it will work if the icon can be
designed/used as a replacement for the current Emacs icon in Gnome.
Or he knows somebody who would like to take such an opportunity in
case he is not interested or does not have time.

-- 
Ralf

Re: Emacs icons

[Juanma Barranquero]

On 8/24/05, Ralf Angeli <angeli@iwi.uni-sb.de> wrote:

> Like Frank I think that something like an icon should be designed by
> an artist, not by a coder.

Hear, hear!

-- 
                    /L/e/k/t/u

Re: Emacs icons

[Thien-Thi Nguyen]

Juanma Barranquero <lekktu@gmail.com> writes:

> On 8/24/05, Ralf Angeli <angeli@iwi.uni-sb.de> wrote:
> 
> > Like Frank I think that something like an icon should be
> > designed by an artist, not by a coder.
> 
> Hear, hear!

well, ideally someone would write some elisp that lets those
programmers w/ artistic bent render their algorithmic ideas,
so that the distinction between "artist" and "coder" is
limited only by the tools available.  anyway, here's a plug
for some xpm generation code:

 http://www.glug.org/people/ttn/software/personal-elisp/
       dist-lisp-index.html

specifically, look for xpm-fulmination.el.  this small library
is used, for example, by fulminate-gnugo-xpms.el, which clearly
demonstrates the limit of my personal artistry (drawing circles
and "rectilinear forms" :-).

thi

Re: Emacs icons

[Richard M. Stallman]

    Like Frank I think that something like an icon should be designed by
    an artist, not by a coder.  One could ask somebody like Jakub Steiner
    who made a lot of icons for Gnome and OpenOffice if he would like to
    design something for Emacs as well.

I can ask him.  Can someone tell me how to contact him?

Re: Emacs icons

[Ralf Angeli]

* Richard M. Stallman (2005-08-25) writes:

>     Like Frank I think that something like an icon should be designed by
>     an artist, not by a coder.  One could ask somebody like Jakub Steiner
>     who made a lot of icons for Gnome and OpenOffice if he would like to
>     design something for Emacs as well.
>
> I can ask him.  Can someone tell me how to contact him?

The email address mentioned on his homepage is "jimmac at ximian.com".

-- 
Ralf

RE: Emacs icons

[Drew Adams]

        Attached you will find two more ideas for an Emacs icon ;-)

    The E can be seen.  I don't see anything bad about this, but since I
    am not an expert on icons, I wonder what others think.

The E can be seen. IMO, it would be better alone, larger, and with more
contrast against the background (e.g. darker red against white, if those are
the colors to be used).

I would lose the "m-a c s" in the icon, because of the small size.

There is no reason to treat the "m-a" differently from the "c s". If the
idea behind "m-a" is to depict an Emacs keybinding, then it should be "M-a"
(or possibly "M-A"). And then the "c s" should be treated similarly, as
"C-s" (or "C-S"). If the entire sequence is meant to be read as a key
sequence, in wrap-around fashion, as "m-a c s", then I think we're asking
too much, in terms of visual interpretation. Better to keep it simple.

I agree with others that it would be good to get input from a graphic artist
or UI pro - anyone know any ;-)?

Re: Emacs icons

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Drew Adams wrote:

>    > The idea of using an E on a gnu is ok semantically.  Whether it looks
>    > better than just an E, I am not sure.
>
>    Attached is an idea ;-) It don't look too bad when resized as a 16x16
>icon.
>
>This could make an attractive _logo_, but it would _not_ work as a 16x16
>icon, IMO (see attached). Clever combination of E with gnu head - bravo!
>But, as Richard pointed out, that makes it hard to distinguish the E.
>
>Let's not forget the story of "The Gnu Who Became a Mushroom" - that's an
>invaluable icon lesson. If shrinking a gnu head can turn it into a mushroom,
>there is no hope for shrinking E-gnus and other such artistic subtleties. In
>particular, shrunken heads seldom appear brilliant.
>
>16x16 is a hard nut to crack.
>
Here is one crack, the 48x48 version and a 16x16 version. BTW if anyone 
want to play with this some of the Gimp xcf files are at the same 
directory as the images for the web page.

[-- Attachment #2: emacs48x48-11.png --]
[-- Type: image/png, Size: 441 bytes --]

[-- Attachment #3: emacs48x48-8.png --]
[-- Type: image/png, Size: 3455 bytes --]

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: Emacs icons

[Drew Adams]

    Here is one crack, the 48x48 version and a 16x16 version. BTW if anyone
    want to play with this some of the Gimp xcf files are at the same
    directory as the images for the web page.

The logo is OK, as a logo (like the Nike swoosh). If it became known to
everyone _as a logo_, then it could work as an icon too. But both the E and
the gnu are unrecognizable _in the icon_ (16x16).

IOW, if we want the icon to stand on its own, not backed up by lots of
"branding" with the larger logo, then it must be recognizable on its own.
IMO.

Re: Emacs icons

[Richard M. Stallman]

    Here is one crack, the 48x48 version and a 16x16 version. BTW if anyone 
    want to play with this some of the Gimp xcf files are at the same 
    directory as the images for the web page.

This is pretty good, but the E is a little fuzzy.  Perhaps a
small change in color or drawing style could make it clearer.

Another message contained a few similar icons, some with a blue E.
Blue is much easier to see.  The green E is not visible enough; let's
give up on that color.

Re: Emacs icons

[David Ponce]

[-- Attachment #1: Type: text/plain, Size: 92 bytes --]

Hi,

Here is another simpler image proposal.  Looks good scaled to 16x16.

Sincerely,
David

[-- Attachment #2: emacs48x48-E.png --]
[-- Type: image/png, Size: 2475 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

[OT] Re: Emacs icons

[Masatake YAMATO]

Gif has still the problem?

    http://www.gyve.org/~jet/boblay/gallery/lisp.gif
    http://www.gyve.org/~jet/boblay/gallery/gnu.gif

Re: Emacs icons

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

David Ponce wrote:

> Hi,
>
> Here is another simpler image proposal.  Looks good scaled to 16x16.
>
> Sincerely,
> David

This can perhaps be used with colors. I have tried to color the picture 
David sent and I attach one variant and also a 16x16 version I got from 
David. There are more colored variants on the web site.

[-- Attachment #2: emacs48x48-Ec.png --]
[-- Type: image/png, Size: 2649 bytes --]

[-- Attachment #3: emacs16x16-E.png --]
[-- Type: image/png, Size: 806 bytes --]

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs icons

[Richard M. Stallman]

The big version of this icon looks nice, and the large E ought to be
readable.  However, there isn't enough color contrast between the purple
E and the dark background.

The small version seems to use different colors, and the E can't be
seen at all.

Re: Emacs icons

[Lennart Borgman]

Richard M. Stallman wrote:

>The big version of this icon looks nice, and the large E ought to be
>readable.  However, there isn't enough color contrast between the purple
>E and the dark background.
>  
>
It is quite hard to understand which picture you are commenting. Could 
you please describe it a bit more?

I have tried to make some version in different colors from the pictures 
David sent. I only made one 16x16 version cause I only wanted to see if 
the E could be made recognizeable in that size. Since some people seem 
to have difficulties with the colors I used this test obviously failed  ;-)

Please suggest other color combinations. I think color, light and 
saturation contrast should all be used. What works for you? What about 
others? Consider also that the icon should be possible to see on white 
background and on darker background. Maybe I should to show different 
background colors on the web page...

Re: Emacs icons

[Richard M. Stallman]

    It is quite hard to understand which picture you are commenting. Could 
    you please describe it a bit more?

You really should put enough info in the Subject line to reliably
identify the icons in the message.  Otherwise, such confusion
is certain to happen.

These icons seem to have a big E above a small MACS.
However, in the smaller version the E could not be seen at all.
As far as I can tell, it is black on black.

Re: Emacs icons

[Emilio Lopes]

[-- Attachment #1: Type: text/plain, Size: 133 bytes --]

David Ponce writes:

> Here is another simpler image proposal.  Looks good scaled to 16x16.

How about something along the lines of


[-- Attachment #2: Emacs icon suggestion --]
[-- Type: image/png, Size: 814 bytes --]

[-- Attachment #3: Type: text/plain, Size: 202 bytes --]


(in allusion to Einstein's E=mc2)? Could look nice with colors and
pretty fonts.

It was not my idea. I first saw it in a post by Christoph Conrad,
where he attributes this "discovery" to Peter Ikier.

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs icons

[Stefan Reichör]

Emilio Lopes <eclig@gmx.net> writes:

>
> (in allusion to Einstein's E=mc2)? Could look nice with colors and
> pretty fonts.
>
> It was not my idea. I first saw it in a post by Christoph Conrad,
> where he attributes this "discovery" to Peter Ikier.

Does someone have a copy of that image?

The page http://www1.physik.tu-muenchen.de/~ecl/albert_emacs.html
is no longer accessible.

The wayback machine didn't help either :-(

Stefan.

Re: Emacs icons

[Emilio Lopes]

Stefan Reichör writes:

> Emilio Lopes <eclig@gmx.net> writes:
>>
>> (in allusion to Einstein's E=mc2)? Could look nice with colors and
>> pretty fonts.
>>
>> It was not my idea. I first saw it in a post by Christoph Conrad,
>> where he attributes this "discovery" to Peter Ikier.

> Does someone have a copy of that image?

Sure:

   http://home.tiscali.de/emilio.lopes/emacs/albert_emacs.html

> The page http://www1.physik.tu-muenchen.de/~ecl/albert_emacs.html is
> no longer accessible.

Yes, I left the TUM in October 2002.  And I must say, Peter Ikier's
discovery sure influenced my decision :-).

-- 
Emílio C. Lopes
Munich, Germany

RE: Emacs icons

[Drew Adams]

What a coincidence! I threw out that E = macs idea, independently, a week
ago. I guess it must be a fairly obvious thing to "discover", but, even so,
I'm still a bit surprised. I'm sure I never saw this anywhere. - Drew

    >> (in allusion to Einstein's E=mc2)? Could look nice with colors and
    >> pretty fonts.
    >> It was not my idea. I first saw it in a post by Christoph Conrad,
    >> where he attributes this "discovery" to Peter Ikier.

    > Does someone have a copy of that image?

    Sure:

       http://home.tiscali.de/emilio.lopes/emacs/albert_emacs.html

Re: Emacs icons

[Richard M. Stallman]

    How about something along the lines of

This is the E=MACS equation idea.  It is clever, but it is too complex
to fit in a usable icon.  In order to be visible, it has to be too
big.

Such complex ideas are not usable, so I ask people to let them drop.

Re: Suggestions for the temporary windows used from the minibuffer

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Mon, 08 Aug 2005 20:27:53 -0400
> Cc: emacs-devel@gnu.org
> 
> I don't think Emacs should features on Windows that are not supported
> on GNU/Linux.  That would distort Emacs into a Windows application
> and defeat the purpose of our work.

We have icons linked into the Emacs binary on Windows for a very long
time now, since January 1999 at the least (see nt/emacs.rc, the
Windows resource file which specifies that, it is used when linking
temacs).  What was suggested in this thread is to add some more icons
to the ones we already distribute (see nt/icons/*).  This is not a new
feature in any way.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

      What was suggested in this thread is to add some more icons
    to the ones we already distribute (see nt/icons/*).

So how would these new icons be used?  Just as user-selectable
alternatives?  I have nothing at all against that.

Re: Suggestions for the temporary windows used from the minibuffer

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: lennart.borgman.073@student.lu.se, emacs-devel@gnu.org
> Date: Tue, 09 Aug 2005 17:46:03 -0400
> 
> So how would these new icons be used?  Just as user-selectable
> alternatives?

Yes, exactly.

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Richard M. Stallman wrote:

>     I think it would be 
>    very nice if in all these the same keyboard command was used to scroll 
>    that extra window and to move into that window.
>
>Isn't that already the case?  C-M-v should always scroll it.
>  
>
It does not work for C-h ?. Maybe that is the only important case though.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    It does not work for C-h ?. Maybe that is the only important case though.

That is handled by very special code.  Would you like to implement
C-M-v in it?

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Richard M. Stallman wrote:

>    It does not work for C-h ?. Maybe that is the only important case though.
>
>That is handled by very special code.  Would you like to implement
>C-M-v in it?
>  
>
Attached is a patch for help.el and help-macro.el (from lisp directory). 
I tried to honor all current bindings to scroll-other-window(-down) and 
also added <prior>/<next>.

I have called <prior>/<next> for Page Up/Down which I think most new 
users will recognize.

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

Richard M. Stallman wrote:

>    It does not work for C-h ?. Maybe that is the only important case though.
>
>That is handled by very special code.  Would you like to implement
>C-M-v in it?
>  
>
Attached is a patch for help.el and help-macro.el (from lisp directory). 
I tried to honor all current bindings to scroll-other-window(-down) and 
also added <prior>/<next>.

I have called <prior>/<next> for Page Up/Down which I think most new 
users will recognize.

[-- Attachment #2: help-scroll.patch --]
[-- Type: text/plain, Size: 4746 bytes --]

Index: help.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/help.el,v
retrieving revision 1.283
diff -u -r1.283 help.el
--- help.el	4 Jul 2005 23:08:54 -0000	1.283
+++ help.el	6 Aug 2005 22:56:45 -0000
@@ -186,7 +186,7 @@
 (make-help-screen help-for-help-internal
   "a b c C e f F i I k C-k l L m p s t v w C-c C-d C-f C-n C-p C-t C-w . or ? :"
   "You have typed %THIS-KEY%, the help character.  Type a Help option:
-\(Use SPC or DEL to scroll through this text.  Type \\<help-map>\\[help-quit] to exit the Help command.)
+\(Use Page Up/Down to scroll through this text.  Type \\<help-map>\\[help-quit] to exit the Help command.)
 
 a  command-apropos.  Give a substring, and see a list of commands
 	(functions that are interactively callable) that contain
Index: help-macro.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/help-macro.el,v
retrieving revision 1.33
diff -u -r1.33 help-macro.el
--- help-macro.el	4 Jul 2005 23:08:54 -0000	1.33
+++ help-macro.el	6 Aug 2005 22:56:53 -0000
@@ -1,6 +1,7 @@
 ;;; help-macro.el --- makes command line help such as help-for-help
 
-;; Copyright (C) 1993, 1994 Free Software Foundation, Inc.
+;; Copyright (C) 1993, 1994, 2002, 2003, 2004,
+;;   2005 Free Software Foundation, Inc.
 
 ;; Author: Lynn Slater <lrs@indetech.com>
 ;; Maintainer: FSF
@@ -104,6 +105,11 @@
 		    ;; sections, *excluding* where we switch buffers
 		    ;; and where we execute the chosen help command.
 		    (local-map (make-sparse-keymap))
+                    ;; Some keys should still be available
+                    (still-map (make-sparse-keymap))
+                    (still-lst (list '(scroll-other-window-down . scroll-down)
+                                     '(scroll-other-window      . scroll-up)))
+                    still-cmd
 		    (minor-mode-map-alist nil)
 		    (prev-frame (selected-frame))
 		    config new-frame key char)
@@ -111,6 +117,16 @@
 		   (setq help-screen
 			 (replace-match (key-description (substring (this-command-keys) 0 -1))
 					t t help-screen)))
+               (mapc (lambda (elt)
+                       (let ((new (if (consp elt) (cdr elt) elt))
+                             (orig   (if (consp elt) (car elt) elt)))
+                         (mapc (lambda (key)
+                                 (define-key still-map key new))
+                               (where-is-internal orig))))
+                     still-lst)
+               ;; Maybe it is good for new users with just next/prior?
+               (define-key still-map [(next)]  'scroll-up)
+               (define-key still-map [(prior)] 'scroll-down)
 	       (unwind-protect
 		   (progn
 		     (setcdr local-map ,helped-map)
@@ -145,7 +161,8 @@
 			   (while (or (memq char (append help-event-list
 							 (cons help-char '(?? ?\C-v ?\s ?\177 delete backspace vertical-scroll-bar ?\M-v))))
 				      (eq (car-safe char) 'switch-frame)
-				      (equal key "\M-v"))
+				      (equal key "\M-v")
+                                      still-cmd)
 			     (condition-case nil
 				 (progn
 				   (if (eq (car-safe char) 'switch-frame)
@@ -160,12 +177,23 @@
 			     (let ((cursor-in-echo-area t)
 				   (overriding-local-map local-map))
 			       (setq key (read-key-sequence
-					  (format "Type one of the options listed%s: "
-						  (if (pos-visible-in-window-p
-						       (point-max))
-						      "" ", or SPACE or DEL to scroll")))
-				     char (aref key 0)))
-
+					  (format "Type one of the options listed, or %s: "
+						  (if (pos-visible-in-window-p (point-max))
+						      "Page Up"
+                                                    (if (pos-visible-in-window-p (point-min))
+                                                        "Page Down"
+                                                      "or Page Up/Down to scroll"))))
+                                     char (aref key 0)))
+                             
+                             ;; If this is one of the commands we still should run then run it.
+                             (setq still-cmd (lookup-key still-map key))
+                             (when still-cmd
+                               (let ((cmd (assq still-cmd still-lst)))
+                                 (unless cmd (setq cmd still-cmd))
+                                 (condition-case nil
+                                     (command-execute cmd nil key)
+                                   (error nil))))
+                             
 			     ;; If this is a scroll bar command, just run it.
 			     (when (eq char 'vertical-scroll-bar)
 			       (command-execute (lookup-key local-map key) nil key)))))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

       "You have typed %THIS-KEY%, the help character.  Type a Help option:
    -\(Use SPC or DEL to scroll through this text.  Type \\<help-map>\\[help-quit] to exit the Help command.)
    +\(Use Page Up/Down to scroll through this text.  Type \\<help-map>\\[help-quit] to exit the Help command.)

I would rather not change that message.  Not all terminals have Page Up
and Page Down.

    +					  (format "Type one of the options listed, or %s: "
    +						  (if (pos-visible-in-window-p (point-max))
    +						      "Page Up"
    +                                                    (if (pos-visible-in-window-p (point-min))
    +                                                        "Page Down"
    +                                                      "or Page Up/Down to scroll"))))
    +                                     char (aref key 0)))
    +                             

Likewise, here I'd rather have it say SPC and DEL.

Please change that and install your patch.

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Richard M. Stallman wrote:

>       "You have typed %THIS-KEY%, the help character.  Type a Help option:
>    -\(Use SPC or DEL to scroll through this text.  Type \\<help-map>\\[help-quit] to exit the Help command.)
>    +\(Use Page Up/Down to scroll through this text.  Type \\<help-map>\\[help-quit] to exit the Help command.)
>
>I would rather not change that message.  Not all terminals have Page Up
>and Page Down.
>
>    +					  (format "Type one of the options listed, or %s: "
>    +						  (if (pos-visible-in-window-p (point-max))
>    +						      "Page Up"
>    +                                                    (if (pos-visible-in-window-p (point-min))
>    +                                                        "Page Down"
>    +                                                      "or Page Up/Down to scroll"))))
>    +                                     char (aref key 0)))
>    +                             
>
>Likewise, here I'd rather have it say SPC and DEL.
>
>Please change that and install your patch.
>  
>
Could you please consider the patch I send after this first? That 
include changes that makes help available for isearh in a sensible way 
and I think that is important.

I thought you might disagree on SPC and DEL but the reason I still did 
the change was because it is mostly new users that use this and need 
help with scrolling. They probably do not user terminals I believe. Are 
you sure SPC and DEL are better?

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    I thought you might disagree on SPC and DEL but the reason I still did 
    the change was because it is mostly new users that use this and need 
    help with scrolling. They probably do not user terminals I believe. Are 
    you sure SPC and DEL are better?

Yes, they are certain to exist and they are the normal Emacs way to
scroll read-only buffers.

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

Richard M. Stallman wrote:

>    It does not work for C-h ?. Maybe that is the only important case though.
>
>That is handled by very special code.  Would you like to implement
>C-M-v in it?
>  
>
I have already sent a patch for this but I have a new one here that I 
think is better. The help function in isearch-mode does not work. This 
patch also addresses that issue.

The patch makes it possible to both reach normal help (C-h, f1) and the 
special isearch help from isearch-forward/backward. It also allow the 
help buffer to be scrolled in both case while still at the isearch prompt.

As you might have noticed I think it is important to make it easier for 
beginners and this is a patch towards that goal.

[-- Attachment #2: help-scroll-isearch.patch --]
[-- Type: text/plain, Size: 11413 bytes --]

Index: help.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/help.el,v
retrieving revision 1.283
diff -u -r1.283 help.el
--- help.el	4 Jul 2005 23:08:54 -0000	1.283
+++ help.el	7 Aug 2005 22:20:35 -0000
@@ -1,7 +1,7 @@
 ;;; help.el --- help commands for Emacs
 
-;; Copyright (C) 1985, 1986, 1993, 1994, 1998, 1999, 2000, 2001, 2002, 2004,
-;;   2005  Free Software Foundation, Inc.
+;; Copyright (C) 1985, 1986, 1993, 1994, 1998, 1999, 2000, 2001, 2002,
+;;   2003, 2004, 2005 Free Software Foundation, Inc.
 
 ;; Maintainer: FSF
 ;; Keywords: help, internal
@@ -186,8 +186,8 @@
 (make-help-screen help-for-help-internal
   "a b c C e f F i I k C-k l L m p s t v w C-c C-d C-f C-n C-p C-t C-w . or ? :"
   "You have typed %THIS-KEY%, the help character.  Type a Help option:
-\(Use SPC or DEL to scroll through this text.  Type \\<help-map>\\[help-quit] to exit the Help command.)
-
+\(Use Page Up/Down to scroll through this text.  Type \\<help-map>\\[help-quit] to exit the Help command.)
+%X-DESCRIPTION%
 a  command-apropos.  Give a substring, and see a list of commands
 	(functions that are interactively callable) that contain
 	that substring.  See also the  apropos  command.
Index: help-macro.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/help-macro.el,v
retrieving revision 1.33
diff -u -r1.33 help-macro.el
--- help-macro.el	4 Jul 2005 23:08:54 -0000	1.33
+++ help-macro.el	7 Aug 2005 22:20:52 -0000
@@ -1,6 +1,7 @@
 ;;; help-macro.el --- makes command line help such as help-for-help
 
-;; Copyright (C) 1993, 1994 Free Software Foundation, Inc.
+;; Copyright (C) 1993, 1994, 2002, 2003, 2004,
+;;   2005 Free Software Foundation, Inc.
 
 ;; Author: Lynn Slater <lrs@indetech.com>
 ;; Maintainer: FSF
@@ -82,21 +83,32 @@
 
 (defmacro make-help-screen (fname help-line help-text helped-map)
   "Construct help-menu function name FNAME.
-When invoked, FNAME shows HELP-LINE and reads a command using HELPED-MAP.
-If the command is the help character, FNAME displays HELP-TEXT
-and continues trying to read a command using HELPED-MAP.
+When invoked, FNAME shows HELP-LINE and reads a command using
+HELPED-MAP.  If the command is the help character, FNAME displays
+HELP-TEXT and continues trying to read a command using
+HELPED-MAP.
+
 If HELP-TEXT contains the sequence `%THIS-KEY%', that is replaced
 with the key sequence that invoked FNAME.
+
+When calling FNAME if the optional parameters X-FUNCTION, X-CHAR
+and X-DESCRIPTION to the defined function FNAME are given they
+must all be given.  In this case the the sequence
+`%X-DESCRIPTION%' in HELP-TEXT is replaced with the parameters
+X-CHAR character and the X-DESCRIPTION string.  Also the keyboard
+character X-CHAR is bound to the parameter X-FUNCTION.
+
 When FNAME finally does get a command, it executes that command
 and then returns."
  (let ((doc-fn (intern (concat (symbol-name fname) "-doc"))))
   `(progn
     (defun ,doc-fn () ,help-text)
-    (defun ,fname ()
+    (defun ,fname (&optional x-function x-char x-description)
 	   "Help command."
 	   (interactive)
 	   (let ((line-prompt
 		  (substitute-command-keys ,help-line)))
+             (when x-char (setq line-prompt (concat (char-to-string x-char) " " line-prompt)))
 	     (if three-step-help
 		 (message "%s" line-prompt))
 	     (let* ((help-screen (documentation (quote ,doc-fn)))
@@ -104,6 +116,12 @@
 		    ;; sections, *excluding* where we switch buffers
 		    ;; and where we execute the chosen help command.
 		    (local-map (make-sparse-keymap))
+                    ;; Some keys should still be available
+                    (still-map (make-sparse-keymap))
+                    (still-lst (list '(scroll-other-window-down . scroll-down)
+                                     '(scroll-other-window      . scroll-up)))
+                    still-cmd
+                    (curr-wind (selected-window))
 		    (minor-mode-map-alist nil)
 		    (prev-frame (selected-frame))
 		    config new-frame key char)
@@ -111,9 +129,28 @@
 		   (setq help-screen
 			 (replace-match (key-description (substring (this-command-keys) 0 -1))
 					t t help-screen)))
+               (when (string-match "%X-DESCRIPTION%" help-screen)
+                 (let ((x-repl
+                        (if x-description
+                            (format "\n%s  %s\n\n" (char-to-string x-char) x-description)
+                          "")))
+                   (setq help-screen
+                         (replace-match x-repl
+                                        t t help-screen))))
+               (mapc (lambda (elt)
+                       (let ((new  (if (consp elt) (cdr elt) elt))
+                             (orig (if (consp elt) (car elt) elt)))
+                         (mapc (lambda (key)
+                                 (define-key still-map key new))
+                               (where-is-internal orig))))
+                     still-lst)
+               ;; Maybe it is good for new users with just next/prior?
+               (define-key still-map [(next)]  'scroll-up)
+               (define-key still-map [(prior)] 'scroll-down)
 	       (unwind-protect
 		   (progn
 		     (setcdr local-map ,helped-map)
+                     (when x-function (define-key local-map (make-vector 1 x-char) x-function))
 		     (define-key local-map [t] 'undefined)
 		     ;; Make the scroll bar keep working normally.
 		     (define-key local-map [vertical-scroll-bar]
@@ -145,7 +182,8 @@
 			   (while (or (memq char (append help-event-list
 							 (cons help-char '(?? ?\C-v ?\s ?\177 delete backspace vertical-scroll-bar ?\M-v))))
 				      (eq (car-safe char) 'switch-frame)
-				      (equal key "\M-v"))
+				      (equal key "\M-v")
+                                      still-cmd)
 			     (condition-case nil
 				 (progn
 				   (if (eq (car-safe char) 'switch-frame)
@@ -160,12 +198,23 @@
 			     (let ((cursor-in-echo-area t)
 				   (overriding-local-map local-map))
 			       (setq key (read-key-sequence
-					  (format "Type one of the options listed%s: "
-						  (if (pos-visible-in-window-p
-						       (point-max))
-						      "" ", or SPACE or DEL to scroll")))
-				     char (aref key 0)))
-
+					  (format "Type one of the options listed, or %s: "
+						  (if (pos-visible-in-window-p (point-max))
+						      "Page Up"
+                                                    (if (pos-visible-in-window-p (point-min))
+                                                        "Page Down"
+                                                      "or Page Up/Down to scroll"))))
+                                     char (aref key 0)))
+                             
+                             ;; If this is one of the commands we still should run then run it.
+                             (setq still-cmd (lookup-key still-map key))
+                             (when still-cmd
+                               (let ((cmd (assq still-cmd still-lst)))
+                                 (unless cmd (setq cmd still-cmd))
+                                 (condition-case nil
+                                     (command-execute cmd nil key)
+                                   (error nil))))
+                             
 			     ;; If this is a scroll bar command, just run it.
 			     (when (eq char 'vertical-scroll-bar)
 			       (command-execute (lookup-key local-map key) nil key)))))
@@ -180,19 +229,23 @@
 		       (let ((defn (lookup-key local-map key)))
 			 (if defn
 			     (progn
-			       (if config
-				   (progn
-				     (set-window-configuration config)
-				     (setq config nil)))
-			       (if new-frame
-				   (progn (iconify-frame new-frame)
-					  (setq new-frame nil)))
-			       (call-interactively defn))
-			   (ding)))))
-		 (if new-frame (iconify-frame new-frame))
-		 (if config
-		     (set-window-configuration config))))))
-     )))
+                               ;; Do not restore in this case since we are still in help
+                               (when (eq defn x-function)
+                                 (unless new-frame
+                                   (select-window curr-wind)
+                                     (setq config nil)))
+                               (if config
+                                   (progn
+                                     (set-window-configuration config)
+                                     (setq config nil)))
+                               (if new-frame
+                                   (progn (iconify-frame new-frame)
+                                          (setq new-frame nil)))
+                               (call-interactively defn))
+                           (ding)))))
+                 (if new-frame (iconify-frame new-frame))
+                 (if config
+                     (set-window-configuration config)))))))))
 
 (provide 'help-macro)
 
Index: isearch.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.268
diff -u -r1.268 isearch.el
--- isearch.el	28 Jul 2005 13:55:16 -0000	1.268
+++ isearch.el	7 Aug 2005 22:21:22 -0000
@@ -298,6 +298,28 @@
 \f
 ;; Define isearch-mode keymap.
 
+(defun isearch-scroll-other-down()
+  (interactive)
+  (let ((hbw (get-buffer-window "*Help*")))
+    (when hbw
+      (condition-case nil
+          (save-selected-window
+            (select-window hbw t)
+            (scroll-down))
+        (error nil))
+      (isearch-update))))
+
+(defun isearch-scroll-other-up()
+  (interactive)
+  (let ((hbw (get-buffer-window "*Help*")))
+    (when hbw
+      (condition-case nil
+          (save-selected-window
+            (select-window hbw t)
+            (scroll-up))
+        (error nil))
+      (isearch-update))))
+
 (defvar isearch-mode-map
   (let* ((i 0)
 	 (map (make-keymap)))
@@ -369,6 +391,12 @@
     ;; Turned off because I find I expect to get the global definition--rms.
     ;; ;; Instead bind C-h to special help command for isearch-mode.
     ;; (define-key map "\C-h" 'isearch-mode-help)
+    (define-key map [(f1)] 'isearch-help-for-help)
+    (define-key map "\C-h" 'isearch-mode-help)
+    (define-key map [(meta prior)] 'isearch-scroll-other-down)
+    (define-key map [(meta next)]  'isearch-scroll-other-up)
+    (define-key map [(prior)] 'isearch-scroll-other-down)
+    (define-key map [(next)]  'isearch-scroll-other-up)
 
     (define-key map "\M-n" 'isearch-ring-advance)
     (define-key map "\M-p" 'isearch-ring-retreat)
@@ -604,6 +632,28 @@
 (defun isearch-mode-help ()
   (interactive)
   (describe-function 'isearch-forward)
+  (isearch-update))
+
+(defun isearch-mode-help-when-active()
+  (interactive)
+  (let ((w (selected-window))
+        (b (current-buffer)))
+    (save-selected-window
+      (unless (get-buffer-window "*Help*")
+        (switch-to-buffer-other-window "*Help*" t))
+      (with-current-buffer (get-buffer "*Help*")
+        (setq buffer-read-only nil)
+        (erase-buffer)
+        (insert (documentation 'isearch-mode))
+        (help-mode)
+        (goto-char (point-min))))
+    (select-window w)
+    (set-buffer b)))
+
+(defun isearch-help-for-help()
+  (interactive)
+  (help-for-help 'isearch-mode-help-when-active ?x "isearch mode help")
+  (sit-for 9)
   (isearch-update))
 
 \f

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    +When calling FNAME if the optional parameters X-FUNCTION, X-CHAR
    +and X-DESCRIPTION to the defined function FNAME are given they
    +must all be given.  In this case the the sequence
    +`%X-DESCRIPTION%' in HELP-TEXT is replaced with the parameters
    +X-CHAR character and the X-DESCRIPTION string.  Also the keyboard
    +character X-CHAR is bound to the parameter X-FUNCTION.

I don't understand that text; I am simply lost.  You need to state
it more clearly.

The best place for this info is in the doc string of the constructed
function that will take these arguments.  Moving the text there will
help you simplify the text.  However, part of the reason this is
confusing is that the explanation states the algorithm for USING these
arguments.  What it needs to say is WHAT THEY MEAN.  Documentation
should not read like a program logic manual.


+               (mapc (lambda (elt)
+                       (let ((new  (if (consp elt) (cdr elt) elt))
+                             (orig (if (consp elt) (car elt) elt)))
+                         (mapc (lambda (key)
+                                 (define-key still-map key new))
+                               (where-is-internal orig))))
+                     still-lst)

That code needs a comment to explain what it is doing.

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Richard M. Stallman wrote:

>    +When calling FNAME if the optional parameters X-FUNCTION, X-CHAR
>    +and X-DESCRIPTION to the defined function FNAME are given they
>    +must all be given.  In this case the the sequence
>    +`%X-DESCRIPTION%' in HELP-TEXT is replaced with the parameters
>    +X-CHAR character and the X-DESCRIPTION string.  Also the keyboard
>    +character X-CHAR is bound to the parameter X-FUNCTION.
>
>I don't understand that text; I am simply lost.  You need to state
>it more clearly.
>
>The best place for this info is in the doc string of the constructed
>function that will take these arguments.  Moving the text there will
>help you simplify the text.  However, part of the reason this is
>confusing is that the explanation states the algorithm for USING these
>arguments.  What it needs to say is WHAT THEY MEAN.  Documentation
>should not read like a program logic manual.
>  
>
The help text is for the macro make-help-screen. The text is just meant 
for the developers who wants to use this macro. The constructed function 
currently has a help string that just says "Help command" and I have not 
changed that. Putting the help text above in the constructed function 
would make it invisible to the developer if he/she does not read the 
code of make-help-screen. The users have no use for this help text.

This is for use with help in isearch mode. It adds the text 
X-DESCRIPTION to the text that is normally shown when you type C-h. It 
also binds the character X-CHAR to the function X-FUNCTION in keymap 
used in C-h help. This is only done for isearch, otherwise the new 
optional arguments X-FUNCTION, X-CHAR and X-DESCRIPTION are not used.

Maybe it would help to say "See isearch mode for an example"?

>
>+               (mapc (lambda (elt)
>+                       (let ((new  (if (consp elt) (cdr elt) elt))
>+                             (orig (if (consp elt) (car elt) elt)))
>+                         (mapc (lambda (key)
>+                                 (define-key still-map key new))
>+                               (where-is-internal orig))))
>+                     still-lst)
>
>That code needs a comment to explain what it is doing.
>  
>
There is a comment right over still-map (though it is short). I can add 
some more comment here of course, like ";; Copy the keys from the users 
current key bindings that still should be available (ie keyboard 
scrolling with Page Up/Down)".

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Lennart Borgman wrote:

> Richard M. Stallman wrote:
>
>>    +When calling FNAME if the optional parameters X-FUNCTION, X-CHAR
>>    +and X-DESCRIPTION to the defined function FNAME are given they
>>    +must all be given.  In this case the the sequence
>>    +`%X-DESCRIPTION%' in HELP-TEXT is replaced with the parameters
>>    +X-CHAR character and the X-DESCRIPTION string.  Also the keyboard
>>    +character X-CHAR is bound to the parameter X-FUNCTION.
>>
>> I don't understand that text; I am simply lost.  You need to state
>> it more clearly.
>>
>> The best place for this info is in the doc string of the constructed
>> function that will take these arguments.  Moving the text there will
>> help you simplify the text.  However, part of the reason this is
>> confusing is that the explanation states the algorithm for USING these
>> arguments.  What it needs to say is WHAT THEY MEAN.  Documentation
>> should not read like a program logic manual.
>
Argh. Just realized that part of this patch does not work. Please 
forget. I will send a new patch

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

Lennart Borgman wrote:

>>>    +When calling FNAME if the optional parameters X-FUNCTION, X-CHAR
>>>    +and X-DESCRIPTION to the defined function FNAME are given they
>>> ...
>>> I don't understand that text; I am simply lost.  You need to state
>>> it more clearly.
>>
>>
> Argh. Just realized that part of this patch does not work. Please 
> forget. I will send a new patch
>
Instead of my previous flawed (and unnecessary complicated patch) I 
suggest the attached simple patch to isearh.el. It fixes the following 
problems (I hope):

1) Add help to the isearch prompt

2) Allows scrolling of the help window

3) Fixes a problem with the stack of commands after fetching a search 
command from the search command ring

4) Renamed search-ring-update to isearch-ring-update so that it better 
fits together with isearch.

*Notes*:
a) Please test 3, it is quite possible that there are more problems with 
the stack (or that I broken another execution path).
b) 4 of course breaks backward compatibility, but I think in this case 
it is a small problem. It simplifies for most users if the name matches 
the package.

[-- Attachment #2: isearch.patch --]
[-- Type: text/plain, Size: 2830 bytes --]

Index: isearch.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.269
diff -u -r1.269 isearch.el
--- isearch.el	6 Aug 2005 22:13:43 -0000	1.269
+++ isearch.el	9 Aug 2005 23:06:23 -0000
@@ -193,7 +193,7 @@
   "Index in `regexp-search-ring' of last string reused.
 It is nil if none yet.")
 
-(defcustom search-ring-update nil
+(defcustom isearch-ring-update nil
   "*Non-nil if advancing or retreating in the search ring should cause search.
 Default value, nil, means edit the string instead."
   :type 'boolean
@@ -368,7 +368,8 @@
 
     ;; Turned off because I find I expect to get the global definition--rms.
     ;; ;; Instead bind C-h to special help command for isearch-mode.
-    ;; (define-key map "\C-h" 'isearch-mode-help)
+    (define-key map "\C-h" 'isearch-mode-help)
+    (define-key map [(f1)] 'isearch-mode-help)
 
     (define-key map "\M-n" 'isearch-ring-advance)
     (define-key map "\M-p" 'isearch-ring-retreat)
@@ -1147,7 +1148,8 @@
 		  (funcall isearch-wrap-function)
 	        (goto-char (if isearch-forward (point-min) (point-max)))))))
     ;; C-s in reverse or C-r in forward, change direction.
-    (setq isearch-forward (not isearch-forward)))
+    (setq isearch-forward (not isearch-forward)
+	  isearch-success t))
 
   (setq isearch-barrier (point)) ; For subsequent \| if regexp.
 
@@ -1691,6 +1693,18 @@
 	  ((eq search-exit-option 'edit)
 	   (apply 'isearch-unread keylist)
 	   (isearch-edit-string))
+          ;; Always scroll other window if help buffer
+          ((let ((binding (key-binding key))
+                 other-buffer-is-help)
+             (when (or (eq binding 'scroll-other-window-down)
+                       (eq binding 'scroll-other-window))
+                 (other-window 1)
+                 (setq other-buffer-is-help (equal (buffer-name) "*Help*"))
+                 (other-window -1)
+                 (when other-buffer-is-help
+                   (command-execute binding)
+                   (isearch-update)
+                   t))))
           ;; Handle a scrolling function.
           ((and isearch-allow-scroll
                 (progn (setq key (isearch-reread-key-sequence-naturally keylist))
@@ -1832,13 +1846,14 @@
 (defun isearch-ring-adjust (advance)
   ;; Helper for isearch-ring-advance and isearch-ring-retreat
   (isearch-ring-adjust1 advance)
-  (if search-ring-update
+  ;; Changed because isearch-edit-string calls isearch-push-state
+  ;; but isearch-search does not
+  (if isearch-ring-update
       (progn
 	(isearch-search)
+        (isearch-push-state)
 	(isearch-update))
-    (isearch-edit-string)
-    )
-  (isearch-push-state))
+    (isearch-edit-string)))
 
 (defun isearch-ring-advance ()
   "Advance to the next search string in the ring."

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    4) Renamed search-ring-update to isearch-ring-update so that it better 
    fits together with isearch.

Lots of isearch options have names starting with search, so I would
prefer to keep the name of this one unchanged.

    2) Allows scrolling of the help window

I don't understand.  Would you please describe more clearly
the change in behavior that this leads to?

    1) Add help to the isearch prompt

I am not sure whether that is a good idea.
I think we should poll the users about it.

    3) Fixes a problem with the stack of commands after fetching a search 
    command from the search command ring

I don't understand, what is a "stack of commands"?
This might be a necessary bug fix, but I would like to understand
at least a little what the bug is.

Re: Suggestions for the temporary windows used from the minibuffer

[Michael Welsh Duggan]

"Richard M. Stallman" <rms@gnu.org> writes:

>     1) Add help to the isearch prompt
>
> I am not sure whether that is a good idea.
> I think we should poll the users about it.

I realize I am only one user, but I would strongly support this.  I
have often been in the middle of an isearch and typed "C-h" because I
couldn't remember one of the nifty isearch features.  On the other
hand, I haven't used anything other than RET or C-g to exit an isearch
since Emacs 20.1.

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)

RE: Suggestions for the temporary windows used from the minibuffer

[Drew Adams]

    >     1) Add help to the isearch prompt
    >
    > I am not sure whether that is a good idea.
    > I think we should poll the users about it.

What is meant by #1 - what is the "isearch prompt", and how would help be
added to it?

If you mean just "let C-s C-h display isearch-mode-help", then yes, I agree.
I use it that way, locally. I think it's especially important for novices,
because there are isearch bindings that are not obvious or are used
infrequently.

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Drew Adams wrote:

>If you mean just "let C-s C-h display isearch-mode-help", then yes, I agree.
>I use it that way, locally. I think it's especially important for novices,
>because there are isearch bindings that are not obvious or are used
>infrequently.
>  
>
Yes that was my intention.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    I realize I am only one user, but I would strongly support this.  I
    have often been in the middle of an isearch and typed "C-h" because I
    couldn't remember one of the nifty isearch features.  On the other
    hand, I haven't used anything other than RET or C-g to exit an isearch
    since Emacs 20.1.

I very often use other commands to exit Isearch.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    This is for use with help in isearch mode. It adds the text 
    X-DESCRIPTION to the text that is normally shown when you type C-h. It 
    also binds the character X-CHAR to the function X-FUNCTION in keymap 
    used in C-h help. This is only done for isearch, otherwise the new 
    optional arguments X-FUNCTION, X-CHAR and X-DESCRIPTION are not used.

That explanation would help, I guess.  But I don't understand the
point of it.  Could you tell us the point?

    Maybe it would help to say "See isearch mode for an example"?

It would help some, but an explicit explanation here of that example
would help more.

    There is a comment right over still-map (though it is short). I can add 
    some more comment here of course, like ";; Copy the keys from the users 
    current key bindings that still should be available (ie keyboard 
    scrolling with Page Up/Down)".

That would more or less suffice for this point.
However, I find the word "still" confusing;
I don't think it fits this.

Re: Suggestions for the temporary windows used from the minibuffer

[Richard M. Stallman]

    +    (define-key map [(f1)] 'isearch-help-for-help)
    +    (define-key map "\C-h" 'isearch-mode-help)
    +    (define-key map [(meta prior)] 'isearch-scroll-other-down)
    +    (define-key map [(meta next)]  'isearch-scroll-other-up)
    +    (define-key map [(prior)] 'isearch-scroll-other-down)
    +    (define-key map [(next)]  'isearch-scroll-other-up)

I think there are already too many useful keys that fail to exit
isearch as I expect them to.  (Yesterday the fact that M-c is special
in isearch caused me trouble.)  So I won't say yes to this.

I might perhaps say yes to part of it, after some discussion.

    +(defun isearch-mode-help-when-active()
    +  (interactive)

What is this function for?  What job does it do?
It needs to be explained.

Re: Suggestions for the temporary windows used from the minibuffer

[Lennart Borgman]

Richard M. Stallman wrote:

>    +    (define-key map [(f1)] 'isearch-help-for-help)
>    +    (define-key map "\C-h" 'isearch-mode-help)
>    +    (define-key map [(meta prior)] 'isearch-scroll-other-down)
>    +    (define-key map [(meta next)]  'isearch-scroll-other-up)
>    +    (define-key map [(prior)] 'isearch-scroll-other-down)
>    +    (define-key map [(next)]  'isearch-scroll-other-up)
>
>I think there are already too many useful keys that fail to exit
>isearch as I expect them to.  (Yesterday the fact that M-c is special
>in isearch caused me trouble.)  So I won't say yes to this.
>
>I might perhaps say yes to part of it, after some discussion.
>  
>
I missed that you could exit isearch that way. Then I would for sure 
drop 5 and 6 and keep 1-4 to be able to give help in isearch. Some 
people use 1 and some 2. 3 and 4 are needed to be able to scroll the 
help and are probably expected to do that by many users.

>    +(defun isearch-mode-help-when-active()
>    +  (interactive)
>
>What is this function for?  What job does it do?
>
It gives help when doing an isearch and is used by the keys above. There 
are many keys to use in isearch mode so I think it is needed. I 
hesitated a bit but then I decided to implement it in two steps:

1) Typing f1 or C-h starts the usual help available on this keys.

2) However this help now has an additional entry that is available by 
typing a certain character (I choose ?x at the moment). This brings up 
the special help describing all the keys in isearch. This additional 
entry is mentioned first, before the normal entries since you probably 
want this one first.

Well, it is just a suggestion and trying it out is perhaps the best to 
see how it works. My rational for doing it this way was that many users 
might find it convenient to just check for one key the same way as they 
are used to while other wants to see all keys that are special to 
isearch. Might be overkill but it is easy to use and isearch is a great 
tool that deserves good help functionality.