Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position?

Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position?

[Drew Adams]

The Text Properties popup menu (via `C-mouse-2'), `facemenu-menu', currently
applies to the cursor position (point). Isn't this misleading? If you are
using the mouse to bring up the menu, then I think you might be expecting
the position of application to be the pointer position, not the cursor
position.

Especially wrt menu items that are specific to a buffer position, it's
likely that users will want to use the menu at different positions by simply
pointing the mouse.

For example, to check the text properties at some position, it would be
convenient to just put the mouse over that position, pop up the menu, and
choose Describe Properties. I tried this in various (pointer) positions, and
I couldn't figure out why the result didn't correspond to what I expected.
It wasn't until I looked at the facemenu code that I understood that the
mouse position is irrelevant and the cursor position is used always.

Don't you think that mouse position would be more relevant here than the
cursor position, when accessed from a mouse menu?

Commands such as `describe-text-properties' should still use the cursor
position (e.g. for access via M-x), but I think that when such commands are
accessed from a mouse (popup) menu, the pointer position should be used
instead.

Re: Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position?

[Luc Teirlinck]

Drew Adams wrote:

   The Text Properties popup menu (via `C-mouse-2'), `facemenu-menu', currently
   applies to the cursor position (point).

No, they apply to the region, or, in Transient Mark mode when the
region is not active, to any immediately following self-inserting
input, which happens to be at the cursor position, because C-mouse-2
does not change the cursor position.  Does it affect the already
present character under point in your setup?  I do not believe that is
supposed to happen and it does not happen for me.

Sincerely,

Luc.

Re: Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position?

[Luc Teirlinck]

Drew Adams wrote:

   Commands such as `describe-text-properties' should still use the cursor
   position (e.g. for access via M-x), but I think that when such commands are
   accessed from a mouse (popup) menu, the pointer position should be used
   instead.

I did not read far enough when I replied.  The "Describe Properties"
item indeed applies to the character after point, but it is the only
C-mouse-2 item that does.  The pointer position may not be on a
character to begin with.  For instance, it might be on the empty part
of the window past the last character.

Sincerely,

Luc.

RE: Q on Text Properties popup menu - shouldn't it use the pointerposition, not the cursor position?

[Drew Adams]

       The Text Properties popup menu (via `C-mouse-2'),
       currently applies to the cursor position (point).

    No, they apply to the region, or, in Transient Mark mode when the
    region is not active, to any immediately following self-inserting
    input, which happens to be at the cursor position, because C-mouse-2
    does not change the cursor position.  Does it affect the already
    present character under point in your setup?  I do not believe that is
    supposed to happen and it does not happen for me.

Correct, concerning most of the menu items. And that makes sense, since most
of the items do something to text (the text in the region).

The last four items (Describe Properties, Display Faces, Display Colors,
Display Fonts), however, do not affect the region and are not affected by
it. Perhaps there should be a menu separator just above these four items?

The Describe Properties item runs describe-text-properties, which always
references (the character after) point, never a region. Since it references
a single position, to me the best position to use is the mouse-pointer
position (when run from the mouse popup menu). If the mouse pointer does not
point to a character, then an error message should say "No character here"
or some such.


BTW, I think there might also be a minor bug: Each time I use the Text
Properties menu I get this message: "<C-drag-mouse-2> is undefined". This
does not seem to affect the menu action, though; things still work OK.

In GNU Emacs 22.0.50.2 (i386-mingw-nt5.1.2600)
 of 2005-04-16 on LAPTOP
Distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

RE: Q on Text Properties popup menu - shouldn't it use the pointerposition, not the cursor position?

[Drew Adams]

    The Describe Properties item runs describe-text-properties,
    which always references (the character after) point, never a
    region. Since it references a single position, to me the best
    position to use is the mouse-pointer position (when run from
    the mouse popup menu). If the mouse pointer does not point to a
    character, then an error message should say "No character here"
    or some such.

To be clearer, this is the kind of behavior I would propose for Text
Properties > Describe Properties:

(defun describe-props-at-mouse (event)
  "Describe text properties of character under the mouse pointer"
  (interactive "e")
  (save-excursion
    (set-buffer (window-buffer (posn-window (event-end event))))
    (goto-char (posn-point (event-end event)))
    (describe-text-properties (point))))

The error you get if you point to something other than a character is this:
"No character follows specified position".

Re: Q on Text Properties popup menu - shouldn't it use the pointerposition, not the cursor position?

[Luc Teirlinck]

Drew Adams wrote:

   The Describe Properties item runs describe-text-properties, which always
   references (the character after) point, never a region. Since it references
   a single position, to me the best position to use is the mouse-pointer
   position (when run from the mouse popup menu). If the mouse pointer does not
   point to a character, then an error message should say "No character here"
   or some such.

C-mouse-2 is mainly a menubar substitute and for the menubar, only the
position of point makes sense.

   BTW, I think there might also be a minor bug: Each time I use the Text
   Properties menu I get this message: "<C-drag-mouse-2> is undefined".

This is either operating system specific or fixed in the meantime.  I
can not reproduce with today's CVS on GNU/Linux.  Maybe people running
MS Windows can reproduce it.

Sincerely,

Luc.

RE: Q on Text Properties popup menu - shouldn't it use thepointerposition, not the cursor position?

[Drew Adams]

       The Describe Properties item runs describe-text-properties,
       which always references (the character after) point,
       never a region. Since it references a single position, to
       me the best position to use is the mouse-pointer position
       (when run from the mouse popup menu).

    C-mouse-2 is mainly a menubar substitute and for the menubar, only the
    position of point makes sense.

The cursor position makes sense for the menubar menu (there's no other
choice, as you say), but not for the mouse popup menu. On the popup menu,
being able to just point and interrogate the text properties is useful.

It's sometimes the case already that a menu command is slightly different
from the equivalent command run via `M-x'. I don't see any problem in having
the popup menu item Describe Properties use the character under the pointer
and the menu-bar menu item use the character after (point).

IMO, the popup menu is more useful than the menu-bar menu, anyway, for stuff
like this. Its usefulness shouldn't be limited by what makes sense for the
menu-bar.

RE: Q on Text Properties popup menu - shouldn't it use thepointerposition, not the cursor position?

[Drew Adams]

       bug: Each time I use the Text Properties menu I get this message:
       "<C-drag-mouse-2> is undefined".

    This is either operating system specific or fixed in the meantime.  I
    can not reproduce with today's CVS on GNU/Linux.  Maybe people running
    MS Windows can reproduce it.

I'm curious if others see this bug. I see it systematically on Windows, even
after loading the latest cvs version of facemenu.el (I did not rebuild
Emacs, however).


In GNU Emacs 22.0.50.2 (i386-mingw-nt5.1.2600) of 2005-04-16 on LAPTOP
Distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Re: Q on Text Properties popup menu - shouldn't it use thepointerposition, not the cursor position?

[Luc Teirlinck]

Drew Adams wrote:

	  bug: Each time I use the Text Properties menu I get this message:
	  "<C-drag-mouse-2> is undefined".

       This is either operating system specific or fixed in the meantime.  I
       can not reproduce with today's CVS on GNU/Linux.  Maybe people running
       MS Windows can reproduce it.

   I'm curious if others see this bug. I see it systematically on Windows, even
   after loading the latest cvs version of facemenu.el (I did not rebuild
   Emacs, however).

You really mean: "Each time I use the Text Properties menu..."

>From your previous postings, I thought you meant each time you use
C-mouse-2 to get to that menu, as opposed to getting it from the menu
bar.  (I do not see it _either_ way, however.)

Sincerely,

Luc.

Re: Q on Text Properties popup menu - shouldn't it use thepointerposition, not the cursor position?

[Luc Teirlinck]

>From my previous reply:

   You really mean: "Each time I use the Text Properties menu..."

I meant:

Do you really mean: "Each time I use the Text Properties menu..."?

Sincerely,

Luc.

RE: Q on Text Properties popup menu - shouldn't it usethepointerposition, not the cursor position?

[Drew Adams]

    	  bug: Each time I use the Text Properties menu I get this message:
    	  "<C-drag-mouse-2> is undefined".

           This is either operating system specific or fixed in the
           meantime. I can not reproduce with today's CVS on GNU/Linux.
Maybe
           people running MS Windows can reproduce it.

       I'm curious if others see this bug. I see it systematically
       on Windows, even after loading the latest cvs version of facemenu.el
       (I did not rebuild Emacs, however).

    You really mean: "Each time I use the Text Properties menu..."

    From your previous postings, I thought you meant each time you use
    C-mouse-2 to get to that menu, as opposed to getting it from the menu
    bar.  (I do not see it _either_ way, however.)

Sorry. I meant each time I use C-mouse-2 to get to the menu. Via the
menu-bar, I see this each time: "menu-bar edit props dp".

RE: Q on Text Properties popup menu - shouldn't it usethepointerposition, not the cursor position?

[Drew Adams]

           bug: Each time I use the Text Properties menu I get
           this message: "<C-drag-mouse-2> is undefined".

Apparently, the mouse drag through the menu is causing a C-drag-mouse-2
event, which is then treated as pending input.

This messes up use of a menu item that I've added locally. The new menu item
reads input, and it gets confused by the extra pending input. That's how I
came across the bug and why it bothers me.

Do this, as a test:

(easy-menu-do-add-item facemenu-menu ["Test" test-fn t])

(defun test-fn ()
  (interactive)
  (message "last input event: %s, input-pending-p: %s"
           last-input-event (input-pending-p))
  (sleep-for 5))

Choose item "Test" in the facemenu-menu, via C-mouse-2.
I see this message:

  last input event: Test, input-pending-p: t

After the sleep-for, I see this in the echo area:

  <C-drag-mouse-2> is undefined

If I put a `read-char' in the test-fn, it chokes on the pending non-keyboard
input event C-drag-mouse-2, showing that this is indeed the guilty pending
event.

If I access the same Test menu item from the menu-bar (Edit > Test
Properties > Test), I see this:

  last input event: Test, input-pending-p: nil

So this is really a problem for the popup mouse menu (only).

RE: Q on Text Properties popup menu - shouldn't it usethepointerposition, not the cursor position?

[Drew Adams]

               bug: Each time I use the Text Properties popup menu I get
               this message: "<C-drag-mouse-2> is undefined".

I should have added that I see the same behavior in Emacs 20, so this is
apparently nothing new.

RE: Q on Text Properties popup menu - shouldn't itusethepointerposition, not the cursor position?

[Drew Adams]

FYI -

For those interested in what I was trying to suggest wrt using the mouse
pointer position for getting at text properties, see
http://www.emacswiki.org/elisp/facemenu+.el.

With this code, the Text Properties menu uses the cursor position (point)
when it is accessed from the menu-bar and the mouse pointer position when it
is accessed via mouse popup menu (C-mouse-2). So, for instance, you can
point the mouse at some text and pick Describe Properties to see its text
properties.

I also added items "Change Face Foreground", "Change Face Background", and
"Change Face Attribute" to the menu. The first two let you change a face
incrementally (using the arrow keys or mouse wheel). Using the C-mouse-2
popup menu, you can just point to some text that has a face and change the
face's colors incrementally. No need to know the face name or color
names/values beforehand: just point and tweak.

The code also lets Customize know that you've changed the face, so changing
the face this way is equivalent to changing it via Customize (using a face
name and color name). The library that does the incremental face changing
(used by facemenu+el) is here: http://www.emacswiki.org/elisp/doremi-frm.el.

The same idea could be extended to other properties/features that users
currently change by name, such as font properties (height, weight, etc.).
The idea is to provide for more direct manipulation: you see a
face/font/frame-parameter/whatever; you tweak it directly, without having to
know its name or the names of its properties and their possible values; you
can save the change via Customize.

RE: Q on Text Properties popup menu - shouldn't itusethepointerposition, not the cursor position?

[Drew Adams]

My post about http://www.emacswiki.org/elisp/facemenu+.el could give the
impression that without it users need to know the face name, in order to
customize the face applied to given text. As Juri pointed out, M-x customize
comes up with the face name by default.

My facemenu code just provides another way to change face colors, besides
choosing them by name, and makes this available on the Text Properties menu.

Re: Q on Text Properties popup menu - shouldn't itusethepointerposition, not the cursor position?

[Richard M. Stallman]

    With this code, the Text Properties menu uses the cursor position (point)
    when it is accessed from the menu-bar and the mouse pointer position when it
    is accessed via mouse popup menu (C-mouse-2). So, for instance, you can
    point the mouse at some text and pick Describe Properties to see its text
    properties.

Does this mean only for the menu items that operate on a single position?
Changing the text properties applies to a region, and the only sensible
thing for it to do is act on _the_ region, as it does now.

    I also added items "Change Face Foreground", "Change Face Background", and
    "Change Face Attribute" to the menu. The first two let you change a face
    incrementally (using the arrow keys or mouse wheel). Using the C-mouse-2
    popup menu, you can just point to some text that has a face and change the
    face's colors incrementally. No need to know the face name or color
    names/values beforehand: just point and tweak.

That is completely unrelated to changing the text properties of some
text, but it could be a useful feature, if it makes face customization
really easy.  Can you describe the interface?  How do you use the
mouse to change a color?  Colors are in a 3-dimensional space,
and the mouse moves only in two dimensions.

RE: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?

[Drew Adams]

        With this code, the Text Properties menu uses the cursor
        position (point) when it is accessed from the menu-bar
        and the mouse pointer position when it is accessed via
        mouse popup menu (C-mouse-2). So, for instance, you can
        point the mouse at some text and pick Describe Properties
        to see its text properties.

    Does this mean only for the menu items that operate on a single
    position?

Yes. The menu looks like this - I added the last two separators and the last
three items:

 Text Properties
 ----------------------
 Face >
 Foreground Color >
 Background Color >
 Special Properties >
 ----------------------
 Justification >
 Indentation >
 ----------------------
 Remove Face Properties
 Remove Text Properties
 ----------------------
 Describe Properties
 Display Faces
 Display Colors
 ----------------------
 Change Face Foreground
 Change Face Background
 Change Face Attribute

    Changing the text properties applies to a region, and the only sensible
    thing for it to do is act on _the_ region, as it does now.

Agreed. There is no change in this regard.

BTW, I was not making a suggestion to change anything in Emacs, except for
letting Describe Properties act on the pointer position (not point) when
called from the popup menu.

There are three classes of commands in this menu:

 - those acting on the region
 - those acting on the character after point (or under the mouse pointer)
 - those acting without regard to any object (intransitive), such as Display
Faces

To make things clearer, we might want to put all of the items acting on the
region in a "Region" submenu. Alternatively, we might put all of the
commands acting at a single position on a "Here" submenu.

In my own local version, for instance, I added some region commands to the
Edit menu and put them in two submenus, Edit Region (for stuff like tabify
and upcase) and Sort Region (for different ways to sort the region).

I'll respond to your questions about Do Re Mi separately.

Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?)

