* Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position? @ 2005-06-24 15:25 Drew Adams 2005-06-24 15:58 ` Luc Teirlinck 2005-06-24 16:09 ` Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position? Luc Teirlinck 0 siblings, 2 replies; 26+ messages in thread From: Drew Adams @ 2005-06-24 15:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position? 2005-06-24 15:25 Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position? Drew Adams @ 2005-06-24 15:58 ` Luc Teirlinck 2005-06-24 16:37 ` Q on Text Properties popup menu - shouldn't it use the pointerposition, " Drew Adams 2005-06-24 16:09 ` Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position? Luc Teirlinck 1 sibling, 1 reply; 26+ messages in thread From: Luc Teirlinck @ 2005-06-24 15:58 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn't it use the pointerposition, not the cursor position? 2005-06-24 15:58 ` Luc Teirlinck @ 2005-06-24 16:37 ` Drew Adams 2005-06-24 16:48 ` Drew Adams 2005-06-24 23:08 ` Luc Teirlinck 0 siblings, 2 replies; 26+ messages in thread From: Drew Adams @ 2005-06-24 16:37 UTC (permalink / raw) 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)' ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn't it use the pointerposition, not the cursor position? 2005-06-24 16:37 ` Q on Text Properties popup menu - shouldn't it use the pointerposition, " Drew Adams @ 2005-06-24 16:48 ` Drew Adams 2005-06-24 23:08 ` Luc Teirlinck 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2005-06-24 16:48 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Q on Text Properties popup menu - shouldn't it use the pointerposition, not the cursor position? 2005-06-24 16:37 ` Q on Text Properties popup menu - shouldn't it use the pointerposition, " Drew Adams 2005-06-24 16:48 ` Drew Adams @ 2005-06-24 23:08 ` Luc Teirlinck 2005-06-24 23:35 ` Q on Text Properties popup menu - shouldn't it use thepointerposition, " Drew Adams 2005-06-25 22:53 ` Drew Adams 1 sibling, 2 replies; 26+ messages in thread From: Luc Teirlinck @ 2005-06-24 23:08 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn't it use thepointerposition, not the cursor position? 2005-06-24 23:08 ` Luc Teirlinck @ 2005-06-24 23:35 ` Drew Adams 2005-06-25 22:53 ` Drew Adams 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2005-06-24 23:35 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn't it use thepointerposition, not the cursor position? 2005-06-24 23:08 ` Luc Teirlinck 2005-06-24 23:35 ` Q on Text Properties popup menu - shouldn't it use thepointerposition, " Drew Adams @ 2005-06-25 22:53 ` Drew Adams 2005-06-25 23:17 ` Luc Teirlinck ` (2 more replies) 1 sibling, 3 replies; 26+ messages in thread From: Drew Adams @ 2005-06-25 22:53 UTC (permalink / raw) 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)' ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Q on Text Properties popup menu - shouldn't it use thepointerposition, not the cursor position? 2005-06-25 22:53 ` Drew Adams @ 2005-06-25 23:17 ` Luc Teirlinck 2005-06-25 23:32 ` Q on Text Properties popup menu - shouldn't it usethepointerposition, " Drew Adams 2005-06-25 23:29 ` Q on Text Properties popup menu - shouldn't it use thepointerposition, " Luc Teirlinck 2005-06-26 1:26 ` Q on Text Properties popup menu - shouldn't it usethepointerposition, " Drew Adams 2 siblings, 1 reply; 26+ messages in thread From: Luc Teirlinck @ 2005-06-25 23:17 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn't it usethepointerposition, not the cursor position? 2005-06-25 23:17 ` Luc Teirlinck @ 2005-06-25 23:32 ` Drew Adams 0 siblings, 0 replies; 26+ messages in thread From: Drew Adams @ 2005-06-25 23:32 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Q on Text Properties popup menu - shouldn't it use thepointerposition, not the cursor position? 2005-06-25 22:53 ` Drew Adams 2005-06-25 23:17 ` Luc Teirlinck @ 2005-06-25 23:29 ` Luc Teirlinck 2005-06-26 1:26 ` Q on Text Properties popup menu - shouldn't it usethepointerposition, " Drew Adams 2 siblings, 0 replies; 26+ messages in thread From: Luc Teirlinck @ 2005-06-25 23:29 UTC (permalink / raw) Cc: emacs-devel >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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn't it usethepointerposition, not the cursor position? 2005-06-25 22:53 ` Drew Adams 2005-06-25 23:17 ` Luc Teirlinck 2005-06-25 23:29 ` Q on Text Properties popup menu - shouldn't it use thepointerposition, " Luc Teirlinck @ 2005-06-26 1:26 ` Drew Adams 2005-06-26 1:29 ` Drew Adams 2005-06-27 0:07 ` Q on Text Properties popup menu - shouldn't itusethepointerposition, " Drew Adams 2 siblings, 2 replies; 26+ messages in thread From: Drew Adams @ 2005-06-26 1:26 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn't it usethepointerposition, not the cursor position? 2005-06-26 1:26 ` Q on Text Properties popup menu - shouldn't it usethepointerposition, " Drew Adams @ 2005-06-26 1:29 ` Drew Adams 2005-06-27 0:07 ` Q on Text Properties popup menu - shouldn't itusethepointerposition, " Drew Adams 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2005-06-26 1:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn't itusethepointerposition, not the cursor position? 2005-06-26 1:26 ` Q on Text Properties popup menu - shouldn't it usethepointerposition, " Drew Adams 2005-06-26 1:29 ` Drew Adams @ 2005-06-27 0:07 ` Drew Adams 2005-06-27 0:46 ` Drew Adams 2005-06-27 16:46 ` Richard M. Stallman 1 sibling, 2 replies; 26+ messages in thread From: Drew Adams @ 2005-06-27 0:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn't itusethepointerposition, not the cursor position? 2005-06-27 0:07 ` Q on Text Properties popup menu - shouldn't itusethepointerposition, " Drew Adams @ 2005-06-27 0:46 ` Drew Adams 2005-06-27 16:46 ` Richard M. Stallman 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2005-06-27 0:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Q on Text Properties popup menu - shouldn't itusethepointerposition, not the cursor position? 2005-06-27 0:07 ` Q on Text Properties popup menu - shouldn't itusethepointerposition, " Drew Adams 2005-06-27 0:46 ` Drew Adams @ 2005-06-27 16:46 ` Richard M. Stallman 2005-06-27 22:35 ` Q on Text Properties popup menu - shouldn'titusethepointerposition, " Drew Adams 2005-06-27 22:41 ` Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?) Drew Adams 1 sibling, 2 replies; 26+ messages in thread From: Richard M. Stallman @ 2005-06-27 16:46 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position? 2005-06-27 16:46 ` Richard M. Stallman @ 2005-06-27 22:35 ` Drew Adams 2005-06-27 22:41 ` Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?) Drew Adams 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2005-06-27 22:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?) 2005-06-27 16:46 ` Richard M. Stallman 2005-06-27 22:35 ` Q on Text Properties popup menu - shouldn'titusethepointerposition, " Drew Adams @ 2005-06-27 22:41 ` Drew Adams 2005-06-28 18:43 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Drew Adams 2005-06-28 18:47 ` Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, " Richard M. Stallman 1 sibling, 2 replies; 26+ messages in thread From: Drew Adams @ 2005-06-27 22:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, not the cursor position?) 2005-06-27 22:41 ` Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?) Drew Adams @ 2005-06-28 18:43 ` Drew Adams 2005-06-28 18:47 ` Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, " Richard M. Stallman 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2005-06-28 18:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?) 2005-06-27 22:41 ` Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?) Drew Adams 2005-06-28 18:43 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Drew Adams @ 2005-06-28 18:47 ` Richard M. Stallman 2005-06-28 19:53 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Drew Adams 1 sibling, 1 reply; 26+ messages in thread From: Richard M. Stallman @ 2005-06-28 18:47 UTC (permalink / raw) Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, not the cursor position?) 2005-06-28 18:47 ` Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, " Richard M. Stallman @ 2005-06-28 19:53 ` Drew Adams 2005-06-28 20:33 ` Robert J. Chassell 2005-06-29 3:59 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Richard M. Stallman 0 siblings, 2 replies; 26+ messages in thread From: Drew Adams @ 2005-06-28 19:53 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, not the cursor position?) 2005-06-28 19:53 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Drew Adams @ 2005-06-28 20:33 ` Robert J. Chassell 2005-06-28 21:01 ` Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, " Drew Adams 2005-06-29 3:59 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Richard M. Stallman 1 sibling, 1 reply; 26+ messages in thread From: Robert J. Chassell @ 2005-06-28 20:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, not the cursor position?) 2005-06-28 20:33 ` Robert J. Chassell @ 2005-06-28 21:01 ` Drew Adams 2005-06-29 0:42 ` Robert J. Chassell 0 siblings, 1 reply; 26+ messages in thread From: Drew Adams @ 2005-06-28 21:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, not the cursor position?) 2005-06-28 21:01 ` Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, " Drew Adams @ 2005-06-29 0:42 ` Robert J. Chassell 0 siblings, 0 replies; 26+ messages in thread From: Robert J. Chassell @ 2005-06-29 0:42 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, not the cursor position?) 2005-06-28 19:53 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Drew Adams 2005-06-28 20:33 ` Robert J. Chassell @ 2005-06-29 3:59 ` Richard M. Stallman 2005-06-29 14:52 ` Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, " Drew Adams 1 sibling, 1 reply; 26+ messages in thread From: Richard M. Stallman @ 2005-06-29 3:59 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, not the cursor position?) 2005-06-29 3:59 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Richard M. Stallman @ 2005-06-29 14:52 ` Drew Adams 0 siblings, 0 replies; 26+ messages in thread From: Drew Adams @ 2005-06-29 14:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position? 2005-06-24 15:25 Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position? Drew Adams 2005-06-24 15:58 ` Luc Teirlinck @ 2005-06-24 16:09 ` Luc Teirlinck 1 sibling, 0 replies; 26+ messages in thread From: Luc Teirlinck @ 2005-06-24 16:09 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2005-06-29 14:52 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-06-24 15:25 Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position? Drew Adams 2005-06-24 15:58 ` Luc Teirlinck 2005-06-24 16:37 ` Q on Text Properties popup menu - shouldn't it use the pointerposition, " Drew Adams 2005-06-24 16:48 ` Drew Adams 2005-06-24 23:08 ` Luc Teirlinck 2005-06-24 23:35 ` Q on Text Properties popup menu - shouldn't it use thepointerposition, " Drew Adams 2005-06-25 22:53 ` Drew Adams 2005-06-25 23:17 ` Luc Teirlinck 2005-06-25 23:32 ` Q on Text Properties popup menu - shouldn't it usethepointerposition, " Drew Adams 2005-06-25 23:29 ` Q on Text Properties popup menu - shouldn't it use thepointerposition, " Luc Teirlinck 2005-06-26 1:26 ` Q on Text Properties popup menu - shouldn't it usethepointerposition, " Drew Adams 2005-06-26 1:29 ` Drew Adams 2005-06-27 0:07 ` Q on Text Properties popup menu - shouldn't itusethepointerposition, " Drew Adams 2005-06-27 0:46 ` Drew Adams 2005-06-27 16:46 ` Richard M. Stallman 2005-06-27 22:35 ` Q on Text Properties popup menu - shouldn'titusethepointerposition, " Drew Adams 2005-06-27 22:41 ` Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, not the cursor position?) Drew Adams 2005-06-28 18:43 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Drew Adams 2005-06-28 18:47 ` Do Re Mi (was: Q on Text Properties popup menu - shouldn'titusethepointerposition, " Richard M. Stallman 2005-06-28 19:53 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Drew Adams 2005-06-28 20:33 ` Robert J. Chassell 2005-06-28 21:01 ` Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, " Drew Adams 2005-06-29 0:42 ` Robert J. Chassell 2005-06-29 3:59 ` Do Re Mi (was: Q on Text Properties popup menu -shouldn'titusethepointerposition, " Richard M. Stallman 2005-06-29 14:52 ` Do Re Mi (was: Q on Text Properties popup menu-shouldn'titusethepointerposition, " Drew Adams 2005-06-24 16:09 ` Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position? Luc Teirlinck
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.