[Drew Adams]

        I also added items "Change Face Foreground", "Change Face
        Background", and "Change Face Attribute" to the menu. The
        first two let you change a face incrementally (using the
        arrow keys or mouse wheel). Using the C-mouse-2 popup menu,
        you can just point to some text that has a face and change the
        face's colors incrementally. No need to know the face name or color
        names/values beforehand: just point and tweak.

    That is completely unrelated to changing the text properties of some
    text, but it could be a useful feature, if it makes face customization
    really easy.  Can you describe the interface?  How do you use the
    mouse to change a color?  Colors are in a 3-dimensional space,
    and the mouse moves only in two dimensions.

Right; it is unrelated, except that it is a way to change the foreground and
background properties of a face or a frame.

I mentioned the incremental-change behavior previously (search for "doremi"
in archive for Nov or Dec 2004). A writeup is here:
http://www.emacswiki.org/cgi-bin/wiki/DoReMi. The same technique is used for
resizing and moving frames, zooming frames (font size), and cycling through
buffers, bookmarks, marks, or color themes, and other incremental or cyclic
changes. The idea is to (re)use the arrow keys for different commands.

Here's what the user experiences (it's easier to try it than to explain it,
however):

1. C-mouse-2 on text in, say, face `font-lock-comment'.
Choose "Change Face Foreground" in the popup "Text Properties" menu.

Alternatively, use `M-x doremi-face-fg'; that command prompts you for the
face to change.

2. Prompt appears in minibuffer:

"Change foreground of `font-lock-comment'. Adjust red, green, blue, hue,
saturation, or value? [rgbhsv]"

3. Enter one of the characters [rgbhsv]. Let's say you enter `r', for
incrementing/decrementing the red color component.

Note 1: You can do this (change color component) at any time during
incremental color change (step 4). For example, if you are incrementing the
red color component and you hit `v', then you switch immediatly to
incrementing the value color component. This is very useful; in effect, it
means that you need not reason in terms of RGB or HSV. A combination of
value changes and RGB changes, for instance, is often handy. You need not
think at all, in fact: just adjust a component to see what it does -
WYSIWYG. You can quickly obtain the color you want.

Note 2: The increment is set by default so as to give you a reasonable
change with each incrementation. You can change the increment, however, to
give you as fine control of the color as you need.

Note 3: Color models RGB, HSV, and CMY are handled. Color components cyan,
magenta, and yellow are just the opposite of components red, green, and
blue, respectively. Incrementing one is the same as decrementing the other.
So, for instance, if you want to increment magenta, just decrement (down
arrow) green.

4. Prompt appears in minibuffer:

"Use up, down, or mouse wheel to adjust value (modifier key: faster). Value
now: Firebrick"

or whatever your current foreground value of `font-lock-comment' is - mine
is Firebrick.

5. Use the up or down key, or the mouse wheel, to increment or decrement the
current red value. The foreground property of the face is changed - you can
see the result immediately on any buffers showing that face.

After each up/down/wheel action, the prompt echoes the (new) current value.
Color values are from now on expressed in the hex form #RRRRGGGGBBBB (red,
green, blue). For example, the prompt looks like this after hitting the up
arrow once:

"Use up, down, or mouse wheel to adjust value (modifier key: faster). Value
now: #B3B222222222"

After hitting the up arrow again, this is the prompt:

"Use up, down, or mouse wheel to adjust value (modifier key: faster). Value
now: #B4B222222222"

You can just hold down an arrow key to repeat its action and keep
incrementing. The echoed value is updated accordingly - just watch it spin
like an odometer. You can go back and forth with the up and down keys, until
you get just what you want.

If you hold down a modifier key (by default, `Meta') while using the arrow
keys or mouse wheel, then the incrementation is boosted: the increment is
larger. Use it to get quickly in the neighborhood of the color you want. The
prompt text "(modifier key: faster)" indicates this possibility. Do Re Mi
commands (such as `doremi-bookmarks') that cycle through enumerations,
instead of incrementing numerical values, do not have this modifier
behavior, with its prompt.

Note: Other Do Re Mi commands use all four arrows, if appropriate. For
instance, a command for resizing frames lets you use all four to grow/shrink
both width and height. This is actually accomplished by having two Do Re Mi
commands, one for each dimension, bound to up/down and left/right arrows
respectively. Each command calls the other at the end, if the other's arrows
are used. The user just seamlessly uses any of the four arrows, without
exiting from the initial command.

6. When you finally get the color you want, just do anything other than
[rgbhsv], up, down, or mouse-wheel, to exit. This message then appears in
the echo area:

"Use `customize-customized' to revisit changes."

The updated value is communicated to Customize, so it will show that the
face foreground was "set" in Customize (i.e. it cheats) and it can be saved
there.

RE: Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, not the cursor position?)

[Drew Adams]

    1. C-mouse-2 on text in, say, face `font-lock-comment'.
    Choose "Change Face Foreground" in the popup "Text Properties" menu.
    Alternatively, use `M-x doremi-face-fg'; that command prompts
    you for the face to change.

    2. Prompt appears in minibuffer: Change foreground of
    `font-lock-comment'. Adjust red, green, blue, hue, saturation...

    3. Enter one of the characters [rgbhsv].

I neglected to mention that at the end of step 3 a "*Face Sample*" buffer is
popped up showing sample text in the face. This is more important for `M-x
doremi-face-fg', where you might choose a face that is not currently
displayed. In the case of "Change Face Foreground" (which calls
`doremi-face-fg'), the current buffer shows the face.

Re: Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?)

[Richard M. Stallman]

Do Re Mi sounds very nice, but I think it might want to also use the mouse
as an alternative to the arrow keys.  Also, in some cases it might be
good to map two dimensions of the color space at a time, not just one.

Can you email me a copy of the program, with the author's name and
email address?

RE: Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, not the cursor position?)

[Drew Adams]

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

    Do Re Mi sounds very nice, but I think it might want to also
    use the mouse as an alternative to the arrow keys.

Not sure what you mean. You can currently use the mouse wheel as well as the
arrow keys. Were you perhaps thinking of using mouse gestures?

    Also, in some cases it might be
    good to map two dimensions of the color space at a time, not just one.

It could be done, I suppose. But, unless you would limit that to 45 degree
diagonals (equal changes in two dimensions), which is not that useful, I
think a different approach would be called for; that is, use a different,
more sophisticated interface, such as that provided by various other apps.

The Custom tab of the Colors dialog box of Word is a good (typical?)
example. It's difficult to describe, so I've attached an image. You can use
it to:

 - Set color components absolutely, using RGB or HSV. You can change any of
these components incrementally.

 - Pick a color from a spectrum display whose saturation changes in the
orthogonal axis (that is, hue x saturation). After picking a spot in this
color plane, you can use the arrow keys to change the saturation (up, down)
or hue (left, right) incrementally. You can also drag the pointer around the
display to change the color.

 - Change only the value, using an associated scale. That is, the third,
value axis is shown separately, next to the hue x saturation plane. You can
use the arrow keys to move the slider along this scale, incrementally
changing the value.

The current color is shown, along with the new color (the one you are
changing). The new color is updated in all displays (RGB, HSV, hue x
saturation plane, value scale) as you change it.

The only disadvantage of such a dialog box wrt doremi is that you don't see
the result reflected immediately in the context of your Emacs buffers - you
see it only in the dialog-box color swatches (New, Current). But we could
choose to also show the changes simultaneously in Emacs buffers.

I'm only suggesting that doremi is rudimentary, compared to something like
the Word dialog box. To change more than one color component at the same
time, it's better to have an interface that shows a color space, such as in
the Word dialog box.

[-- Attachment #2: color-db.jpg --]
[-- Type: image/jpeg, Size: 62256 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: Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, not the cursor position?)

[Robert J. Chassell]

Perhaps you could simply adapt the four color selectors available in
the GIMP; the first is what you describe.  The other three do the same
thing, but with different interfaces.  Obviously, one wants to change
more than one color component at the same time, so the four interfaces
may need some adaption.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, not the cursor position?)

[Drew Adams]

    Perhaps you could simply adapt the four color selectors available in
    the GIMP; the first is what you describe.  The other three do the same
    thing, but with different interfaces.

Where can they be found?

    Obviously, one wants to change
    more than one color component at the same time...

Not so obvious to me. Changing more than one at a time can be useful, but I
think changing one at a time is also useful, especially if you can move from
one to the next easily.

Re: Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, not the cursor position?)

[Robert J. Chassell]

       Perhaps you could simply adapt the four color selectors
       available in the GIMP ...

   Where can they be found?

For the sources, take a look at    http://www.gimp.org/source/

For examples, in an instance of the GIMP, double click on the
foreground/background item of the main control frame.

       Obviously, one wants to change more than one color component at
       the same time...

   Not so obvious to me. ...

My apologies; I was not clear.  I meant:  if you change a background,
then you may well want to change a foreground in a coordinated
fashion.  If, as you say, you can move from one to the next easily and
keep a sample of the previously set color, then you are fine.

The key is keeping a sample of the previously set color (unless you
have very good color memory; and few do).  The interfaces I have seen
show you the previous color of the one you are currently setting in a
big rectangle.  You also will want to see previously set colors.

Each of the four the GIMP color interfaces has a set of squares
showing the previously set colors.  Maybe all they need is to be made
bigger and closer to the `current setting' rectangle.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, not the cursor position?)

[Richard M. Stallman]

	Also, in some cases it might be
	good to map two dimensions of the color space at a time, not just one.

    It could be done, I suppose. But, unless you would limit that to 45 degree
    diagonals (equal changes in two dimensions), which is not that useful,

I think we are miscommunicating.  I'm thinking that horizontal arrows
could alter one dimension in color space, while vertical arrows
could alter another dimension.

Since it doesn't have to be limited to arrows, another pair of keys
could move in the third dimension of color space.

     To change more than one color component at the same
    time, it's better to have an interface that shows a color space, such as in
    the Word dialog box.

That sounds plausible.  I wonder if that could be programmed in Emacs
Lisp.  Also, some toolkits may have a widget for doing this job,
and maybe Emacs could invoke it somehow.

RE: Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, not the cursor position?)

[Drew Adams]

    	Also, in some cases it might be
    	good to map two dimensions of the color space at a time,
      not just one.

        It could be done, I suppose. But, unless you would limit
        that to 45 degree
        diagonals (equal changes in two dimensions), which is not
        that useful,

    I think we are miscommunicating.  I'm thinking that horizontal arrows
    could alter one dimension in color space, while vertical arrows
    could alter another dimension.

    Since it doesn't have to be limited to arrows, another pair of keys
    could move in the third dimension of color space.

You can only press one arrow at a time (you can press two, but only one
takes effect).

Using modifier keys it would be possible to truly alter two dimensions at
once, but only in equal (or predefined, constant) proportions. You could
assign any key sequence to such a predefined change, of course.

To allow altering more than one dimension at the same time, in varying
proportions, you need more graphic input - a la the Word dialog box.

Currently, in the doremi color commands, you use up and down arrows for each
color component (no matter which component), and just type [rgbhsv] at any
time to change to a different component. E.g. r up up g down down b down up
up v down down. Simple.

To respond to your suggestion, it would be possible to change things so that
you could use up/down for, say, red, left/right for, say, green, and two
other keys for blue. The (small) advantage is not having to type a `r', `g',
or `b' to switch between components.

That is what I do, for instance, for the doremi frame movement and resizing
commands. In that case, there is a natural association between left/right
arrows and horizontal movement or resizing, and similarly for up/down &
vertical.

For color components, I don't see the advantage of not having to specify the
current component [rgbhsv] outweighing the confusion of keeping straight
which component corresponds to which keys. And, since there are two color
models (RGB & HSV), you would need six key-pair assignments, or you would
still need some way to switch between the models (RGB vs HSV).

        To change more than one color component at the same
        time, it's better to have an interface that shows a color
        space, such as in the Word dialog box.

    That sounds plausible.  I wonder if that could be programmed in Emacs
    Lisp.  Also, some toolkits may have a widget for doing this job,
    and maybe Emacs could invoke it somehow.

Those are things to explore. Bob Chassell suggested using existing Gimp code
that does this kind of thing. Otherwise, it could be done in Lisp, I'm sure,
using small colored characters as the tiny color swatches (no need for
graphics) - a block character could be used.