RE: Customize buttons that change user's customfileshouldaskforconfirmation
Set All (F => C) Save All (F => C,S) Get All that can be automatically written by custom-set-* What is the nuance here? Just what is _not_ being gotten (what values cannot be automatically written by custom-set*)? Standard (D => F,C) Saved (S => F,C) Current(C => F,C) Presumably, `Set All' means `evaluate new values specified in your initialization file, both those automatically written by custom-set-* as well as those you have written manually, but do not write the new initialization file'. I don't understand this. Set All (F=>C) means set all current values (C) to the values shown in the edit fields (F). What does this have to do with the init file? Presumably, `Save All' means simply `automatically write custom-set-* values into your initialization file, write that file, and then evaluate it'. I was with you up until the last clause, "and then evaluate it". I don't believe that is the current behavior or what is expressed by F=>C,S (set current values from edit fields and save edit fields to custom file). Evaluating the custom file would do a lot more than F=>C, and I expect that that would introduce unwanted behavior. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's customfileshouldaskforconfirmation
> Set All (F => C) > Save All (F => C,S) > Get All >Standard (D => F) >Saved (S => F) >Current(C => F) > > This is clean and symmetric, and I agree with the plan to replace > Erase Customizations with Get All Standard Values. However, the > command Reset to Saved is a clean and useful command, and I think that > replacing it with Get All Saved Values would be a step backwards. > > How to get the best of both worlds? Perhaps like this: > > Set All (F => C) > Save All (F => C,S) > Get All >Standard (D => F,C) >Saved (S => F,C) >Current(C => F,C) I believe the logical structure Miles first suggested (essentially the first one above) with the enhancement above with a single "Get All"-button is the best. It gives the possibility to preview the values before setting them. I agree (obviously). I could live with the second set of buttons, except that they all _set_ the current value, so they should be called Set All *, which produces confusion with F => C. Set All (F => C) Save All (F => C,S) Reset to Saved (S => F,C) Get All Standard (D => F) Saved (S => F) Current(C => F) No; I think we should avoid Reset to Saved. First, because it uses the confusing term "Reset" (which means other things in many preference editors). Second, it is simply Get All Saved followed by Set All, which is just two clicks and is much clearer. I don't see the disadvantage of the first group above. Why is F => C,S helpful/needed? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user'scustomfileshouldaskforconfirmation
I don't understand this. Set All (F=>C) means set all current values (C) to the values shown in the edit fields (F). What does this have to do with the init file? Everything is written to the init file (or files loaded from it); that is where customization forms are evaluated. So `Set All (F=>C)' means to set in the init file those values changed by customize. I don't think so. I don't think that's what happens now, at least, for Set. "Setting" something in the init file is really (automatically editing and) _saving_ it. The term "set" refers today to setting the _current value_. Or are you suggesting that the form be evaluated in some place a user cannot see? I can understand doing that; but it makes it less likely that the person will learn to write simple forms. Customization is, after all, an automatic expression writing and evaluating function. Not only do people like to see what the Lisp expression looks like, we want to encourage them to do so! After all, that leads to hacking. See above. AFAIK, Set is not involved with custom-set* in any way; it simply does F=>C. The customize automatic expression writing action is rather like the (not very good) function that came with Calc mode more than a decade ago and since been removed. The difference is that the Calc mode automatic expression writing function wrote `defun' expressions and could handle anything you could put in a keyboard macro of the time; the Customization functions write `custom-set-*' expressions instead. Presumably, `Save All' means simply `automatically write custom-set-* values into your initialization file, write that file, and then evaluate it'. I was with you up until the last clause, "and then evaluate it". Well, when you `Save for Future Sessions' the new value takes effect right away. The expression is evaluated. At least, that is what happens now. (I just checked.) So save `all' must mean that _all_ customizations are saved and also evaluated. That means saving and evaluating your .emacs file. Perhaps the button should be reworded to `Set and Save All'. That is clearer to me; I prefer this wording. But it takes more room. The help (or `tip') on the button or function should explain that saving the init file also involves evaluating it, so the new valued become effective, that is, they become set as well as saved. Save does mean set and save, so, yes, the current value is updated to the same value that is written to your custom file. That is not the same thing as evaluating your entire .emacs file, however. I personally think that "Save" is clear enough, but you are correct that the semantics behind the button are set and save. The tooltip and doc string could make that explicit, as you suggest. Actually, the more I think about it, the more I like the rewording to `Set and Save All' even if it is longer. After all, you can set values in your initialization file without saving it; and you can save it without evaluating it. You have led to a good point. How can you save Customize settings without also setting their current values (today)? And, again, changing a value in your init file is not what is meant currently by "set"; "set" refers to setting the current values. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's customfileshouldaskforconfirmation
I am not sure whether the change from S => F,C into S => F is a good idea. Agreed. See proposal above. What does "proposal above" refer to? I don't see anything that appears to relate to this. My bad. I read what you wrote backward, I guess. The proposal I meant was my proposal of 2/6/2005, which was also quoted in the mail you quote: Here is what I would propose: Set All (F => C) Save All (F => C,S) Get All Standard (D => F) Saved (S => F) Current(C => F) 1. Each button name includes "All". Likewise for menu-bar menu items. 2. The "resetting" actions only fill the edit field; they do not set the current value. 3. The "resetting" actions are combined in a button menu (pulldown list). My reply to a different message also makes clear that I still think S => F is preferable to S => C,F: No; I think we should avoid Reset to Saved. First, because it uses the confusing term "Reset" (which means other things in many preference editors). Second, it is simply Get All Saved followed by Set All, which is just two clicks and is much clearer. I don't see the disadvantage of the first group above. Why is F => C,S helpful/needed? However, there is a typo there also. The last line should have S => F,C instead of F => S,C. To be clear: I prefer not to have S => F,C (Reset to Saved), but to have instead S => F (Get All Saved) followed by F => C (Set All). Sorry for the confusion. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that changeuser'scustomfileshouldaskforconfirmation
... the current value is updated to the same value that is written to your custom file. That is not the same thing as evaluating your entire .emacs file, however. I am refering to `All'. Clearly, individual settings should not involve evaluating your entire .emacs file. "All" refers, in Customize, to all options in the current Customize buffer. Your .emacs can involve lots of other things. Your .emacs is not currently eval'd when you do anything in Customize, AFAIK, and it would be a mistake to reevaluate .emacs, IMO. You are correct, however, that Save in Customize means Set and Save - that is, those particular options listed in the current Customize buffer are both set and saved. How can you save Customize settings without also setting their current values (today)? And, again, changing a value in your init file is not what is meant currently by "set"; "set" refers to setting the current values. Just by saving them: for example, just now I changed my bold face ... to '(bold ((t (:background "DodgerBlue4" :foreground "Red" OK. You're talking about editing _.emacs_ and saving it (correct?). Within _Customize_, there is no way to Save without also setting, IIUC - that is what I meant. However, unlike Emacs Lisp expressions saved in regular libraries, Emacs Lisp expressions used for customization are saved in your .emacs file. That file is automatically loaded each time you start a new instance of Emacs. So customized saving implies (eventual) evaluation. Yes, eval of .emacs occurs upon startup (only). If we do not offer a `Save for the future, but not for this session' option for the automatic writing user interface, it might reduce potential confusion just a little to say `Set and Save All' and besides saving, set for current use as well as after the next start. That is the current (and proposed) behavior: Save (in Customize) means set and save. I personally think that "Save" is sufficient as the name, but I agree that all help for the button/menu item should explicitly mention that it both _sets_ and saves. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Changed outside --> set, in Customize UI
I [RMS] said: To avoid confusion. In general, it is a good idea to separate the values that users set from the values that programs set. You [Drew] responded with a misunderstanding: Pick a level of unity for the "Set" (vs "changed-outside") club: 1. Set inside Customize. 2. #1 + `set-variable' used interactively. 3. #2 + any command called interactively that has as purpose to change the value. 4. #3 + any interactive command, used interactively or not. 5. #4 + any function or sexpr executed interactively (`M-:'). 6. #5 + any function or sexpr called by any function or sexpr in #5. 7. #6 + explicitly loading any library (interactively). 8. #7 + loading any library in your custom file (.emacs). 9. #8 + loading any library, even indirectly. You're trying to distinguish cases based on MECHANISMS used to set the variable. That's not the kind of distinction we are making. We are not talking about how it's done. The distinction here is who decides to set this particular variable. Does a certain Lisp program decide, or does the user decide. Yes. I argued that _none_ of the above mechanisms is an adequate indicator of "who decides to set this particular variable." We agree, I think, that _no_ mechanism is ultimately adequate to that task. The question of who is deciding a particular change can only truly be answered by the user. But we have no choice: _If_ we try to determine _by code_ who is doing the deciding, then we need some objective criterion (we don't want to ask the user, about each change that is made, "Did you intend that?"). IOW, we must look at how a change is made _if_ we wish to maintain an outside/inside distinction - we must examine the setting mechanisms. And the current scheme does indeed make the determination based on mechanism (clicking Set inside C. vs everything else). The question you posed does not require an answer. This is the two-part question I posed: "Is there is a good inside/outside boundary to choose? Which kinds of changes should we allow inside the "Set" club?" The placement (and the need) of this boundary has been the question from the beginning. It requires an answer _if_ people are arguing for maintaining an inside/outside distinction: How is the boundary to be defined? My answers to the two-part question are (1) "No, there is no good boundary" and (2) "All changes should be considered to 'set' options". I argued that none of the mechanisms I listed is adequate to the task: All user-option changes, no matter how they are made, should be admitted to the Customize club. The inside/outside distinction is not a useful one to maintain. If my list of "mechanisms" is not complete or is off the mark, if there is an adequate criterion to distinguish inside changes from outside changes (whether "mechanism" or not), let's hear it. I said in an earlier message, and you seemingly agreed: The idea behind limiting Customize admission to only interactive functions I think hints at the proper criterion, but it does not hit it square on. The idea of user Helen "setting" an option really comes down to this: user _intention_. That is not a criterion we can test by program, but it is the only reasonable criterion, IMO. I agree; I think that's exactly what it means to me. Users set variables by running programs. The difference is that in one case the intention to set variable X is embodied in the program code; in the other, the progranm could set any variable, but the user chooses to set X. You seem to agree in general, but you also seem to suggest that the particular program code could be examined to determine intention - if it offers the user a choice, then presumably the user is in charge; if it does not, then the _program is deciding_. Is that what you mean? If so, then I disagree. Even a program that offers no choice can be run or not, according to user choice. That particular mechanistic criterion (program offers a choice or not) is no better than interactive vs non-interactive. Again, user intention "is not a criterion we can test by program." I proposed that we make no inside/outside distinction, that we regard all changes to user options as "setting" them. What to do, then, about programs and libraries that set options? I pointed out that some are _designed_ to set options (and when a user runs them, the user is choosing to set those options), and some (multi-user libraries, in particular) should not set options (if they do so now, they must be corrected). I argued that the only exception to considering all option changes as "setting" the options is the startup sequence: This difference in library kind (purpose) can be reflected in the treatment by Customize. It is normal for .emacs and personal libraries loaded at startu
RE: Customize buttons that change user's customfileshouldaskforconfirmation
> I believe the logical structure Miles first suggested
> (essentially the first
> one above) with the enhancement above with a single "Get
> All"-button is the
> best. It gives the possibility to preview the values
> before setting them.
>
> Yes, it does that. However, it is also more cumbersome to use.
The problem with "S => C,F" compared to "S => F" is that you may have
saved a set of parameters that does something stupid (e.g. select
black on black text for the default font). Being able to load such
values and edit them before saving them is very useful.
Yes, that is the reason. In addition, "S => F" is clearer (because simpler).
I don't know if "S =>" imply that [1] we actually read the values from
the
custom-file (e.g. .emacs) or if [2] it just restores the value that was
initially read from that file, or [3] the last value that was written by
this emacs to that file.
What is the difference between [1] and [3]? I believe that custom-set* is
read from your .emacs ([1] and [3], IIUC). I think [2] would be confusing
behavior: The `saved' value that the user has in his mind should always
correspond to the value that will result if Emacs is restarted (now). That
is, it should correspond to whatever value .emacs reestablishes (unless that
is a `standard' value).
If it implies reading from the file, this could be used to load
values from a diffent custom-file (to see what they are) before
actually using them.
No way to do that has yet been proposed. S=>F means to get the values from
the custom-set* in the user's .emacs (custom file). There is currently no
way to designate a different library to use as the source of `saved'
settings.
Instead of providing such a feature, I'd suggest that users should just
`M-:' the custom-set* expression of the custom-file in question. IOW, I
don't think we should provide a Customize feature to get the custom-set*
stuff from an arbitrary file. Users who want to do that should be capable of
evaling the custom-set* expression.
If you simply _load_ (e.g. load-library...) a different custom-file (which
is not the same as Get All Saved) sometime after startup, then the values
would of course get set, in addition to the edit fields being filled. In my
proposal, those settings would show up as "Set", precisely so that you can
distinguish them from values established during startup (which show up as
`saved' ("unchanged").
> Perhaps we should ask the users which one they prefer.
I prefer "S => F" with a message in the echo area telling the
user to use "Set All" to apply the values.
Me too.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's customfileshouldaskforconfirmation
> I don't know if "S =>" imply that [1] we actually read
> the values from the
> custom-file (e.g. .emacs) or if [2] it just restores the
> value that was
> initially read from that file, or [3] the last value that
> was written by this emacs to that file.
>
> What is the difference between [1] and [3]?
If custom-file is updated by another emacs instance, [1] != [3].
Thanks. I didn't pay attention to the "this emacs".
Since we're dealing with a file (persistence), I would think that [1] would
be the best approach. (I don't know either what we do currently.)
> If it implies reading from the file, this could be used to load
> values from a diffent custom-file (to see what they are) before
> actually using them.
>
> No way to do that has yet been proposed. S=>F means to get
> the values from
> the custom-set* in the user's .emacs (custom file). There is
> currently no
> way to designate a different library to use as the source of `saved'
> settings.
M-: (setq custom-file "X")
M-x customize
do some editing
save (into X)
M-: (setq custom-file "Y")
get (from ?)
Question is "from X" or "from Y"?
Good point. I would think it should be Y.
In any case, we should tell the user just what will happen (with a
dynamically defined tooltip? "Get values from file `Y'") and echo what did
actually happen with a message ("Values read from file `Y'").
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user'scustomfileshouldaskforconfirmation
The key is to satisfy both novices and experts Provide a good default interface for novices and also a way for that novice to become an expert without too much trouble That is why Customize should not only do its job, but make it easy for a person to learn. I don't agree with some of the detailed proposals you've made - for example, I agree with Kim that your history-of-values display would be overkill and confusing. However, I do agree that Customize should do these things, in order of priority: 1. "Do its job", as you put it: - make it easy for anyone, including a non-Lisper, to customize options - provide an easy-to-use options browser 2. Facilitate learning more about Emacs - Lisp, in particular. #1 is far more important than #2. #2 should never interfere with #1. In particular, the UI should not be made more complex in order to promote #2. But Customize should not act as an obstacle to understanding what's under the hood - it should facilitate that learning, but not require it or impose it. Your analogy with menu items that show corresponding key sequences is a good one. Simple information bridges like that help users be more effective. As I mentioned long ago, I think that simple links in Customize to a) the current Lisp value of an option and b) the defining source code, as are available in `C-h v', would be unobtrusive and quite helpful. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user'scustomfileshouldaskforconfirmation
> If it implies reading from the file, this could > be used to load values from a diffent custom-file > (to see what they are) before actually using them. > > No way to do that has yet been proposed. S=>F means > to get the values from the custom-set* in the user's > .emacs (custom file). There is currently no way to > designate a different library to use as the source of > `saved' settings. M-: (setq custom-file "X") M-x customize do some editing save (into X) M-: (setq custom-file "Y") get (from ?) Question is "from X" or "from Y"? Good point. I would think it should be Y. Absolutely not. `(setq custom-file "Y")' means that you want Custom to _write_ to Y. If you want Y to be read you have to load Y... If you want Y to be your Custom file, write: (setq custom-file "Y") (load custom-file) in your .emacs, as the docstring of `custom-file' recommends. The question was about "getting" values from a custom file without loading that file. You are confirming, I guess, that there is no way to change custom-file for purposes of get-but-do-not-load. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user'scustomfileshouldaskforconfirmation
> If it implies reading from the file, this could > be used to load values from a diffent custom-file > (to see what they are) before actually using them. > > No way to do that has yet been proposed. S=>F means > to get the values from the custom-set* in the user's > .emacs (custom file). There is currently no way to > designate a different library to use as the source of > `saved' settings. M-: (setq custom-file "X") M-x customize do some editing save (into X) M-: (setq custom-file "Y") get (from ?) Question is "from X" or "from Y"? Good point. I would think it should be Y. Absolutely not. `(setq custom-file "Y")' means that you want Custom to _write_ to Y. If you want Y to be read you have to load Y... If you want Y to be your Custom file, write: (setq custom-file "Y") (load custom-file) in your .emacs, as the docstring of `custom-file' recommends. The question was about "getting" values from a custom file without loading that file. You are confirming, I guess, that there is no way to change custom-file for purposes of get-but-do-not-load. If instead of `M-: (setq custom-file "Y")' we set custom-file through Custom, then the up to date Custom Info is _immediately_ in Y, without having to save any further option. (Because saving `custom-file' itself took care of things.) So if somebody _really_ wants to change Custom file during an emacs session (instead of from .emacs) the way to do it is through Custom. Got it. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons thatchangeuser'scustomfileshouldaskforconfirmation
But here we are discussing what happens if you change custom-file in an already running Emacs session, after a custom-file has already been loaded. In that situation loading that _second_ Custom file (which presumably is an empty file to be written into by the current Emacs) does not make a lot of sense. The main type of situation in which one might actually want to change custom-file in a running Emacs is the following. I believe that Kim started off this change-custom-file thread, in the context of the question of S=>F. He mentioned that it might be useful to have S=>F instead of only S=>C,F, in order to let you retrieve values from a second custom file without loading that second file. I think the thread has diverged from Kim's point, which is OK, but I'm not sure that everyone is following it clearly. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Use faces to indicate states in Customize?
With an aim to reduce the "noise" in the Customize UI a bit, here is a proposal that might or might not be considered for 22.1. It should be trivial to implement, while waiting for any more substantial UI changes that we might make after 22.1. 1) We reduce the text displayed as the "state" of each option. 2) We use a slightly different face for each possible state, with the states that we want to stand out more (e.g. Set) having faces that stand out a little more. That is, the face of the text would be different for each option state, and the text would be simpler (shorter) than it is now. For example (each entry here is (1) proposed text, (2) state, (3) current text, (4) doc string text from `custom-magic-alist'): - 1) "Edited"; 2) `modified'; 3) "you have edited the value as text, but you have not set the option"; 4) "This item is modified, and has a valid form" - 1) "Saved" or possibly "Unchanged"; 2) `saved'; 3) "this option has been set and saved"; 4) "This item is marked for saving" - 1) "Standard"; 2) `standard'; 3) "this option is unchanged from its standard setting"; 4) "This item is unchanged from the standard setting" - 1) "Set Here"; 2) `set'; 3) "you have set this option, but not saved it for future sessions"; 4) "This item has been set but not saved" - 1) "Set Elsewhere"; 2) `changed'; 3) "this option has been changed outside the customize buffer"; 4) "The current value of this item has been changed temporarily" - 1) "Invalid"; 2) `invalid'; 3) "the value displayed for this option is invalid and cannot be set"; 4) "This item is modified, but has an invalid form" - 1) "Other"; 2) `rogue'; 3) "this option has not been changed with customize"; 4) "This item has no customization information" This would make scanning for changes (Set) easier, and would make the unchanged stuff (Unchanged, Standard) less prominent. The default face differences should be slight, so that this does not just make for _more_ noise. The faces used for each state should of course be customizable. The more lengthy description could be incorporated into tooltips. What do you think? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: M-Tab on w32 (and other window systems?)
I find that Esc and TAB keys are close enough to make typing Esc TAB a simple enough operation. ...I am used to Esc TAB, and don't find it hard to reach. ESC TAB is `complete-symbol'. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Use faces to indicate states in Customize?
(each entry here is (1) proposed text, (2) state, (3) current text, (4) doc string text from `custom-magic-alist'): The entries you give for (4) to not seem to correspond either to today's recent or yesterday's values of `custom-magic-alist'. No, they are older - sorry for any confusion in that regard. The exact text is not relevant to my point, however. My point was to continue to provide info such as that in (3) and (4), but to do so only upon request (e.g. via tooltip), in order to reduce the text displayed for each custom option. There are relatively few custom "states". A long description of each state need not be repeated each time the state is mentioned. My idea is to use 1) only a short name (label) at each state occurrence and 2) a "legend" that accurately describes what each such label stands for. The legend could be in a centralized location (e.g. buffer bottom) and could describe all of the states (once), or it could be available only upon demand and be split up, as a set of individual tooltips for the state names. I prefer the latter, but either is better than repeating a description at each occurrence, IMO. The other part of my idea is to use color to make the states easier to distinguish when scanning. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's custom fileshouldaskforconfirmation
The big problem is that if the user sets option X on a page and does
"F => C", and then (sometime later) sets option Y on the same
page, and then does "F => C,S", the effect is that the change
to X is also saved. This may be highly confusing to a user.
This is confusing now only because the button doesn't properly indicate that
the action is to Save All. As we discussed, renaming the button (All) and
asking for confirmation should take care of this. ("This will save all
options in the buffer that have been Set. Do you want to continue?").
One possible solution for that is to discourage, or even get rid of,
of the per-variable command button. If there is only the whole-buffer
Set and the whole-buffer Save, this confusion won't happen.
ISTR that I have seen apps where there is no difference between the
field value and the active value within the customization tool, but
all the changes require confirmation when you exit the customization
tool.
The concept of "exiting" does not make sense for a Custom buffer, but
there could be a buffer-wide Activate command, "Put this in effect",
which combines Set and Save.
That's just what the Save button does currently, IIUC.
If that were the only way to make values
take effect, it would be a lot simpler than the current Custom
facility.
In addition to Activate, there would be Cancel and Standard Values.
And perhaps What's Changed, which says what would change if you use
Activate right now.
What do people think of the idea?
I think that it would be a very bad idea to move away from being able to
manipulate (e.g. edit, set, reset, & save) individual options. A given
custom buffer will perhaps have many options in several different states.
There must be a way to save one or more options in the buffer but not
necessarily all. Otherwise, we will get more confusion and operator error.
We might want to let users select a set of individual options (e.g. using
checkboxes or by dragging a region) and then operate on the selection. That
would provide a shortcut to operating individually on each item in the set,
and could help make it clear which options were affected for a "global"
operation.
But to always use the entire Customize buffer as that selection would be
restrictive, IMO.
WRT the idea of checkboxes - I'm thinking of what we do in Dired to mark
(select) files for applying actions. You can use many different ways to mark
a file (regexp etc.). In my own Dired code, you can also:
- Use the mouse to drag a region, then use a mouse-3 menu item Mark (or
Unmark) to select (or deselect) all the files in the region. If no region is
active (no selection), then the mouse-3 menu items affect the single file
under the pointer.
- Use SHIFT and CONTROL with mouse-1 clicks to select blocks of files or
individual files to add to the selection set - just as you do in Windows
Explorer.
Extending this idea to Customize, a user would mark/select various options,
then use a global action (button or menu-bar menu item) that operates on all
of the selected options. If no options are selected, then the menu item
would apply to the option under the pointer.
The menu for this is the individual-option menu, which is currently accessed
by the State "button". This could remain as a pulldown menu (which is what
it really is now), or it could be moved to a contextual menu on mouse-3 (as
I have in Dired). In the latter case, mouse-3 would not be available for
selecting and killing, but users could still select a region by dragging.
I assume that this discussion applies to possible changes after the release,
not before.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's custom fileshouldaskforconfirmation
I said:
We might want to let users select a set of individual options
(e.g. using checkboxes or by dragging a region) and then
operate on the selection. That would provide a shortcut to
operating individually on each item in the set, and could help
make it clear which options were affected for a "global" operation.
...
Extending this idea to Customize, a user would mark/select
various options, then use a global action (button or menu-bar
menu item) that operates on all of the selected options. If no
options are selected, then the menu item would apply to the
option under the pointer.
The menu for this is the individual-option menu, which is
currently accessed by the State "button". This could remain as
a pulldown menu (which is what it really is now), or it could
be moved to a contextual menu on mouse-3 (as I have in Dired).
In the latter case, mouse-3 would not be available for
selecting and killing, but users could still select a region by
dragging.
I mispoke in the second paragraph quoted above. The global buttons (Save All
etc.) and the menu-bar menu should always apply globally (to everything in
the buffer), not to the currently selected options.
The current selection should be treated instead by a context-sensitive
menu - e.g., the mouse-3 menu. Another reason for moving the menu from the
State button to, for example, mouse-3 is this: The State-button menu is
fixed as local to a particular option; it cannot be used as a
context-sensitive menu that applies to the current selection (or the option
under the pointer, if there is no selection).
In sum:
- Global buttons and the menu-bar menu apply to all options in the buffer.
Their item names include the word "All".
- A context-sensitive menu (e.g. mouse-3) lets you mark and unmark options
and perform Save, Set etc. actions on the marked options. If no option is
marked, then the menu actions apply to the option under the mouse pointer
("current" option).
- You can mark or unmark all options in a region. The context-sensitive
menu items Mark and Unmark apply to all options in the region.
- If we have a context-sensitive menu (e.g. mouse-3), as described, we
should move all of the individual-option items from the State menu to the
context-sensitive menu.
We might want to use mouse-2 instead of mouse-3 to bring up the
context-sensitive menu. Mouse-3 is standard for such a menu in many
applications, but using it here means users would lose the normal mouse-3
functionality. Mouse-2 follows links and activates buttons in Customize, so
there should be no conflict with the menu: to use the c-s menu you just
position the pointer anywhere that is not on a button or a link.
However, if we did that, then we should not also have any pull-down menus
(e.g. State) that are activated by mouse-2, because it needs to be clear
whether the menu that appears applies to some fixed object (e.g. State) or
is the context-sensitive menu (which applies to the selection).
I personally think that mouse-3 would be a good choice for the c-s menu and
that the loss of mouse-3 editing functionality would not be missed in
Customize (I don't miss it in my version of Dired that has similar
functionality).
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's customfileshouldaskforconfirmation
> - A context-sensitive menu (e.g. mouse-3) I any proposal of this kind I think it is important to give the possibility to use only the keyboard. Some people do not want to use the mouse and some simply can not use it. That's standard practice: there should be keyboard access to the same functionality provided by the mouse - in particular, popup menus. I don't know if that's the case generally with Emacs (I think not), but it is standard in many apps these days. Some such mechanism is, I think, in fact required for accessibility standards that apply to disabled people - e.g. W3C WCAG (Web Content Accessibility Guidelines) Double-A recommendations. Why not let the menu-bar menu have entries for working with the "current option". The "current option" could be that where the point is. (I implemented this kind of functionality in my proposal long ago for a redressed Custom GUI.) That's possible, but I don't think it's desirable. That is not standard in any UI I'm familiar with. A context-sensitive menu is usually associated with a mouse button, because you are generally using the mouse to manipulate things associated with that context. This is the practice nearly everywhere in MS Windows, for instance. For example, you are doing things in a dialog box, and you use mouse-3 to open a menu for manipulating something in the dialog box that is under the mouse pointer. Users are very used to this behavior. It is true that Emacs has a notion of point (cursor) that is separate from the pointer location, so that such an operation as you describe can be unambiguous without the mouse. Dired, for instance, has a menu-bar menu (Immediate) that is largely for manipulating an individual file at point. I nevertheless think that in most contexts (e.g. Customize) the position of point is not a very useful (because not very obvious) indicator of the current focus of action. Also, if the context is to sometimes be a _set_ of options, then point is not a sufficient context indicator. It is better to make the focus of action obvious - e.g. using visible marks. Another possibility in this regard is, as Richard suggested, to list the options to which an action will apply (a la Dired asking if you want to delete these files). ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
dired Mark menu commands
Some minor suggestions regarding Dired's Mark menu: 1. The command `dired-mark-extension' (`*.'), defined in dired-x.el, is useful to mark all files with a certain extension. Most people have never heard of it, however. More than once, I've mentioned it in reply to questions on help-gnu-emacs, and have gotten replies like "I've used Emacs for years and never knew that existed." Why not add this command to the Mark menu? It could be called "Mark Extension...". 2. All of the "Mark"* menu items and commands except `dired-mark-extension' use the prefix arg to unmark (instead of to mark). `dired-mark-extension' uses the prefix arg as a (decimal) character code for the mark to use. So, to unmark all files with extension "el", you would do this: `C-u 32 *. el', because decimal 32 is the code for SPACE. Using a prefix arg this way is not very intuitive. I think it would make more sense for `dired-mark-extension' to use the prefix arg for unmarkp, as the other commands do. Those few dired-x functions that currently call `dired-mark-extension' with a marker-char argument could call a different function, which does what `dired-mark-extension' does today. IOW, the common, end-user command would use the prefix arg to unmark, and the more complex functionality could still be made available separately. Also, the more complex functionality might better use the interaction of `dired-unmark-all-files': _read_ the mark to use (as a character, not a number). 3. Why not add `dired-mark-symlinks' (`*@') to the Mark menu? It could be called "Mark Symlinks". 4. Why not add `dired-unmark-all-files' (`M-DEL') to the Mark menu? It could be called something like "Unmark Marked-With...". 5. Why not group the Unmark menu items together (Unmark, Unmark All, and perhaps Unmark Marked-With...)? Why not use a menu separator between the Mark, Unmark, and Flag groups of commands? Adding commands like these to menu-bar menus helps users become aware of them, as Robert C. pointed out recently. After users see that there is a command "Mark Extenstion..." and it is bound to `*.', they are likely to start using the keyboard shortcut. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's custom fileshouldaskforconfirmation
the whole-buffer buttons are _very_ seldom used. We could poll the users and see. If users generally use the single-item button and not the whole-buffer buttons, I would not mind simplifying things by eliminating the latter. For the poll - Like Luc, I use the single-item operation (on the State menu). I generally only set or save one option at a time. If we used a header line, as Kim suggested, then that would be as convenient (close by) as the State menu for operating on a single option. But some way of letting you know which options will be affected (e.g. popup list) should be implemented for any global button or menu, as we have discussed. As someone mentioned, if you want to operate on multiple options, you don't want to repeat the set or save operation for each option independently. So, if we _must_ choose between the two methods, the global button is more general. What is the reason that we must choose and not have both local and global actions? Is it to simplify the UI? Getting rid of the buttons would simplify the buffer; but getting rid of some of the State menu items would not appreciably simplify the UI, IMO. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's custom fileshouldaskforconfirmation
The reason the header line is nice is that it will remain on the screen even when you scroll the customize window. Yes. Of course, the same operations are also available in the menu-bar menu, which stays put like a header line. But of course, you cannot activate it with your mouse. We could make the header line mouse-sensitive, as in Info. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: dired Mark menu commands
Why not add this command to the Mark menu? It could be called "Mark Extension...". Because it is not part of Dired. Well, the exact command I described (prefix arg means unmark) is not the existing command in dired-x either - it doesn't exist yet. It could be _added_ to dired, if people find it useful. I know that I mark all files with the same extension a _lot_ more often than I use some of the other menu items. 3. Why not add `dired-mark-symlinks' (`*@') to the Mark menu? It could be called "Mark Symlinks". It is already there. Not in my Emacs -q, it isn't. What are you doing, to get it in the menu? The command is bound to the key sequence, but it is not in the Mark menu. In GNU Emacs 21.3.50.1 (i386-mingw-nt5.1.2600) of 2005-01-30 on NONIQPC Distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../. ./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl ude' 4. Why not add `dired-unmark-all-files' (`M-DEL') to the Mark menu? It could be called something like "Unmark Marked-With...". It is already there. Not in my Emacs -q, it isn't. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's customfileshouldaskforconfirmation
What is the reason that we must choose and not have both local and global actions? Is it to simplify the UI? I am considering the idea of eliminating one of them in order to simplify the interface. It seems to be far too complex now. Then I repeat: "Getting rid of the buttons would simplify the buffer; but getting rid of some of the State menu items would not appreciably simplify the UI." The advantage of the buttons is being able to act on multiple options at once. Acting on multiple options is perhaps for "experts" only, however. The disadvantage of the buttons is that their behavior can be complex and error-prone, as Luc described well. In sum, if you want to simplify the UI and make it easier and less error-prone for novices (in particular), then keep the single-option menus and get rid of the buttons. If you do get rid of the buttons, will you also get rid of the equivalent menu-bar menu items? If not, then no functionality will be lost. And all discussions of the button problems (complexity, expert-only? etc.) can be ported to the menu-bar menu. ;-) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Customize buttons that change user's custom fileshouldaskforconfirmation
Maybe the "Customize" menu could have a simple check-box option for "Show per-option action buttons". The inquisitive emacs user will surely find it :-) I agree that if a user enabled this, the global buttons should not be shown. This is a compromise that gives both approaches what they want. We should, however, strive to adopt such a compromise only if there is a consensus that there is (separate) value in having _each_ approach - not simply because we can't seem to reach consensus on _which_ approach is best. I doubt that we currently agree that both approaches are good (simple, safe, etc.), and that which to use should just be a user choice (option). From the current state of the discussion, it sounds more like each "side" thinks that his side is the "simpler" and "safer" approach. I agree with everyone else that no action should be taken now. In fact, the remainder of the customize-design discussion should be postponed until after 22.1 is released. There is a lot that we could put on the table for discussion regarding customize, and some of the issues are best discussed in combination. I think we all have the same general goals, and our differences probably reflect (mainly) different usage patterns or mutual misunderstandings. That is, I expect that we can in fact reach consensus on what is the best approach, given sufficient time and discussion. Customize is complex, the present UI provides lots of possibilities for a user, and the possibilities of changing customize to improve it are innumerable. So, it's no wonder that we haven't yet reached consensus - we haven't really explored the customize design space much. And, as I mentioned once before, it is essential to get input from Per, who understands the original design well - both the intent and the howto. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Info-search-isearch
> Currently only regexp isearch invoked with M-C-s can use `Info-search' > and search through multiple Info nodes. But it would be better if > normal C-s isearch searched through multiple nodes as well. This would be actually great, it would match the behavior of standalone info (which, IMO, is much better). Is there any reason not to check this code in? I like being able to confine an isearch to the current node. Currently, I can use `s' for global search and `C-s' (or `C-M-s') for local (node) search. So, to me, it would be desirable to have some indication that the end of the current node was reached without finding another occurrence of the string - e.g. "Failing isearch in node Foo: bar". Except for being able to overwrap isearch in the node (no great loss), this would give the advantages of both approaches (local and global search). Without such a local-failure indication, you would have to (perhaps unwittingly) continue the search to another node, and then use `l' to get back where you were. IOW, why not have two levels of isearch "failure": 1) no more in the current node, 2) no more in the current Info "manual"? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: follow-link in grep buffer
I realise that applications like web browsers use mouse-1 to follow links, so it is a good idea for Emacs to provide some consistency and it works well with Info pages. However, I am not sure if it is always appropriate as Emacs users understand that mouse-1 just generally moves the cursor, while mouse-2 might jump to another buffer. The grep buffer is an example. If I try to place the cursor anywhere on a line before the end of a match, the associated file pops up in another buffer. However I might just want to select that window to resize it. I could select the window by clicking on the modeline but if I click on the wrong part I get a different buffer. All this functionality must be daunting for the new user, so I suggest the following: 1) Mouse-1 is not used to follow links in the grep or compilation buffers. 2) If it has to be used for this purpose, then it only works where the match occurs (this must be easy to implement as it already has a different face) and the match is also underlined so that it looks like a link. Y'know, I knew this would come up sooner or later. I believe that the idea was to have the mouse-1 follow-links (and activate buttons) behavior be a user option. (I'm not sure what I prefer in this regard, as a user.) It's good for Emacs to act like other apps in this regard, as long as that doesn't impact functionality or cause other pbs. But you are absolutely correct that mouse-1 following links (and activating action buttons) will make it difficult to just select a buffer with the mouse, whenever that buffer is link-dense (or button-dense). One possibility that occurs to me now is to have a mouse-1 click in a window other than the selected-window act as mouse-1 does now: just set point. That is, the first mouse-1 click just sets point and selects the window; only thereafter would mouse-1 follow links. That is similar to the behavior I see in Windows, where clicking mouse-1 on a (WM) window that doesn't have the focus just shifts the focus: If you click a button (for example) in a window that doesn't have the focus, the window is selected, but the button is not activated (you must click it again, after the window has the focus, for it to take effect). This would not completely solve the problem you raise: You could not use mouse-1 to move point to a different part of the same, focused window. But the time-delay approach that was proposed a few months ago (by Kim?) would presumably address that pb. I think the idea there is that if you want to set point with mouse-1, then you just hold mouse-1 pressed longer than some (user-settable?) time limit, before releasing it. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: follow-link in grep buffer
I believe that the idea was to have the mouse-1 follow-links (and activate buttons) behavior be a user option. You mean `mouse-1-click-follows-link'? It _is_ a user option. I personally have it set to nil. But the default value uses the new behavior. Yes, that's what I meant. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: follow-link in grep buffer
This "double click to launch" used to be a pretty common idiom at one time, though browsers have watered it down in some contexts. FWIW - I'm not an expert on this, but I believe that in Windows the single- vs double-click-follows/activates behavior is a user option. I would guess (but don't know) that most Windows users now use the single-click behavior. I don't know if following links and other actions (e.g. open) follow the same principle (option value). Perhaps someone else can speak to this more authoritatively. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: follow-link in grep buffer
> Based on your example, I'd say another option might be: > - if the click is used to give focus, then don't follow the link. Given that if you press the button longer it also doesn't follow the link, the tooltip tells you that it does, even without focus, and doesn't mention that mouse-2 does the job too (it's masked by mouse-1), I think it would only create further confusion. I made the same suggestion as Stefan, and I don't think it would lead to further confusion. As I mentioned, that is pretty much the behavior that Windows users experience every day (the first click establishes focus). And I can testify that it has saved my derriere more than once, when I accidentally clicked something (e.g. button) in a window that didn't have the focus. Of course, mouse-follows-focus would no doubt overrule this behavior, so it wouldn't help in that case. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Info-search-isearch
> I like being able to confine an isearch to the current > node. Currently, I can use `s' for global search and `C-s' > (or `C-M-s') for local (node) search. > > So, to me, it would be desirable to have some indication > that the end of the current node was reached without > finding another occurrence of the string - > e.g. "Failing isearch in node Foo: bar". Except for being > able to overwrap isearch in the node (no great loss), this > would give the advantages of both > approaches (local and global search). Without such a local-failure > indication, you would have to (perhaps unwittingly) > continue the search to > another node, and then use `l' to get back where you were. > > IOW, why not have two levels of isearch "failure": 1) no > more in the current node, 2) no more in the current Info "manual"? The behavior of what you propose is different from either the current C-s behavior in an emacs info buffer or in standalone info. Correct. The message I was replying to was just asking to make the C-s behavior the same in an info buffer and standalone info, and allow to the user to choose one or the other via a customizable variable. Correct. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: follow-link in grep buffer
I just installed a change so that a mouse-1 click only follows a link if the window is already selected. The tooltip will now say to use mouse-2 to follow a link in a non-selected window and to use mouse-1 in a selected window. I don't think it's a good idea to put the info about mouse-2 in the tooltip here; I would leave it out, to simplify the explanation. Using mouse-2 to select a link in a non-selected window is not necessary, anyway - users can just click mouse-1 to select the window first. Keeping this extra info in the tooltip will only confuse novices (and others). Users quickly get used to the Windows behavior without any explanation that their first click in a non-selected window does not follow a clicked link. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: follow-link in grep buffer
If we have specific problems in certain modes, let's fix those modes (e.g. in grep that you have to click on the file:line part of a line to jump). Just to add one more permutation to our list of contortions ;-) - I would like to see modes like Dired and Grep and Buffer List make the entire line, which is in fact the entire entry, clickable and mouse-highlightable, as I think I mentioned before. The reasons are: - It makes it much easier to "scan" with the mouse, seeing what lines up with what. This is like using a ruler to scan entries in a large table or phone book. - It makes it easier to click an entry - just click anywhere on the line. I've used this behavior for decades in my own Emacs, and I find it useful. Anyway, I mention this now because of Kim's suggestion, above, which moves a bit in the opposite direction. IOW, I don't want to see the hot zone _reduced_ or limited in buffers like grep, I instead want to see the entire entry (which is the entire line) become the hot zone. Assuming that I were able to convince others about this (;-)), what would that mean wrt mouse bindings? In buffers like these (Dired, grep, Buffer List), the main mouse action is not to set point, but setting point is still an important action (e.g. in Dired). I don't have a brilliant suggestion, but I wonder if it wouldn't be reasonable, in such buffers, to reverse one approach mentioned already: - mouse-1 follows the link (which, to me, should be the whole line) - double-click mouse-1 sets point I don't think this would be too bad. In such buffers we do need to set point sometimes, and we sometimes want to create a region, but we don't usually need to double-click to select a word. We could always drag to create a region (I do that in my Dired buffers). Of course, there is the argument that this won't be intuitive to users, but I think we'll be up against such an argument no matter what we choose. After all, being able to both a) follow a link and b) set point is not that common. Another argument against this might be that a too-slow double-click would mess up the user, mistakenly following the link. I think users can deal with this. In Windows, a simple GUI dialog lets you set the double-click interval (speed), and this setting applies to all applications. (BTW, Do we pick up this Windows setting in Emacs, to use as our double-click delay?) Kim's time delay is also a good approach to the mouse-1/mouse-2 problem, and it is also standard behavior in many apps (the argument that users will never discover it is overstated, IMO). There would be no problem in adopting both approaches simultaneously (to set point: either double-click or hold mouse-1 pressed a little longer). That might sound paradoxical, but it's perhaps the easiest behavior to explain (and discover): to follow a link, use a single short click; anything else sets point. Whatever we choose, we have these requirements: - It should be at least as easy to follow a link as to set point. In buffers that are primarily "view" buffers, as opposed to "edit", it is tolerable if setting point is not quite as easy as following a link. - It shouldn't be too hard to discover or perform either action. - There should not be any disastrous consequences of making a mistake. WRT having the first mouse-click set the focus (a suggestion Stefan and I each made): Yes, that would be done only if the window didn't already have the focus. No, it wouldn't apply if you choose to have the focus automatically follow the mouse. I think that first-click-focuses suggestion makes sense, regardless of what other conventions we adopt - that is, it should be adopted even if we also choose to use double-click (or whatever) to set point. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: follow-link in grep buffer
> Just to add one more permutation to our list of contortions ;-) - > > I would like to see modes like Dired and Grep and Buffer List make > the entire line, which is in fact the entire entry, clickable and > mouse-highlightable, as I think I mentioned before. For one thing, this is visually distracting. Our highlight color is pretty brutal. For buttons, this is fine, for active lines, this is too much. For that reason, I use underline for mouse-face highlighting in such buffers. > The reasons are: > > - It makes it much easier to "scan" with the mouse, seeing what > lines up with what. This is like using a ruler to scan entries in a > large table or phone book. The mouse highlighting we have makes the line pretty unreadable. That is ok for buttons: you usually are aware what they are for before you move to their confined area. But it is too heavy for whole lines. Agreed - see above. The proper highlighting to use is our choice (and then it's the user's choice). I agree that mouseover highlighting of entire-line entries should be subtle, not overwhelming. I use underline. Ideally, I would love to be able to use underlining _without removing any font-lock highlighting_; that is, simply underline the text when you point to it, without changing any of its other properties. That's the behavior in most Web browsers. I'm not sure if that's easy to do, or even feasible, in Emacs, however. > - It makes it easier to click an entry - just click anywhere on the > line. Good grief. In a dired buffer, I most often need to to some directory editing operation: renaming, moving, viewing with a special application. If there is no place in the whole buffer where a simple mouse-1 will be able to place point, this is a terrible nuisance. I am not sure I'd want to have even just the file name mouse-1-buttonized, let alone the whole line. 1. Currently I do not have mouse-1 follow links, so I have no pb in this regard. I agree that if one cannot easily set point, that is a major problem. 2. I specifically said that in such buffers it is very important to be able to easily set point with the mouse. I said, about such buffers: "the main mouse action is not to set point, but setting point is still an important action (e.g. in Dired)." 3. Describing behavior like this doesn't communicate it well. You really need to try it (or have a good imagination). Also, it's hard to think outside of one's habitual box - that is, our habits can often convince us that any change is undesirable. > Anyway, I mention this now because of Kim's suggestion, above, which > moves a bit in the opposite direction. IOW, I don't want to see the > hot zone _reduced_ or limited in buffers like grep, I instead want > to see the entire entry (which is the entire line) become the hot > zone. That pretty much destroys the ability for simple editing without using smartass tricks like long clicks or drags. See above. I use mouse-1 to set point currently, as usual (no double-clicking). If we changed mouse-1 to follow links, then I would double-click to set point - or I would forego mouse-1-follows-links. "Simple editing" would not be affected detrimentally by what I or Kim described, and such buffers are not for non-simple editing. This is not an interface I want to have to explain to anybody. We want an interface that does _not_ need explaining - especially wrt basic mouse operations such as following links and setting point. I think this behavior would be fairly intuitive and easy to discover - no special explanation would be needed. Keep in mind, too, that Emacs novices already need to learn much trickier mouse manipulations (double-click and triple-click to select, mouse-1 plus mouse-3 to select, etc.). How did you learn all that? You probably read it in Info. Well, what I'm talking about is a lot less to explain than all that. And, more importantly, it probably would be discovered and not need explaining at all (unlike mouse-1 plus mouse-3 to select etc.). > Assuming that I were able to convince others about this (;-)), what > would that mean wrt mouse bindings? In buffers like these (Dired, > grep, Buffer List), the main mouse action is not to set point, but > setting point is still an important action (e.g. in Dired). I don't > have a brilliant suggestion, but I wonder if it wouldn't be > reasonable, in such buffers, to reverse one approach mentioned > already: > > - mouse-1 follows the link (which, to me, should be the whole line) > > - double-click mouse-1 sets point Terrible. If I tell that to any new Emacs users, they'll shake their heads and leave Emacs alone. And when you tell them about mouse-1 plus mouse-3 and all the rest? I don't mind if you configure your own editor in such a backward way that makes the simple operations difficult,
RE: follow-link in grep buffer
> Terrible. If I tell that to any new Emacs users, they'll > shake their heads and leave Emacs alone. > And when you tell them about mouse-1 plus mouse-3 and all the rest? The difference is that you don't need to tell Emacs novices about mouse-1+mouse-3 (which I never ever use in Emacs, BTW, I always use drag-mouse-1 instead). OTOH you do have to explain to them why they can't just "click to place point" and how to work around it. Well, I don't want to belabor this point, but mouse-1+mouse-3 behavior does need introducing, _if_ someone is to use it - people are not likely to _discover_ that behavior. Double-click behavior is something that many people will discover without explanation, IMO. Others may disagree... BTW, I'm a bit surprised that you always drag to select. Do you also not use two mouse-3 clicks to delete the region? That's another handy operation (though not basic or essential) that requires some introduction. Unlike mouse-1+mouse-3, people _are_ likely to discover that on their own, but it might take them a while to understand just what they've done. Using the mouse to follow a link and set point are basic operations that should not require any how-to explanation. Today, we do need to "tell" novices about mouse-2 and links. Tomorrow, we may unfortunately need to "tell" them about other ways to use the mouse to do simple things. We should try to come up with a scheme that leaves the three most basic mouse operations - setting point, defining the region, and following links - without need of an explanation. It doesn't sound like we're quite there yet. Your point is valid, of course, that novices might not need mouse-1+mouse-3. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: follow-link in grep buffer
> I use mouse-1 to set point currently, as usual (no > double-clicking). If we changed mouse-1 to follow links, then I > would double-click to set point - or I would forego > mouse-1-follows-links. "Simple editing" would not be affected > detrimentally by what I or Kim described, and such buffers are not > for non-simple editing. Look, you are arguing for an interface you are not even using yourself. I argued for full-line mouseover highlighting in buffers like grep. I've been using it for decades. Try it; you'll like it. I also threw out, as a _separate_ idea, the possibility that if we have mouse-1 follow links, then double-click mouse-1 might set point (instead of mouse-1 setting point and double-click following links). I provided a little rationale for such an approach, but I also explained that I was _not_ going to the barricades for that idea. If you find that idea crazy, I won't fight for it. I have not used mouse-1 to follow links in Emacs. mea culpa. Whenever I explain why a particular default is horrible, you say "Oh, I have configured something different myself currently". This leads nowhere. Bad generalization. A better generalization is "Whenever David discusses something, he screams like Howard Dean in Iowa." But neither generalization is very good. > This is not an interface I want to have to explain to anybody. > > We want an interface that does _not_ need explaining - especially > wrt basic mouse operations such as following links and setting > point. I think this behavior would be fairly intuitive and easy to > discover - no special explanation would be needed. I disagree. > Personally, I find the full-line highlighting so useful that if > forced to choose, I'll probably choose not to have mouse-1 follow > links in such buffers. _I_ might not mind double-clicking to set > point in such buffers, but if you barf at the thought, well, we > might have different taste. I seem to be a complete failure at communicating my opinion. No, on that score you do well. Taste is not a question here. One of the great things of Emacs is that it can be configured to accommodate almost any taste and need. We are talking about a default setting here: and that does not need to be tasteful, but obvious and generally useful and consistent. "we might have different taste" in this matter: We might have different opinions of what the default setting should be. Sorry if that wasn't clear. The personal choice I was referring to was this: I will keep full-line mouseover and forego mouse-1-follows-links, in my own Emacs. The former is that important to me. I would _like_ standard Emacs to follow my taste in this, but I don't expect to be able to convince others on this. Not this time around, anyway ;-). That personal choice is separate (different) from the question of double-click mouse-1 to set point vs to follow links. The latter is a discussion about what the default Emacs behavior should be. We might have different taste in that choice. I say "might" because I am not arguing forceably for one or the other; I don't even know what I would prefer in that regard. I just threw out an additional possibility for consideration. As I said in my reply to Stefan, "It doesn't sound like we're quite there yet." I was just trying to contribute to finding a solution. FWIW, my reason for bringing up the full-line mouseover in this discussion was Kim's remark that we might consider _reducing_ the size of the mouseover fields in grep. He made his suggestion (of a possibility) because of the perceived problem with setting point in such buffers if mouse-1 follows links. There remains a problem with setting point vs following links, IMO. Reducing the hot zones won't solve the problem (though it would restrict it), and such a hot-zone reduction works against what I think we should be doing wrt mouseover in such buffers. So 1) I spoke my mind wrt full-line mouseover zones and 2) I threw out yet another set-point-vs-follow-link possibility, for discussion. And "I find it nice that if I reconfigure the highlighting face that as a side effect I get in dired an orientation line" has nothing to do whatsoever with consistency. We don't want the behavior in dired to be surprisingly different from the rest by default, and we don't want to have some moderately convenient choice for dired (and I disagree with your assessment even just in dired) to make all the rest less logical and convenient. I guess you are saying that mouse-face highlighting should always be the same, for consistency. Consistency is a valid argument, in general. I agree that consistency is important, but everything is relative. This particular inconsistency is not a biggee to me (mouseover highlighting is always clear to users, regardless of the color etc.), but "we might have different taste" in weighi
RE: follow-link in grep buffer
> Bad generalization. A better generalization is "Whenever David > discusses something, he screams like Howard Dean in Iowa." But > neither generalization is very good. Whatever. Enough people have pointed out by now that they see little merit or sense or consistency or logic in my proposals. So I'll just stop screaming and let others decide. Chalk that one up to my bad sense of humor - I apologize. None of us need ad hominem arguments; I was trying to say that, sarcastically, by making such an argument myself. FWIW, I don't find your double-click-to-follow+single-click-to-set-pt suggestion worse than my opposite idea. In fact, your reference to the coding guideline about click-1 and click-2 convinced me that my suggestion was not a good one. Thanks for that reminder. I doubt too that people in general see "little sense" in your proposals in general or in this proposal, in particular. Quite the contrary. I personally think it's worth kicking this particular design problem around a little more, to see if the discussion doesn't come up with something elegant. There have been several proposals so far that I find acceptable, but I don't think we've yet reached that "Eureka!" moment that brings a really contented consensus. It's not as if this problem is critical or urgent. We can do something not-too-unreasonable for the current release and think about it some more for later. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Key binding M-g should really be goto-line autolearn=noversion=3.0.2 autolearn=no version=3.0.2
Example: How would students/designers use Emacs for PHP coding, where the remote site displays error messages and line numbers in a web page? Not to distract you all from the burning issue of `M-g', but how about a poor-man's compile buffer? If the target line number is already displayed in Emacs somewhere, why bother to type it in to `goto-line'? It wouldn't help with a Web page display, of course (unless the page were viewed in Emacs), but it sounds from your use case as if it might be generally useful to have a command that picks up the line-number from the text at point (whenever that text can be parsed as a numeral) and does `goto-line' in buffer `(other-buffer (current-buffer) t)'. And it might be useful to have an equivalent mouse command: click a displayed numeral to go to that line in the other buffer. To be able to specify a different target buffer, you could use a prefix arg, but you should not have to type anything (even RET) for must uses of the command - the default target buffer should be what you want. IOW, no default buffer-name with a prompt; just go to other-buffer. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Key binding M-g should really be goto-line autolearn=noversion=3.0.2 autolearn=no version=3.0.2
> it might be generally useful to have a command that picks up the > line-number from the text at point (whenever that text can be > parsed as a numeral) and does `goto-line' in buffer > `(other-buffer (current-buffer) t)'. We already have that, it's compilation-minor-mode. Looking at the code for compilation-minor-mode (as I'm inexperienced with it), I see no connection with what I suggested. That mode appears to work only in buffers that can be parsed to work with next-error etc. What I suggested was a simple command to pick up a numeral from any buffer, regardless of what the numeral might mean in that buffer. It would be rudimentary, but would do at least what people are doing with `goto-line', without requiring them to key in the line number. A minor suggestion - that's all. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Key binding M-g should really be goto-line autolearn=noversion=3.0.2 autolearn=no version=3.0.2
> What I suggested was a simple command to pick up a numeral > from any buffer, > regardless of what the numeral might mean in that buffer. It would be > rudimentary, but would do at least what people are doing with > `goto-line', > without requiring them to key in the line number. Is this what you have in mind? (defun goto-line-at-point (&optional buffer) "Go to the line whose number is given at point, counting like \ \\[goto-line]. With a prefix arg, prompt for a BUFFER and select it before moving." (interactive (list (if current-prefix-arg (read-buffer "Goto buffer: " (other-buffer (current-buffer) t) t (when buffer (pop-to-buffer buffer)) (goto-line (number-at-point))) I was thinking more like the following. You don't want to have to input the buffer each time (even hitting RET to get the default). And it's unlikely that you would want to go to a line in the same buffer in which the line number appears. (defun goto-line-at-point (buffer) "In another buffer, go to the line whose number is at point. With prefix argument, you are prompted for the buffer. Without it, `other-buffer' is used." (interactive (list (if current-prefix-arg (read-buffer "Buffer: " (other-buffer (current-buffer) t) t) (other-buffer (current-buffer) t (let ((lineno (or (number-at-point) (error "No number near cursor" (unless (wholenump lineno) (setq lineno (abs (truncate lineno (message "Line %s in buffer `%s'" lineno buffer) (pop-to-buffer buffer) (goto-line lineno))) If so, maybe a mouse- version would be useful, too. Yes, that's what I was suggesting. I don't have a need for such commands, but it sounded like they might be useful for the use case cited. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Key binding M-g should really be goto-lineautolearn=noversion=3.0.2 autolearn=no version=3.0.2
> How about making goto-line suggest the number at point > as its default argument? That seems very convenient! I haven't yet received RMS's email, but yes, why not? I think it may also be convenient if, point is not on a number, use the first number on the current line as a default. This is because I think it's common to have point sitting at the beginning of an error line, and this would save users the effort of manually positioning point over the actual line number (the heuristic could fail in some cases if for instance a filename contained digits, but I think it would often be right). BTW, also maybe the prompt in the "use last selected buffer" case should mention the buffer name. FYI - I don't suggest that `goto-line' itself should be changed this way, but the code I sent for `goto-line-at-point' (which picks up a number in a buffer to use as goto-line line number in another buffer), in my version, uses `number-nearest-point' instead of `number-at-point'. That does what you suggest wrt a number at line start. `number-nearest-point' is defined here: http://www.emacswiki.org/elisp/thingatpt-plus.el. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Key binding M-g should really be goto-lineautolearn=noversion=3.0.2 autolearn=no version=3.0.2
> FYI - I don't suggest that `goto-line' itself should be > changed this way, but the code I sent for `goto-line-at-point' I think goto-line should do it. What is "it"? You cut off the rest of my sentence where I said what I meant by "changed this way": use `number-nearest-point'. I suspect that your "it" is not my "this way", but I'm not sure what you mean. RMS has already said that he is not interested in such nearest-point stuff in Emacs. That's why I changed it to `number-at-point' in the code I sent, and that's why I said that I don't propose it for `goto-line' itelf. I mentioned it only "FYI", for the original poster, in particular. Your suggestion to pick up the line number at bol might be acceptable to RMS, however. I think that the main pb he had with the "nearest" stuff was that its scope was not sufficiently constrained. That is not a pb with bol. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: isearch-forward and Info-search
Would you like it if isearch failed before proceeding to the next Info node? I would. I suggested this long ago. It should first wrap, as Richard suggested. After the entire Info node has been searched, it should fail. A subsequent invocation should continue through the manual. IOW, isearch the node completely first (wrapping), then inform the user that there are no more occurrences in the node, then continue on to other nodes. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: isearch-forward and Info-search
I also think it would be too annoying to fail before leaving every Info node. It would be better to fail only in the first Info node where isearch was started. Good point - I agree. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: isearch-forward and Info-search
> Would you like it if isearch failed before proceeding to the > next Info node? > > I would. I suggested this long ago. It should first wrap, as Richard > suggested. After the entire Info node has been searched, it should > fail. A subsequent invocation should continue through the manual. > IOW, isearch the node completely first (wrapping), then inform the > user that there are no more occurrences in the node, then continue > on to other nodes. IMO, this behavior is too confusing. I agree, and I don't know why I suggested here to first wrap. In fact, what you describe was what I suggested originally: > But it would be better if > normal C-s isearch searched through multiple nodes as well. I like being able to confine an isearch to the current node. Currently, I can use `s' for global search and `C-s' (or `C-M-s') for local (node) search. So, to me, it would be desirable to have some indication that the end of the current node was reached without finding another occurrence of the string - e.g. "Failing isearch in node Foo: bar". Except for being able to overwrap isearch in the node (no great loss), this would give the advantages of both approaches (local and global search) IOW, why not have two levels of isearch "failure": 1) no more in the current node, 2) no more in the current Info "manual"? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
suggestions on toolbar icons
Some minor suggestions on toolbar icons (in Windows version, at
least). No need for a lot of discussion. If any of this makes
sense, good; if not, forget it.
ALL BUFFERS
---
- Magnifying glass for search: This symbol is often used for
Zoom, and it should be reserved for Zoom.
Suggestion: Use binoculars instead. (People don't search with
magnifying glasses, anyway.)
- Manuscript "X" for quit/exit: This symbol is often used for
Delete. It's not too bad for quitting (killing) a buffer, but
extending this to stand for "quit" generally (e.g. Info) is
not good.
Suggestion (my preference): Use the "exit" international
symbol, which is an arrow leaving a box by its open end:
++
|
< |
|
++
Reserve the manuscript X for a real delete operation that
cannot be assimilated with quitting. Whenever "delete" can be
considered to mean quit, use the exit symbol.
Alternative suggestion (but I prefer the one above): Use a
non-manuscript X for quit (perhaps like the one Windows uses
to close a frame, in the upper-right corner). It is only the
_manuscript_ X that means delete and so can be confusing.
- Tooltip for quit/exit:
Suggestion: Use "Quit buffer", or "Delete buffer" instead of
"Discard current buffer". I prefer "Quit buffer".
INFO BUFFER
---
- Right arrow targeting yellow disk (go to named node):
Suggestion: Arrow should point to the word "Node" or "Xxxx",
not to a nameless yellow disk.
- Index:
Suggestion: Add the letter "i" at the top of the icon
(lowercase i, as in the information symbol, but without any
enclosing circle). Split the "text" of each line, to show that
these are entries in a list (index):
_ ____
_ _ is better than ___
_ ____
- Arrows Previous, Next, Up, History Back, and History Forward:
The structural-move icons (Previous, Next, Up) look too much
like the chronological-move icons of Web browsers. I don't
have a slam-dunk suggestion here, but we should come up with
something better: browser users are used to these fat arrows
for chronological moves. (It's best to avoid them altogether.)
Suggestion (my preference): U-turn arrows for chronological
moves (right-then-left for back, left-then-right for forward);
small arrows with ellipsis (indicating continuation) for
structural moves: ...<-- and -->...
By "U-turn" arrows, I don't mean the current curly arrows, but
arrows that make a full sideways turn, like a U on its side.
Alternative suggestion (but I prefer the one above): U-turn
arrows for chronological moves; thin arrows for structural
moves. (The current curly arrows would not be good for
structural moves, because their shape suggests moving up and
over.)
Second alternative: If people don't like U-turn arrows, then
use the fat arrows for chronological moves, a la web browsers.
- Tooltip for Up arrow: Should say "Go to parent node", not "Go
up in the Info tree".
- Home (Info-top-node): Icon is good. However...
It takes you to the top node of the current file. Once there,
the icon remains active, although it then does nothing. Either
it should then be deactivated, or (better, IMO) `Info-top-node'
should take you to (dir) if you are already at the top of a
manual. We already have the notion of "Home" being relative
(different manuals have different homes), so letting it have
two levels this way would not be disruptive - in a sense there
_are_ two levels of "home" (or "top").
EDITING BUFFER
--
- Folder (for "file): This is _not_ good. A folder icon is used
ubiquitously for, well, a folder - that is, a directory.
Suggestion: The new-file and existing-file icons should be
very similar. Use the current new-file icon for both, but, in
the case of new-file, make it slightly smaller and have tiny
"sparkle" lines emanating from it ("[ ]" here represents a
slightly smaller version of the current new-file icon):
` | '
- [ ] -
' | `
Such sparkle lines (I don't know the real term) are often used
to indicate action, change of state, newness, or creation.
Alternative suggestion (perhaps better): Put just a tiny
sparkle star in one corner of the new-file icon. Example:
http://did.mat.uni-bayreuth.de/geonext/ru/start.html?CONTENT=help&head=Dokum
entation
- Directory (Dired):
Suggestion: Use a regular folder icon. Duh?
- Tooltip for Directory:
Suggestion: Mention "Dired" - "Operate on files in directory
(Dired)".
- Help:
Suggestion (my preference): Use a large, lowercase "i" in a
circle, the international symbol for information.
Alternative suggestion (but I prefer the one above): Use a
question mark (?) in a circle. A question mark is closer to
the meaning of Help, but Emacs Help is more than h
RE: suggestions on toolbar icons
I won't belabor this, but I do have a few responses. Your reply is, in essence, "GNMMME" (shades of Allen Ginsberg w/ "Oo"). If GNOME's choices are not always the best, we will nevertheless live with it. > - Folder (for "file): This is _not_ good. A folder icon is used >ubiquitously for, well, a folder - that is, a directory. You are talking Microsoft products here I guess. This is the Gnome stock open icon, I see no advantage to adopt a different set of guidelines different from Gnome where the folder icon is not at all is ubiquitously used for directory. Check out any Gnome application. > - Directory (Dired): >Suggestion: Use a regular folder icon. Duh? GTK_STOCK_DIRECTORY _is_ a standard folder icon. This _agrees_ with my suggestion (not at all Microsoftesque) that a standard folder icon should be used for Dired. If you think advocating that a folder icon be used to represent a folder editor implies advocating adopting Microsoft conventions, then I would suggest that you are overly zealous in your struggle. Oo. Similarly, GTK_STOCK_FILE is a standard file icon. This _agrees_ with my suggestion to keep this icon. The question then is, what about new-file vs existing-file? I suggested using something similar for both of these. GTK_STOCK_NEW is in fact _identical_ to GTK_STOCK_FILE, showing that GNOME and I think alike on this one. Emacs, however, currently uses the _directory_ icon, GTK_STOCK_DIRECTORY for opening an existing file - it happens that this icon is identical to GTK_STOCK_OPEN. Using a folder to represent opening a _file_ flies in the face of every UI I've ever seen. Are you sure that GTK_STOCK_OPEN is intended for files, not for directories? Does using it for opening a file make sense to you? Finally, if you are going to use GNOME as a litmus test, then why not be consistent and use GTK_STOCK_GOTO_TOP instead of GTK_STOCK_HOME for Info's Top? Likewise, why not use GTK_STOCK_GO_BACK for Back (which is, presumably, chronological) - as in Web browsers? Why use the GNOME undo/redo icon (GTK_STOCK_REDO) for Back and Forward? I suspect that we are already departing dangerously from the GNOME Oom. It's a slippery slope... The Gnome stock quit could be used in info to quit, it is an arrow pointing to an open door. Yes, that's better, although the icon is ambiguous (entering or exiting?) and is not very clear (the door is hard to distinguish). I prefer the international exit sign - the one you look for when there's a fire. > - Tooltip for quit/exit: >Suggestion: Use "Quit buffer", or "Delete buffer" instead of >"Discard current buffer". I prefer "Quit buffer". But "Quit Buffer" is not clear, it could mean the same as "Quit Info" i.e. leaving the buffer intact, just switching to another buffer. "Quit" is clearer (and more common) than "discard". At this level, the distinction between leaving the buffer intact and killing it is not important - and "discard" doesn't help with this distinction anyway. The point of stock items is that themes may change them and applications that uses stock items change appearence automatically. I think that Emacs could do better than what is there now, but I do respect that general argument. I wasn't aware of this. Gnome is the GNU desktop environment, so aligning Emacs with Gnome where possible makes sense. It does not make sense to me to change Emacs for the benefit of any other platform. This is not about "any other platform". Aligning Emacs with GNOME is fine, in principle. Recognize, however, that it can also mean a straightjacket at times - Emacs will not be _better_ than whatever GNOME has already defined. Now, if someone would like to make a general solution, like adding the feature that an Emacs user can select from several different icon themes or make his own theme, that would be something. Agreed. If you really want a change to happen it would be more likely if you have made the icons already (both bitmap and pixmap format), and shown us a picture of them in Emacs. Sorry, I'm not an artist or an image guru. I think my descriptions got the point across. It's a moot point anyway, if we are to adhere to the GNOME "standard". I said I wouldn't belabor this, but I did run on a bit. I'll not follow up - do whatever you like. Oo. - Drew ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: suggestions on toolbar icons
OPEN is what the action is, not FILE. Sometimes (without file dialog or the Motif dialog), you can actually open directories with open. So FILE does not apply. Yes, despite the name, `find-file-existing' can also open directories. I still think the folder icon is misleading here. > Similarly, GTK_STOCK_FILE is a standard file icon. This _agrees_ with > my suggestion to keep this icon. It is not FILE, it is NEW we are using. And should be using, as the action is NEW as in new buffer, not FILE. Again, it is possible to make a new buffer without any file with this under the right settings. Fine. How would I know which you use, without checking the code? FILE and NEW are _identical_ icons; they are both standard file icons. So, what is FILE for? Is it perhaps for opening an existing file? It is normal that the two actions "open a new file" and "open an existing file" have similar icons - that's just what I was suggesting we need. Similar, yes; identical, no. File, yes (for both); folder, no. > Are you sure that GTK_STOCK_OPEN is > intended for files, not for directories? it is indeed used for opening existing files. OK. Too bad. > if you are going to use GNOME as a litmus test, then why not > be consistent and use GTK_STOCK_GOTO_TOP instead of GTK_STOCK_HOME for > Info's Top? Likewise, why not use GTK_STOCK_GO_BACK for Back (which is, > presumably, chronological) - as in Web browsers? Why use the GNOME > undo/redo icon (GTK_STOCK_REDO) for Back and Forward? HOME was used because previous Emacs versions use HOME from GTK 1.x. Legacy. BACK is used in info, I presume that is what you mean. Are you suggesting BACK for two actions? I said "why not use GTK_STOCK_GO_BACK for Back (which is, presumably, chronological)." It is used in Info for Previous, not for chronological Back. I already pointed out that it is _not_ good to use undo/redo for chronological moves. The previous version of Emacs used redo/undo, so we keep that. Legacy. Are we tied to legacy as well as to GNOME? And if (as is the case here) they happen to conflict? Apparently legacy wins. To be clear: _IF_ we are to be consistent in adherence to GNOME, then we should 1) use BACK/FORWARD for Back/Forward (chronological moves), 2) use something else (not BACK/FORWARD and not UNDO/REDO) for structural moves, and 3) use TOP (not HOME) for Top. Hang legacy, for things like toolbar icons! > the international exit sign. Make that icon, so we can see what it looks like. Attached (google for "exit"). Also attached: the information symbol (google for "information"). Even countries that don't use international signs use these two in airplanes, airports, and such, so I can't imagine many people haven't seen them. Also attached: possibilities I mentioned for "Preferences" (Customize) and "New File". > "Quit" is clearer (and more common) than "discard". At this level, the > distinction between leaving the buffer intact and killing it is not > important - and "discard" doesn't help with this distinction anyway. It is very important. It is a great difference between just burying a buffer and discarding it. Of course, but it is not a difference that is reflected in "discard" any more than in "quit". If you really want to be a stickler about this, use "delete". The point is that "discard" is as ambiguous as "quit", but it is less familiar to many people. <><><><>___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Options menu
   OPTIONS   ==1 Customize Emacs  >   --2 Language Environment (Mule)  >3 Set Font/fontset   --4 Show/Hide >5  [] Blinking Cursor6  [] Highlighting7  [] Active Region Highlighting   --8  [] Truncate Syntax Highlighting9  [] Paren Match Long Lines in this Buffer10 [] Word Wrap in Text Modes11 [] Case-insensitive Search12 [] C-x/C-c/C-v cut-and-paste (CUA)   --13 [] Use Directory Names in Buffer Names14 [] Save Places in Files between Sessions15 [] Automatic File De/compression   --16  [] Enter Debugger on Error17 [] Enter Debugger on Quit/C-g   --18 Save Options   == 1. I agree generally with David's siggestions.  2. Below is one possible reordering, with some name changes (shorter). Submenus use nouns; menu items use verbs. Some items could be removed, as Kim & David suggested. Debug stuff could be combined in a submenu instead of a main-menu pane.  3. Note the ellipsis (...) for Font: This opens a dialog box (at least on Windows).   [] Remember Last Place in Files 14 [] Search Case-Sensitively  11 [] C-x/c/v to Cut, Copy, Paste  12 [] Auto (De)compress Files 15 --- [] Enter Debugger on Error 16 [] Enter Debugger on Quit (C-g) 17 --- Font... 3 Appearance >   4    (+ current Show/Hide menu)     [] Highlight 6    [] Highlight Region  7    [] Highlight Matching Parens 9    [] Blink Cursor  5    [] Truncate Long Lines  8    [] Word-Wrap in Text Modes 10    [] Add Path to Buffer Name 13  Language Environment (Mule) >   2 More Options (Customize)   >   1 --- Save Options   18 ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: suggestions on toolbar icons
> use something else for structural moves, You are assuming somebody else should figure out what this "something else" is. I made several concrete suggestions for this "something else", starting with "->..." (left, right, and up versions) and including other Gnome icons. And Lennart made a suggestion (arrow pointing to a page). I can only suggest. >> the international exit sign. > Make that icon, so we can see what it looks like. > Attached. These are visually inconsistent with the rest of the toolbar And? Of _course_ a harmonious set of icons would be needed. I sent prototype images to give you an idea of what I meant, because you asked for them and you said you didn't understand my verbal description. I made it clear that those images are just pulled from various Web pages (googling); I sent URLs in my first message. IOW, you said you didn't understand my description, you didn't follow the URLs to see what I meant, you asked me to send an image to clarify, and then you said that the images I sent don't fit what's already there now. Can you say "mauvaise foi"? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: suggestions on toolbar icons
Man, you start out implying you don't want to start an argument and yet fill your message up with this sort of crap. You clearly don't like Gnome -- and I certainly have my own long list of complaints about it -- but please save the anti-Gnome rants for some other list. So I'm a Gnome-hater now? And a Microsoft pusher? Ad hominem ad nauseum. For the record: 1. I have nothing against Gnome. I have never seen or used Gnome. I had hardly heard of Gnome before Jan's email; I did not know that Emacs was using Gnome icons; and I did not know that Gnome had a set of generic icons. I stated explicitly that aligning Emacs with Gnome was fine, in principle. I mentioned that I agreed with the idea of using generic icons that can change appearance automatically - that's very good - I mentioned that I wasn't aware of that possibility. I pointed out a few places where Gnome icons _agreed_ with what I was suggesting (versus what is now in Emacs). I (and Lennart) suggested using some Gnome icons that are not used now, and I suggested using some of the Gnome icons differently. 2. I do use Windows now in my work, as well as GNU/Linux (remotely - xterm only). I am not particularly a fan of Microsoft as a company, and I don't think Microsoft UIs are always great - far from it. I think free software as a movement is great, and Microsoft as a movement is not. But that does not mean that everything GNU is the best there is, that there is no room for improvement, or that inspiration for such improvement cannot come even from the likes of Microsoft or other devils. It so happens that none of my suggestions on icons were inspired by Microsoft products (to my knowledge), but so what if they had been? It is silly (counter-productive) to circle the wagons each time you think someone has mentioned something happening outside the cult. "Burn the heretic!" will eventually leave you with few of the faithful left to burn. 3. I don't even use the toolbar - I just happened to open a recent Emacs and came across what I felt were not-the-most-helpful icons. I sent along some ideas for improvement, with no particular expectation that any one of them might be adopted. In several cases I gave alternative suggestions - the suggestions were obviously intended as food for thought, as possible minor improvements. The response was, essentially: 1) Gnome doesn't allow/provide this, and 2) where allowed/provided, it conflicts with the legacy Emacs icons. End of story. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Type Ahead Find
Tres cool. Very useful. (Haven't tried it, but the description sells it, to me.) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Options menu
> From: "Drew Adams" <[EMAIL PROTECTED]> > Date: Fri, 18 Mar 2005 07:48:49 -0800 > > OPTIONS > == > 1 Customize Emacs > > -- > 2 Language Environment (Mule) > > 3 Set Font/fontset > -- > 4 Show/Hide > > 5 [] Blinking Cursor > 6 [] Highlighting > 7 [] Active Region Highlighting Please don't make such a change: the simple toggle-type options should come first, and the submenus (like Mule) later. Not the other way around. Likewise with Customize: it should come after the toggles. Uh, are you sure you're replying to me? What you quoted was from Kim; I suggested something different that agrees 100% with what you just said. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Antialiased text on X11
The fact of the matter is that anti-aliased fonts specially on LCD screens look much better than non-antialiased fonts. Its rather sad that I have to use xemacs on windows (such a heresy) in order to have my fonts antialised. I'm not an expert on anti-aliasing, but I use Windows XP on an LCD with ClearType smoothing of screen font edges, and it works beautifully. I only wish I had the same effect when I use Emacs on Linux (I'm not saying there is no way to do that, but I'm ignorant of it). If you use Windows XP, try this: 1. Right-click the desktop, choose Properties. 2. Open the Appearance tab (panel). 3. Click the Effects... button. 4. Check the box labeled "Use the following method to smooth edges of screen fonts" 5. Choose ClearType or Standard (I use ClearType). 6. Click OK. Click OK. Does that not do what you want? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Todays exercise of sanity (or does "see" really match "not"?)
I guess that you have Info-hide-note-references enabled. The reason why it stops on "see" is that the actual text in the buffer is: (*note Character Sets::). and note matches "not". I filed a bug report on this behavior on Oct 4. Juri fixed it on Oct 31 with respect to stuff in the header (File, Next etc.), but there was no fix AFAIK for Note and Menu. In discussion of the bug report, I stated that "we should be able somehow to separate _content_ in a manual from _structural and navigational artifacts_ that support that content." I still think that should be the goal: users should use TAB to go to the next cross reference, instead of searching for "Note". The text "Note" for a cross reference is not content; it is metacontent. If a user searches for "Note", he should find only occurrences of the actual text "Note" in the manual, not cross references. In practice, however, it might not be that easy to distinguish content from meta-information in the case of meta-info that is not in the header. At least that's what I understood from the discussion at the time. Here is part of Juri's explanation from that discussion: `Info-search' searches for a string on raw text of Info files. Some parts of Info files where Info nodes were already visited are fontified and have `invisible' property. But fontifying and adding `invisible' or other properties to hide the tags from search to the whole Info file before search is too inefficient, so `Info-search' can't rely on text properties. Instead of that, it should rely on the known syntax of Info files such as that Info nodes begin with a ^_ character. I think skipping the header is sufficient to ignore irrelevant parts of Info nodes, and I see no problem with other special Info tags like Note and Menu. In reply to David's point about preview-latex needing to search and find the meta-text: I agree that programs need to be able to find meta-text. The point is to separate such meta-text from the content - or at least be _able_ to separate/distinguish it. In most modes, at least, Info-search should not find strings that are in meta-text (if this is not to difficult to fix). ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Todays exercise of sanity (or does "see" really match "not"?)
> > `*Note' is a special tag, not part of the text. > `*Note' _is_ a part of the text. There are obviously different ways of looking at this, and the issue is not just one of terminology (what we decide to call "text" or "content"). Perhaps we can agree that some people and some programs will likely want to treat such stuff as part of the "text/content/data" and others will want to ignore it as part of the "text/content" and treat it instead as "tags"/"metadata". It will always be true that one person's data is another person's metadata. The analogy with markup is useful, even if it is true that 1) the mechanism used in Info is not exactly markup and 2) at least some of these "tags" (e.g. "Note") are visible in the Info text. Perhaps we can also agree that we should not try to change anything about this now, at least not in any fundamental way. And perhaps we can also agree that it might be good to look, later, at the possibility of letting users/programs have their cake and eat it too: be able to treat such "tags" as data or metadata, au choix. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: mouse-face vs. transient-mark-mode
When an overlay property of 'mouse-face 'highlight is set on a line, and transient mark mode is on, and you attempt to drag out a new region in the line, the region mark overlay does not show, and significant flickering occurs as you drag the mouse inside the highlighted text. As soon as the mouse moves out of the mouse-face area (either during the drag or after it's completed), the mark face is visible. The flickering is present even when transient-mark-mode is disabled.. Is it possible to set a priority on either mouse-face or the region highlight property to have the former yield to the latter? I can't answer your question definitively, JD, but I think the answer is "no". Caveat - The rest of this message is about a possible new feature, so it is not intended for real discussion before the release. I mention it now as food for thought, because of JD's request. I mentioned a few months ago that I thought it be great if one could have a mouse-face text property combine visually with the face text property: Ideally, I would love to be able to use underlining _without removing any font-lock highlighting_; that is, simply underline the text when you point to it, without changing any of its other properties. That's the behavior in most Web browsers. I was speaking of using underline (for example) as the mouse-face, and I mentioned only font-lock highlighting, but the general idea is to let the mouse-face show up in combination with the face. That way, you could see the normal (font-lock) highlighting as well as things like the region. Of course, the desired effect would only be achieved if the two (mouse-face & face) combined well. JD's request for being able to set a precedence might fit here. As I mentioned previously: I'm not sure if that's easy to do, or even feasible, in Emacs I don't know much about face inheritance, but perhaps that could be used somehow in this regard. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Should killing a help or compile buffer also delete the window?
I've always found it annoying that Emacs seems to have a habit of leaving junk windows around whenever you invoke something that needs to display information in a temporary buffer I realize that you can't expect Emacs to know when you are done with a window unless you actually tell when. The obvious way to tell when is to type `C-x 1' or `C-x 0', but this leaves the temporary buffer lingering, which makes me nervous When I was new to Emacs, I would always kill a garbage buffer before deleting its temporary window. Eventually, I discovered `C-x 4 0' and started using that I believe the Right Thing to do when the user kills a temporary buffer whose window was created as a side-effect of displaying the buffer in question is to restore the old window configuration. At least when the automatically created window hasn't been used for anything else, Emacs should take the hint and get the window out of the user's face. The annoyance you describe is, I think, exacerbated (or perhaps is only manifest?) when one uses one window per frame by default, as I do. And commands like `delete-window' and `kill-buffer-and-window' don't help in this regard, with one-window frames. FWIW, I customized a few things in my Emacs to deal with this. I mention it for those who might be interested, not as a proposal to change Emacs itself. If interested, see the short description at http://www.emacswiki.org/cgi-bin/wiki/Delete_Frames_Easily_-_But_Not_Too_Eas ily. Wrt various efforts to deal with this and your comments on deleting windows and killing buffers: Deleting a window should not, in general, delete (kill) its buffer, but killing a buffer _interactively_ can often reasonably delete its window too (and frame, if `one-window-p'). - Drew ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
mouse-1-click-follows-link: doc, Options menu, customize groups
I fired up GNU Emacs 21.3.50.1 (i386-mingw-nt5.1.2600) of 2005-01-30 on NONIQPC and discovered that mouse-1 was now following links. Not remembering the email thread about this, I looked in Emacs itself for how to turn this new behavior off. I didn't find anything about it in the Emacs manual or the Emacs Lisp manual. I searched everywhere for "mouse-1" (and that's a lot of hits). I tried looking in Customize by browsing groups. Starting at the top, I didn't see anything about "mouse", so I tried group "convenience" - to no avail. After I searched my emacs-devel email and found the name `mouse-1-follows-link', I searched Info for that, still to no avail. I tried `describe-variable' and then clicked the customize link, finding that the only group for this option is "mouse". Some questions: - Shouldn't this option be described in the Emacs manual? - Should this option perhaps be added to the Options menu? Maybe not, since this that menu is best for things that you are likely to change more than once. - Does it perhaps make sense to add _all_ options to the Options menu that change commonly used behavior from the previous Emacs version? Such options could be candidates for removal from the menu in later releases, but Emacs users will want to know how to turn off or modify any new default behavior that they discover. - Does it perhaps make sense to add "convenience" to the customize groups for this option? - Does it perhaps make sense to add "convenience" as a parent to the "mouse" customize group? Its only parents currently are "environment" and "editing". ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Unclear in etc/NEWS
I saw this text in etc/NEWS --- *** Unexpected yanking of text due to accidental clicking on the mouse wheel button (typically mouse-2) during wheel scrolling is now avoided. This behavior can be customized via the mouse-wheel-click-event and mouse-wheel-inhibit-click-time variables. and I don't understand it. It says that a certain problem won't happen, but it fails to say what Emacs actually *does*. Would someone who understands this please clarify it? I may be wrong, but I believe this means that previously you might accidentally press the wheel while rotating it, that was interpreted as a mouse-2 click, and that caused a spurious yank. Many mouse wheels also function as mouse-2, by pressing them. It is all too easy to accidentally press the wheel while you rotate it. This fix presumably ignores mouse-2 clicks interspersed with wheel rotations. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
compilation-finish-function vs compilation-finish-functions
What is the usage difference between `compilation-finish-function' and `compilation-finish-functions'? I don't see this explained anywhere. I haven't checked the latest CVS info files for the Elisp manual, but I have checked the latest compile.el source code and see no explanation there. Shouldn't the usage be documented somewhere? Clearly, a user would generally not use both of these. Is one of them intended to be deprecated? If not, shouldn't the order of execution (first `function', then `functions') be advertised? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: run-hooks vs. run-mode-hooks.
> (if (fboundp 'function-in-doubt) > (defalias 'mymodule-function-in-doubt 'function-in-doubt) > (defun mymodule-function-in-doubt ...)) Actually this form has the disadvantage that the byte-compiler would have to check which functions are defnied in every branch. And snice it doesn't do that as of now, the byte-compiler won't noticve that this form does define `mymodule-function-in-doubt' and will hencforth issue warnings when you call that function. Better use: (defalias 'mymodule-function-in-doubt (if (fboundp 'function-in-doubt) 'function-in-doubt (lambda (..) ...))) which makes it trivially obvious that `mymodule-function-in-doubt' will indeed always be defined. Is the behavior of the byte-compiler for this kind of thing explained somewhere? That is, are there coding guidelines somewhere to guide Lisp users wrt the byte compiler? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
frame parameters user-size and user-position
1. Frame parameter `user-position' can be used to tell the window manager that the user has positioned a frame. Is there an equivalent `user-size' parameter to tell the window manager whether the user has sized the frame? I don't see `user-size' documented anywhere (e.g. Info (elisp)), but I see it used in these files: faces.el, frame.el, mac-win.el, w32-win.el, x-win.el, and frame.c. If it is similar to `user-position', shouldn't it be documented? 2. The doc for `user-position' says that you can use it to tell the window manager that the user positioned the frame, in hopes that the w-m will leave the position alone. I assume something similar is behind `user-size'. I have never seen either of these parameters in any of my frames, so I assume they are only there if I add them myself. (I'm using Emacs in Windows, if that makes a difference.) That would seem to agree with the doc, which just says you can specify them when you create a frame. Would it be possible (after the release) to have Emacs update these frame parameters whenever a user repositioned or resized a frame (e.g. using the mouse)? That is, could we perhaps use these parameters to _indicate_ whether the user has repositioned or resized a frame (even if the indication is not 100% reliable)? Would this be possible (for at least some window managers), or is this information not available from a window manager? For this to work, Emacs would need to record a non-nil value for the frame-parameter whenever the user manually moved or sized a frame and (by default) set it to nil when a frame is created or moved/sized by program. My question is one of feasibility, for now. I don't want to start a discussion about a possible new feature; I'm just wondering if this is feasible. Such an indication of user frame-sizing could be useful, for example, for code that tries to automatically resize a frame to fit its buffer. If the user has previously sized the frame, an automatic resize would presumably not be done, in order to not override the user's intention. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: [rant] Should reverting a buffer really discard undo history?
In theory, we could treat the revert operation as an undoable change to the buffer contents. In practice, for large buffers, that change would be so large that it would soon be discarded from the undo list. For even larger buffers, the result of saving the whole buffer as an undo record would be an immediate error. It would be impossible to revert. So I am against this change--at least if it were the default. So, it could still be considered as an option? The values of the option would reflect a performance-vs-safety/security tradeoff. The default value would choose performance, and the doc could tell users how to opt for more safety/security at the price of a possible performance hit. I'm not real familiar with the mechanics of the undo list, but couldn't the previous file contents be stored only on disk, as a temporary file, and the value in the undo list be just a pointer to that file instead of the file contents? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: mouse-1-click-follows-link
> > Some like grep, seem to cover a lot of the buffer. I'm not saying > > that you can't get round it, just that it requires thought. > > Good point. I'm much less sure that it's good in the case of grep. > Maybe it could work to put a little jump button next to each entry, > instead of using each whole line as a link? Though that wouldn't be > good for keyboard users... What if there was a button for clicking, > but you could also press RET anywhere on a line to follow the link? In the compilation buffer mouse-face (and therefore mouse-1) only works on the file and line number while mouse-2 and RET work for the whole line. It would help if grep also worked this way. I disagree. My opinion: 1) mouse-1, RET, and mouse-2 should all behave similarly. What's good for mouse-2 is good for mouse-1 too. The challenge is to find the right default behavior (trade-off/compromise). 2) The entire line should be the hot zone (no "button"). Makes it very easy to scan lines and align text anywhere on the line with the proper hot zone. No need for your eye to move between the text (anywhere on the line) and the hot zone. 3) The grep behavior (full-line hot zone) should hold also for the compilation buffer (compilation and grep should behave similarly). 4) mouse-1 should follow links by default, for the reasons others have given (even though I, myself, might choose to turn this off). 5) The delay for mouse-1 to set point should be short, by default, so it is not inconvenient to set point with mouse-1. The current default delay is too long. Users will naturally click very quickly to follow a link, and if they click too slowly, they will quickly learn to click quicker (or consult the doc to change the delay value). Clicking a little too slowly unintentionally (i.e. when intending to follow a link) will just set point, which is benign. 6) The default (emacs -q) value for mouse-1-click-follows-link is apparently 450 ms. The doc string says that the value (not the default value, but the value) is 350 ms, which is incorrect. The doc string should be corrected, so that it does not use a hard-coded value. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: mouse-1-click-follows-link
> 5) The delay for mouse-1 to set point The delay for mouse-1 to set point is completely unintuitive, and no other application I have ever seen works that way. Sorry, could you please clarify? Is your response related to my message (suggesting to shorten the current default value of the delay) or to the general idea of having a delay, or...? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: mouse-1-click-follows-link
> There seems to be an increasing trend to make Emacs look and act like > a web browser in all contexts, making it frustrating to use for text > editing purposes. Setting the point is basic functionality, and I > shouldn't have to cross my fingers, double tap, hold, turn around and > touch my nose to do it. I'm more and more inclined to agree. I think the mouse-1-clock-follows-link behavior should be used (by default) at most at a few well-tested placed. E.g. custom (where it's already working this way in 21.4 AFAIK), help, info. But not grep, not compile, ... The idea of having mouse-1-clock-follows-link activated by default is to make it easier for beginners accustomed to web browsers more than to text editors, and maybe that makes sense, but we shouldn't overstate this case either: the number of users we can expect to win thanks to this minor detail is likely to be vanishingly small. It's not like the mouse-2-follows-link convention is the only "unusual" UI aspect of Emacs. So maybe turning it on for a handful of cases makes sense. And keeping a more intrusive option may also make sense for people whose system makes it hard to generate a mouse-2 event. But the current setup has tricked me too many times already. I know I can turn it off, but we should be careful not to alienate our fervent disciples. I too have no problem with different default values for mouse-1-follows-link in different buffers. Some will scream "inconsistent", but that's OK by me. The default could be nil in buffers like grep, compilation, and dired, and non-nil in buffers like Info, Help, Apropos, and Customize. Major modes could define an appropriate value. With time and user feedback, we could refine the fit. What about the default value (setq-default) for buffers/modes that don't specify either behavior? We could just try non-nil and see what happens (users would let us know quickly enough). On the other hand, it probably makes more sense to use non-nil only for the cases where we generally agree that it makes sense, and use nil for setq-default. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: mouse-1-click-follows-link
> 2) The entire line should be the hot zone (no "button"). Makes it very easy > to scan lines and align text anywhere on the line with the proper hot zone. > No need for your eye to move between the text (anywhere on the line) and the > hot zone. Thats not much of a compromise! Jason's point about the touchpad makes it even more important that the entire line should be *not* be the hot zone. It was meant only as my opinion, FWIW, not as a compromise of any kind (between what and what?). And, as I've said before, having the entire line be a hot zone is more important to me than being able to use mouse-1 to follow links. > 5) The delay for mouse-1 to set point should be short, by default, so it is > not inconvenient to set point with mouse-1. The current default delay is too > long. Users will naturally click very quickly to follow a link, and if they > click too slowly, they will quickly learn to click quicker (or consult the > doc to change the delay value). Whatever the period, its hard to estimate in your head while clicking. How long should a piece of string be? Such a delay is not estimated in one's head. You try it. Too slow? You try it faster. Too fast? You try it slower. You like it? You save it. BTW: In Windows, the mouse double-click delay is configured with a sliding scale, and you can double-click a test area to see what the value would mean _in practice_. Handy and simple. Something like this could be useful for defining mouse delays in Emacs too. In the present case, you would test-click (mouse-1) a link to see if you liked the current delay - change it and test-click again etc. Should be simple to implement. (Just an idea, for consideration after the release, not now.) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: mouse-1-click-follows-link
mouse-1-click-follows-link is nicely defined to satisfy everyone, I think. You can turn off mouse-1 link sensitivity completely or activate it on: 1) short (fast) click, 2) long (slow) click, or 3) double-click. Good job. What we've *not* come to agreement on yet: 1) Whether the behavior should always be the same in each buffer or should possibly vary by buffer. If the latter, should this be user-changeable (e.g. local values) or not? 2) What the default value should be. If we allow local values, this means both a) the default global value and b) the default local values for different categories of standard buffers (e.g. those dense with links, like Dired, vs those sparse with links, like Info). Our options include `nil' (mouse-1 doesn't follow links at all), +integer (fast click follows link), -integer (slow click follows link), and `double' (double-click follows link). My opinion: 1. Users should be able to have different behaviors in different buffers, in this regard. 2. The global (default) value should be `nil': mouse-1 should be insensitive to links by default. 3. The default value for buffers that are sparse with hot spots (e.g. Info, Help, Customize) should be 100 ms (fast click follows link). 4. The default value for buffers that are dense with hot spots (e.g. Dired, grep, compilation) and for which users will likely want to set point occasionally should be `double' (double-click follows link). 5. The default value for buffers that are dense with hot spots, but for which users don't need to set point at all (eg. Buffer List) should be 100 ms (fast click follows link). (There are probably few such standard buffers.) 6. Any default values that are set to "fast click follows link" should use a much faster click value than what is currently the default, so users can more easily set point. Most users intending to follow a link will click quite fast, naturally. A value such as 100 ms is better than the current default of 450 ms, which is far too slow. [Please try different values, even if you don't intend to have mouse-1 follow links on single clicks, so we can get a consensus wrt a good value to recommend or use as default in appropriate buffers. Try negative values too, and mention if you prefer slow click follows link to fast click follows link.] 7. Whatever we agree upon, the design should be communicated to users as recommendations for their own buffers of different kinds. If we decide to allow different values in different buffers, we should include, in the mouse-1-click-follows-link doc string, suggested guidelines for using different values with different buffer types. This will encourage relatively consistent use patterns. 8. Users should be able to have full-line hot zones for buffers that are essentially lists of links. This includes grep, compilation, and Dired. RMS has apparently decided to reduce the hot-zone size for grep. I prefer full-line links. It would be good for users to be able to customize this, regardless of the default behavior. IOW, because of the recent move to mouse-1 following links (even potentially), we are now losing full-line links in grep. People accidentally followed links (me too), so the hot zones are now being reduced to alleviate this problem. I don't agree with that solution to the problem, but all I would ask for is a way for users to get back the full-line link behavior. Mouse-1 is extremely customizable now via mouse-1-click-follows-links, but the hot-zone extent is not customizable at all, without rewriting the grep/compile code. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: mouse-1-click-follows-link
> 1. Users should be able to have different behaviors in different buffers, in this regard. I think this should clearly be global-only. It's important for things to be predictable by a normal user who can't remember which mode does what because she doesn't spend 25hours per day in Emacs. But in a different email, you also wrote: I think the mouse-1-clock-follows-link behavior should be used (by default) at most at a few well-tested placed. E.g. custom (where it's already working this way in 21.4 AFAIK), help, info. But not grep, not compile, ... If it is to have different behavior in different places (even if only a few well-tested ones), then how do you want to do that, without using local values for mouse-1-click-follows-link? Hard-code the behavior? If so, how would users override it? If mouse-1 should, by default, follow links in some places (but not in others), no matter how few, wouldn't using a local value for mouse-1-click-follows-link be the best way to accomplish that? IOW, you make two arguments, I think: 1) Let's have some, but not too many, places where mouse-1 follows links, by default (because it needs to be predictable; it's hard to remember...). 2) mouse-1-click-follows-link should be global only. I don't see that #1, by itself, supports #2. What is the reason for #2? Why not implement #1 with local values? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: mouse-1-click-follows-link
Summary:
(1) mouse-1-click-follows-link: it should be `nil' everywhere. (I've
changed my opinion.)
(2) We should change the link mouseover pointer.
(3) Hot-zone extent should not be based on a supposed tradeoff between
setting point and following a link. That's a red herring.
Reasons below. Here's where we are now:
mouse-1-click-follows-link is nicely defined to satisfy everyone,
I think. You can turn off mouse-1 link sensitivity completely or
activate it on: 1) short (fast) click, 2) long (slow) click, or 3)
double-click. Good job.
What we've *not* come to agreement on yet:
1) Whether the behavior should always be the same in each buffer
or should possibly vary by buffer. If the latter, should this be
user-changeable (e.g. local values) or not?
2) What the default value should be. If we allow local values,
this means both a) the default global value and b) the default
local values for different categories of standard buffers
(e.g. those dense with links, like Dired, vs those sparse with
links, like Info).
Our options include `nil' (mouse-1 doesn't follow links at all),
+integer (fast click follows link), -integer (slow click follows
link), and `double' (double-click follows link).
Here's what I said before:
My opinion:
1. Users should be able to have different behaviors in different
buffers, in this regard.
2. The global (default) value should be `nil': mouse-1 should be
insensitive to links by default.
3. The default value for buffers that are sparse with hot spots
(e.g. Info, Help, Customize) should be 100 ms (fast click follows
link).
4. The default value for buffers that are dense with hot spots
(e.g. Dired, grep, compilation) and for which users will likely
want to set point occasionally should be `double' (double-click
follows link).
5. The default value for buffers that are dense with hot spots,
but for which users don't need to set point at all (eg. Buffer
List) should be 100 ms (fast click follows link). (There are
probably few such standard buffers.)
(1) I've changed my opinion on #4 and #5. By default, the value should
be `nil' everywhere: mouse-1 should *not* follow links.
Reasons:
a. mouse-2 as yank is not needed on a link, so mouse-2 is a
perfect choice for following links. That was surely behind the
original design, and it remains the best argument for mouse-2.
Having mouse-1 sometimes follow a link and sometimes set point
(e.g. via different delays), in the same buffer, always involves
some UI tradeoffs (fast-click, slow-click, double-click). That's
OK, but it should not be the _default_ behavior anywhere.
b. With mouse-1-click-follows-links, especially if we allow local
values, everyone can do what he wants, wherever he wants. This
includes people who use mice without mouse-2. IOW, even if mouse-2
is the default for links, users can choose instead to use mouse-1
in various ways for linking. Previously, users could not easily
switch to mouse-1; now they can.
c. Newbies will discover mouse-2 for links soon enough. They will need
to discover it for yanking, anyway; it is no harder to learn it for
linking. Up front, we should:
(i) Tell them about mouse-2 for linking.
(ii) Suggest they try it for a while ("try it; you'll like it").
(iii) Tell them they can change it: mouse-1-click-follows-link.
d. It is not difficult to go back and forth between mouse-2 for
linking in Emacs and mouse-1 in other apps. We all do it all the
time. The argument that people are "used to mouse-1 for linking" is
countered by c plus d - there are two aspects to it.
(2) As I said in October, and which led to Kim coming up with using
mouse-1 for linking, we should change the finger-pointer cursor over
links. The index-finger pointer _suggests_ using mouse-1.
That pointer is commonly used by Web browsers to indicate that the
pointer is over a hyperlink or an action button, so that's
presumably the reason it is now used in Emacs for the same thing.
However, in common Web browsers, the mouse button to activate
such a link or button is mouse-1, not mouse-2. What bugs me is
that the index-finger pointer suggests to me to use mouse-1,
because the index finger (wired, in my head, to mouse-1) is the
one doing the pointing.
RMS and Kim both thought I was asking to use mouse-1 for links. I was
only suggesting to change the mouseover pointer. RMS wrote:
Mouse-1 can't do that. Mouse-1 in Emacs is a general Emacs
command that is meanigful anywhere in the buffer.
Anyway, this is not the time to change features.
Kim came up with a patch to use mouse-1 for links, and we were off and
running. I wrote:
> My point was not that using mouse-2 is not good. I think mouse-2
> should remain the way to click links and bu
RE: mouse-1-click-follows-link
>I dislike underlined links --- even on web pages, but as long >as I can turn it off, it may be ok... Usability surveys has often found that users wants links to be underlined (in most situations). We shouldn't go overboard. Underlining links is important in _text_, so users can see they are there. Web pages of text are behind the convention of underlining links for visibility. However, it is only distracting to underline links in, say, a table or list where each entry is a link. Users must know that the table/list contains links; once they know that, there is no need to highlight each link. I would argue, for instance, that Dired, grep, and compilation buffers should have full-line links, for ease of use. But, to use these buffers, users must be somewhat familiar with them anyway. Given that minimal familiarity, there is no reason to underline the full-line links - mouseover highlighting suffices (and underlining is a good choice for mouse-face in these buffers). If, however, as RMS and some others prefer, such buffers will not have full-line links by default, then, yes, the links should be underlined (face, not just mouse-face), so users can find them. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
link appearance and soft face properties
We've been discussing whether or not links should be underlined, whether or not link underlining should be applied to the link face or its mouse-face, and whether or not link appearance should be the same in all buffers. Just a thought, for consideration after the release: What about having a :link face attribute (property) that is soft, not hard? This would be analogous to using soft markup like Emphasis, as opposed to hard markup like Bold: Emphasis can be different for different users/applications/environments, whereas Bold always means bold. That is, in order to separate purpose/intention/use from physical formatting, why not have soft face attributes like :link that a user can define/override (e.g. in terms of faces or face attributes)? IOW, why not separate identifying something as a link from defining its appearance? That way, a single (possibly user) definition of the :link attribute would automatically affect any faces that have that property. And it would also be easy (including for users) to selectively apply the :link property to face or mouse-face or both. Discussion here of the appearance of links (underline vs this or that) would then be reduced to discussion of 1) the default appearance of the :link face property and 2) whether to apply :link, by default, to face or mouse-face or both (and, perhaps, in what buffers). Less heat, more flexibility. This would also carry over to other soft face properties, having an impact on the appearance of things like the mode-line and buttons. Instead of hard-coding the appearance of everything, we would define a default appearance using high-level property classes like :link. Note: I'm not that familiar with face definitions, face attributes/properties, and face inheritance, so don't get excited if this makes little sense. In particular, perhaps this functionality is already available via face inheritance or in some other way. In that case, what about using this functionality to implement a generic "link" face or face property that would then be inherited by the appropriate faces that are today used for links? IOW, such properties appear today to be hard-wired - why not look for some way to soft-define them? A link is, after all, a user-interface object that exists independently of its particular formatted appearance. In Web browsers, users can easily decide whether links should be underlined, green, etc. or not. Why not give that same flexibility to Emacs? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: debug-on-entry question
change the interactive specification of `debug-on-entry' to call `function-called-at-point'. Yes. I've suggested this previously. When debugging, you are often in an Emacs-Lisp buffer, and this is useful. For post-release: it would be good to rewrite the function `call-interactively' in Lisp which will allow easy modification of reading arguments according to code letters (e.g. in this particular case adding a call to `function-called-at-point' for the code letter `a'). Not a bad idea. --- However, that would only help with uses of `call-interactively', not uses of `interactive' itself. It's probably not feasible (and I foresee immediate dismissal of the idea, regardless of feasibility), but what about also having a mechanism to let users extend (redefine) the predefined `interactive' code letters? For example, a user could define his own version of `b' in `(interactive "b...")'. Instead of having to find all occurrences of `(interactive "b...")' and replacing each of them with his own `(interactive (list (my-read-buffer...)...)...)', he could just redefine what `(interactive "b...")' means, in a single place. IOW, why not make the "bindings" between the `interactive' code letters (e.g. `b') and their input-reading functions available to users? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: link appearance and soft face properties
> That way, a single (possibly user) definition of the :link > attribute would automatically affect any faces that have that > property. And it would also be easy (including for users) to > selectively apply the :link property to face or mouse-face > or both. > > I think this can be done by making these faces inherit > from a face named `link'. This is an interesting idea, but then for consistency this should be applied to every mouse-over attribute with follow-link property, i.e. not only in compilation and grep buffers, but also in info, dired, gnus... Yes, that's what I meant: use a predefined (but user-customizable) `link' face everywhere, for links. Currently, we have no "soft" (= user-changeable) notion of what a "link" is. In fact, even apart from a lack of customizability, we have no notion of "link", except for that provided by the `follow-link' property (which is not even used for all links). A link is currently defined only by whatever the underlying code happens to do with a mouse-1 or mouse-2 click at that position: if the code "follows a link" upon mouse click, then we can say that a link is present. One cannot assign "linkness" (behavior and appearance) to a portion of text. The appearance of a link is governed by a face or mouse-face at that position. There is no notion of a "link" object that unites function and appearance (and allows for user modification of appearance). Providing a link face (that inherits etc.) and using it for all links (i.e. places where the code in fact "follows a link" upon click) would let users customize, in a single place, how links appear. (If we provided buffer-local faces, users would also be able to easily customize link appearance on a per-buffer basis.) Best: Provide "link" objects: text that has certain properties that include both appearance and "link-following" behavior when clicked. OK (but < Best): Provide only a "link-appearance" text property or face. We would continue to count on an underlying association of locally coded mouse-click-link-behavior with the text that has the `link' property or face. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: link appearance and soft face properties
What about having a :link face attribute (property) that is soft, not hard? What does "soft" or "hard" mean, here? Soft: The appearance of a soft text property like :link would be whatever a user says it is. By default, it might be a set of properties with just one member: the :underline property. Hard: The appearance of a hard text property like :underline always means the same thing: the text is underlined. Users can decide to use it or not use it, but they cannot redefine it. That way, a single (possibly user) definition of the :link attribute would automatically affect any faces that have that property. And it would also be easy (including for users) to selectively apply the :link property to face or mouse-face or both. I think this can be done by making these faces inherit from a face named `link'. I thought that might be the case. Instead of "soft" text properties (which would be definable as a set of soft and hard text properties), an inheriting face could be used. IOW, a face is already a set of text properties (you can say "has" if you don't like "is"), and we already have face inheritance. A potential difference I see is that the thing that inherits is a face, rather than a text property. In the present case, we would define (and use for all links) a `link' face that inherits certain properties (e.g. :underline) by default. I'm not sure that would be equivalent in flexibility to defining an inheriting (= "soft") text property :link, but perhaps it would be. If we can do this (predefine links in a soft way) using face inheritance, then why don't we (after the release), in order to give people more flexibility? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: debug-on-entry question
> change the interactive specification of > `debug-on-entry' to call `function-called-at-point'. > > Yes. I've suggested this previously. When debugging, you are often > in an Emacs-Lisp buffer, and this is useful. _If_ you are in an Emacs-Lisp buffer and consequently have the source code of the function to be debugged available, edebug-defun is orders of magnitude more useful for debugging a particular function. debug-on-entry is much less convenient, but can be used without having the source at hand. OK. I take that as an FYI about the usefulness and appropriateness of edebug in a source-code buffer, but not as an argument not to let `debug-on-entry' grab the function-at-point in its interactive spec. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: link appearance and soft face properties
Hard: The appearance of a hard text property like :underline always means the same thing: the text is underlined. Users can decide to use it or not use it, but they cannot redefine it. This is a weird statement. What should people who listen to underlined text do? (They may want the underlined text to be different from the rest.) What should people who look at text, but for various reasons, use colors, never underlines or other such modifications. (Setting in their .emacs file.) I'm not sure what your point is. Is it my statement that you find weird or the fact that :underline is cast in concrete as underlining? Are you suggesting that text properties such as :underline should have or should allow an alternative interpretation for, for example, those with disabilities such as loss of sight? Are you suggesting that such text properties can already be used in this way? What is your point? If you are questioning whether such properties are really "hard" today, that is, whether they do not in fact allow for alternative display or interpretation as, say, sound, then I think the answer is "yes" - out of the box, Emacs does not allow for any alternative treatment for such properties: :underline always means "underline". The :underline text property simply determines whether or not the text in question is underlined. From Info: `:underline' Whether or not characters should be underlined, and in what color. If the value is `t', underlining uses the foreground color of the face. If the value is a string, underlining uses that color. The value `nil' means do not underline. Someone might, I suppose, write code to interpret :underline in some other way. That is not the point I was making by distinguishing "soft" from "hard" text properties. In particular, I wanted to distinguish link text from underlined text. Just because some text might be underlined does not make it a link. To be a link, it must behave as a link. I suggested we provide a way to make a portion of text appear as a link - in whatever way that appearance might be manifested. Being able to realize :underline text as text read aloud in a certain way would not help us with the problem of changing the representation of links, because not all :underline text is link text. The distinction of soft from hard that I was driving at is, as I mentioned, the difference between using Emphasis and Bold markup tags: Emphasis text is intended to be displayed in different ways, depending on the context; Bold text is not. It is the difference between software and hardware. Softer vs harder is essentially later vs earlier binding. Such a distinction is old - you can see it in the design, for instance, of Tex/LaTex. Maybe there is a better name for it than "soft vs hard" - I don't know. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
File menu changes (suggestions)
Suggestions to change some File menu items. A few of the renamings might be considered for this release. 1. Unsplit Windows is a very poor name. It doesn't give you a hint of what it does; in particular, it doesn't suggest that the current window is the only one that will remain displayed. It should be named something like `Delete Other Windows' or simply `One Window'. 2. Don't reference "buffer" or "file" in File menu items, when this just refers to the current buffer/file (or the one that will become current). The unreferenced object in a File menu item is understood to be the current buffer/file. And the distinction between file and buffer is not needed here. - New File-> New (but Open is better - see 3, below) - Save (current buffer) -> Save - Close (current buffer) -> Close - Save Buffer As -> Save As - Print Buffer-> Print - PostScript Print Buffer -> PostScript Print - Revert Buffer -> Revert People are used to all of these File commands in other applications. You don't see "Save Page" or "Close Page" in Web-browsers or "Save File" in other editors. In particular: a. Currently, there is an inconsistency wrt "Buffer" and "(current buffer)". These should be made consistent, since the same thing (the current buffer) is involved in each case. It is not as if one acted on the current buffer and the other prompted for an existing buffer to act upon. b. New File does not really create a new file; it opens a buffer (new or existing) that can be saved to a file (new or existing). Not mentioning "file" and "buffer" avoids the distinction, which doesn't matter here anyway. Mentioning "file" and "buffer", and using "file" where it should be "buffer", just misleads. So, New is better than New File (but see 3, below). 3. WRT 2b, it is true that the file or buffer opened need not in fact be new, so even "New" is misleading. The problem arises because we need a name to distinguish open-new-or-existing-buffer-for-new-or-existing-file from Open File (existing file only). A better name for New would be just "Open". Open File is technically "open existing file", but "Open File" is adequate for this action, and it fits with Open Directory and Insert File - explicit mention of "File" suggests an existing file here. 4. A better name for Revert is Reopen. Just as Paste is preferable to Yank in a menu, so is Reopen preferable to Revert: more users will understand it immediately. 5. Move all of the window and frame stuff to a new menu, "Frames". This menu is analogous to the "Buffers" menu. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: debug-on-entry question
> However, that would only help with uses of `call-interactively', not > uses of `interactive' itself. I don't understand what you mean. `interactive' is just a specification. `call-interactively' interprets it. Sorry; I see that now. I didn't realize it when I wrote that. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: File menu changes (suggestions)
We refer to the buffer on purpose: we want users to see Emacs terminology even in the menus, and even when the menus are following established UI guidelines and use standard entries like "New" and "Close". Why then do we use Paste instead of Yank? Menu-item names can serve as a bridge between terms that newbies are used to and Emacs terminology. Users can find operations they are familiar with in the menus, and gradually learn the associated commands, which can have very different names. It doesn't help if we use common terminology in uncommon ways - see "New" below. > a. Currently, there is an inconsistency wrt "Buffer" and "(current buffer)". That's not an inconsistency: in the first case, "Buffer" is part of the command name; in the second, it's a minor comment about the command's operation. 1. "Save Buffer As" runs command `write-file'. Where's the beef - er - "buffer"? 2. "Save (current buffer)" runs command `save-buffer'. 3. "Close (current buffer)" runs command `kill-this-buffer'. 4. "Revert Buffer" runs command `revert-buffer'. - 1,2 & 3 seem opposite of the convention you say is behind the names. 4 confirms your rule, as do the "* Print Buffer" items. Not much of a rule (explanation). - The command name is irrelevant here. Again: `yank'. - A minor comment about a command's operation belongs perhaps in a tooltip or help, but not in the name of the menu item itself. > New is better than New File (but see 3, below). No, it is not better, since it doesn't say what new entity is created. Other GUI programs have a submenu there or work only with one type of entities (or just leave it vague, which we didn't want to do). So "New File" says that a new file is created? Yes, it says that, but it tells not the truth: no file is created by this operation. > 3. WRT 2b, it is true that the file or buffer opened need not in fact be > new, so even "New" is misleading. The problem arises because we need a name > to distinguish open-new-or-existing-buffer-for-new-or-existing-file from > Open File (existing file only). A better name for New would be just "Open". "New" is a standard entry in the "File" menu, so I don't think renaming it to (a non-standard) "Open" is a good idea. The name "New" is standard, but our meaning/use of that name is not so standard. "New" in many (most?) applications (e.g. Word and Windows Explorer are common ones) will not let you open an existing document. Our "Open" can do two things: 1) create new, 2) open existing. However, "Open Directory" does not create a new directory. That too is a place where we might consider either renaming the item or extending command `dired' to incorporate the behavior of `dired-create-directory'. > 4. A better name for Revert is Reopen. Do you know of any other GUI applications that have such a menu entry? I have seen "Revert to Saved", which is also clearer than "Revert" (and "Revert Buffer"). My knowledge is limited - you might be right; "Reopen" seems clearer to me, though. "Reload", which David mentioned, is also clearer (though it also suggests Columbine or Grand Theft Auto). Web browsers often use "Refresh" (in the View menu) for reloading a page (although the "reloading" often uses the cache, by default). > 5. Move all of the window and frame stuff to a new menu, "Frames". Not good: we have a crammed menu bar already, adding more top-level items would only make things worse with no real advantage. Agreed. But 1) this stuff has little to do with "File"; 2) use of a "Windows" menu, having a similar purpose, is common in other apps; 3) I think it is likely that we will have more frame and window commands to add to a Frames menu in the future. Again, I didn't expect that much of what I threw out would be agreed upon, especially in the immediate. I do think we might agree to rename a few of the items for this release. I'm thinking, for instance, of "Unsplit Windows". Another possible renaming I forgot to mention is "Split Window". The window is not split to result in a single window with a divider. "New Window" would be a better name for this menu item. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: link appearance and soft face properties
When you use emphasis and bold, you are speaking about two different kinds of markup, logical and physical. Right. I wrote about the separation of "purpose/intention/use from physical formatting", which was my way of characterizing logical vs physical or, as someone else pointed out, semantic vs presentational. But I also mentioned "user-changeable" vs "hard-wired". Admittedly, these are not identical distinctions. However, in this context, I think they are usefully combined: The ":underline" text property is a hard-wired, physical formatting spec. The ":link" text property I was proposing is a user-changeable, logical spec. :link is user-changeable: users can determine what the ultimate appearance is. :link is logical: it represents a purpose/intention/use that is more abstract than that of underlining. What makes it more abstract? The fact that there can be different (physical) manifestations/implementations (regardless of whether or not users can define those physical realizations). So, I don't think it was a distraction to speak of "soft" in this context as combining user-changeable and logical. It's true that "logical" markup can refer simply to markup with different physical manifestations and letting users choose the manifestation by choosing the context, without necessarily letting them choose or define the physical form beyond that. (I won't get into the name vs named distinction that you brought up; I think it adds more heat than light here. Sorry if I wasn't clear, though.) Anyway, as people have pointed out, it appears that face inheritance, not text-property inheritance would be sufficient to realize what I was suggesting. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: link appearance and soft face properties
> Providing a link face (that inherits etc.) and using it for all > links (i.e. places where the code in fact "follows a link" upon > click) would let users customize, in a single place, how links > appear. (If we provided buffer-local faces, users would also be > able to easily customize link appearance on a per-buffer basis.) I can't imagine other useful face attributes for the `link' face than underline. For example, changing its foreground color will make different faces inheriting from it indistinguishable (like visited and unvisited links in Info, or file names and line numbers in grep and compilation). So I see the `link' face mainly as a way to turn link underlining off. But then it should be possible to do that on a per-buffer basis to turn underlining off in some modes (e.g. in grep and compilation) but leaving it in others (e.g. in Info). Turning underlining on/off is certainly one application of this. There is also the choice of whether links should use a special face (e.g. underlining, or blue text) or a special mouse-face or both. WRT the face property, this means whether or not links should be discernable without moving the mouse over them. Emacs has used different ways to represent links in the past, I believe. Links in Info are now underlined and blue, and a mouseover removes the underlining and the blue foreground and makes the background green (by default). Links in Dired use the same mouseover highlighting, but do not use any highlighting for the face property. And so on. The feature I was proposing would let Emacs developers and Emacs users: 1) Define the global (default) appearance of links (both face and mouse-face properties) in a single place. 2) Define the local appearance of links on a per-buffer (e.g. per mode) basis. And the same idea would apply to buttons and other user-interface objects that use faces. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: File menu changes (suggestions)
We are miscommunicating: I didn't mean the name of the Lisp function, I meant the command name that appears in the menu. > - The command name is irrelevant here. I disagree. Obviously, if I thought you were speaking of the Lisp command name, then that is what I meant was irrelevant here. And the menu command name is obviously relevant to the menu command name (!). And the rest of the line you quote read "Again: `yank'.", making it even clearer that I meant that the Lisp command name was irrelevant to the menu command name. Is that what you disagree with? > > 5. Move all of the window and frame stuff to a new > >menu, "Frames". > > Not good: we have a crammed menu bar already, adding more > top-level > items would only make things worse with no real advantage. > > Agreed. But 1) this stuff has little to do with "File"; 2) use of a > "Windows" menu, having a similar purpose, is common in other apps; Richard didn't want that, since in Emacs, `window' means something different. I proposed "Frames", not "Windows" - see just above. I simply mentioned that a menu (called "Windows") with a similar purpose is a common occurrence. > Another possible renaming I forgot to mention is "Split Window". The window > is not split to result in a single window with a divider. "New Window" would > be a better name for this menu item. I think other applications use the same name. Perhaps just "Split" would be better, I don't know. Verbs without objects in the File menu should, by default, refer to the default object for that menu, which is the current file/buffer. "Split" by itself would not suggest that a new window was to be created. It might suggest that the current file/buffer would be split, but that is not what happens. What's wrong with "New Window" for the menu command to create a new window? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Bug in y-or-n-p?
1. Define these: (defun foo () (y-or-n-p "foo? ")) (defun bar () (y-or-n-p "bar? ")) (setq kill-emacs-query-functions '(foo bar)) 2. Use the menu-bar File > Exit Emacs. The question "foo? " correctly appears in a popup menu y/n. 3. Respond `n' to "foo? ". 4. The question "bar? " should be asked via a popup menu also, but it appears instead in the minibuffer. No, the question bar should not be asked at all if you answere `n' to foo, and in today's CVS it is not asked, at least not on GNU/Linux. If you answer `y' to foo, then bar should be asked via a popup menu, and it is, in today's CVS, at least on GNU/Linux. There is no bug. >From the kill-emacs-query-functions docstring: Functions to call with no arguments to query about killing Emacs. If any of these functions returns nil, killing Emacs is cancelled. In other words, once you answer `n' to any question, the other questions are not asked. The fact that bar was asked for Drew could have been a temporary bug In CVS which would appear to be fixed now. Unless it is operating system specific, or a local problem with Drew's setup. I'm sorry, I meant this for foo: (defun foo () (y-or-n-p "foo? ") t) ; always return `t' I'm using this version of Emacs: 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)' ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Bug in y-or-n-p?
(defun foo () (y-or-n-p "foo? ") t) ; always return `t' After that, and following the rest of your recipe, bar gets asked via a popup menu, in today's CVS, on GNU/Linux. Great, then it's fixed. Thanks. In my (April 2005) version, foo gets asked via popup menu, but bar gets asked via the minibuffer. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Bug in y-or-n-p?
> Great, then it's fixed. Thanks. > > In my (April 2005) version, foo gets asked via popup menu, > but bar gets asked via the minibuffer. I don't think it is fixed. You were testing on Windows, weren't you? I see the same problem with MinGW and MSVC on today's CVS. Yes, I'm on Windows. Thanks for checking the bug. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: debug-on-entry question
The problem is in changing [the behavior of] existing code letters. Emacs allows customization of almost everything down to redefining built-in core functions, but disallows customization of default methods for reading input arguments. This is an artificial restriction contradicting the principles of Emacs customization. I agree. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces
The Elisp Info on Lisp Data Types is presented near the beginning of the manual, as it is important, basic information. Reading this info, I see no mention of `face'; `face' is not a datatype. A face is (`type-of') either a symbol or a vector. Fair enough; some of the "kinds of things", such as `face', that we reference casually are not themselves datatypes. But I wonder if perhaps something about this shouldn't be mentioned in the Info section on datatypes - perhaps mentioning `face' as an example of something you might in some ways be inclined to think of as a datatype but that Emacs treats differently from a type. Point out, in particular, that not everything that has what might look like a type predicate is a datatype - e.g. `facep'. Readers can get the impression when reading the section on datatypes that it covers all of the standard "things" we manipulate in Emacs Lisp. Looking at the list of type predicates, a reader would never guess that faces even exist, yet they are important things that we manipulate everyday. There is no `face' type, but there are faces. It might help to add a short explanation of this, including mention of predicates like `facep' that look like, but are not really, type predicates. What I'm suggesting is: 1) Mention that we sometimes speak casually of some things as if they were of a particular abstract type, when there is no such type. Make readers aware that when we speak of some things, like `buffer' and `function', there are corresponding datatypes, and when we speak of other things, like `face', there is no corresponding (`face') datatype. This is not obvious, and it's not obvious which things, like `function', correspond to a datatype and which, like `face', do not - there is nothing in the predicate names `functionp' and `facep' that provides a clue. (And functions, like faces, come in more than one form. It's not obvious why `function' is considered an abstract datatype with representations as diverse as lambda expression, keystroke command, and primitive, yet symbol and vector are not considered the representations of an abstract `face' datatype.) 2) Cross-reference the discussions of some of the important "non-types", such as `face'. A reader of the datatypes section and the list of type predicates would be helped by being made aware that there are also other (non-primitive) kinds of things that we manipulate, and the reader should be able to link to the doc of such important things as faces. Obviously, there is no limit to the "kinds of things" that can exist that have no corresponding datatype of the same name. The point is just to mention that 1) such things can exist, and 2) `face', in particular, is one (and cross-reference the face doc). Finally, I'm ignorant: Just why is `face' not treated similarly to `function' - why isn't `face' a datatype? If the answer expresses a general rule, then perhaps that rule should also be included in the doc, to clarify things. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
custom-face-attributes has no doc string
`custom-face-attributes' has no doc string. However, it is hardly something internal. It is explicitly mentioned in (elisp) Info node Defining Faces: The element's second element, ATTS, is a list of face attributes and their values; it specifies what the face should look like on that kind of terminal. The possible attributes are defined in the value of `custom-face-attributes'. Shouldn't `custom-face-attributes' have a doc string explaining its structure and purpose? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces
while i agree that the documentation could make more distinction between fundamental and composed (or "defined-by-conventional-use") types, i figure that doing so might be a bad idea because it would constrain the implementation. since `facep' works like `functionp' (fsvo "like"), that should be what programmers rely on. if in the future faces become fundamental, that transition will be easier to handle if prior internals were left unexposed (ignorance is bliss). One of my concerns is that readers of the datatypes section will not know that faces exist. This section is near the beginning of the manual, and it can give the impression that it also presents all of the important Emacs-Lisp objects. At a minimum, I think it would help to mention that, although these are the only datatypes, there are additional things of interest (like faces) that are not listed here. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: datatypes in Elisp Info: mention "things" for which there is no"thing" datatype - e.g. faces
But I wonder if perhaps something about this shouldn't be mentioned in the Info section on datatypes - perhaps mentioning `face' as an example of something you might in some ways be inclined to think of as a datatype but that Emacs treats differently from a type. Adding a brief section about faces in that chapter is a good idea. I don't have time to work on it, but if someone else writes it, we could install it. 2) Cross-reference the discussions of some of the important "non-types", such as `face'. My memory doesn't recall any others, but I wouldn't want to rely on it. What others do you know of? I didn't have any others in mind. I just wanted to speak about this generally, in case there were others. (Kenichi Handa mentions coding-system, charset, fontset.) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces
> Finally, I'm ignorant: Just why is `face' not treated similarly to > `function' - why isn't `face' a datatype? If the answer > expresses a general > rule, then perhaps that rule should also be included in the > doc, to clarify things. I tend to think of datatypes in lisp as being... Whatever people decide on this should be reflected in the Elisp manual (i.e. it should be updated). Currently, I'm not sure that your POV is reflected there. There are two places where the `function' datatype is discussed, which are linked: 1) Lisp Data Types and 2) Functions, linked through `functionp' at Type Predicates. It's not clear whether the entire discussion at Functions applies to the `function' datatype. In general, perhaps we should be clearer when we are speaking of an "official" datatype and when we are speaking rather more loosely. If Elisp "datatype" does not reflect something objective and operational (e.g. determinable by program), then perhaps we shouldn't speak of "datatype" at all. IOW, perhaps we should either make it clear what constitutes an Elisp datatype, and which "kinds of things" are datatypes, or not speak of Elisp datatypes at all. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Q on Text Properties popup menu - shouldn't it use the pointer position, not the cursor position?
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. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Q on Text Properties popup menu - shouldn't it use the pointerposition, not the cursor position?
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: " 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)' ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Q on Text Properties popup menu - shouldn't it use the pointerposition, not the cursor position?
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". ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Q on NaN
I said this: (condition-case nil (setq foo (/ 0.0 0.0)) (arith-error nil)) In older versions of Emacs (at least prior to April 2005 CVS), this would evaluate to nil. Now, it evaluates to -0.0NaN. I can modify the code like so: (and (condition-case nil (setq foo (/ 0.0 0.0)) (arith-error nil)) (bar foo)) ; foo must be a number, not a NaN What function do I use for bar? `numberp' doesn't work, since (numberp -0.0NaN) is non-nil. To make the point simpler: (numberp (/0.0 0.0)) returns t. That seems like a bug to me. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Q on NaN
Consider this: (condition-case nil (setq foo (/ 0.0 0.0)) (arith-error nil)) In older versions of Emacs (at least prior to April 2005 CVS), this would evaluate to nil. Now, it evaluates to -0.0NaN (on Windows, at least), which breaks the encompassing code (which tests the above expression for non-nil). Fair enough. I can modify the code like so: (and (condition-case nil (setq foo (/ 0.0 0.0)) (arith-error nil)) (bar foo)) ; foo must be a number, not a NaN What function do I use for bar? `numberp' doesn't work, since (numberp -0.0NaN) is non-nil. That seems odd to me, since NaN means "not a number" and numberp means "a number", but I guess I can live with a little oddness. In the Elisp manual, I didn't find a predicate to test for NaN. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Q on NaN
Still following up on my own post: (condition-case nil (setq foo (/ 0.0 0.0)) (arith-error nil)) In older versions of Emacs (at least prior to April 2005 CVS), this would evaluate to nil. Now, it evaluates to -0.0NaN. I can modify the code like so: (and (condition-case nil (setq foo (/ 0.0 0.0)) (arith-error nil)) (bar foo)) ; foo must be a number, not a NaN What function do I use for bar? `numberp' doesn't work, since (numberp -0.0NaN) is non-nil. To make the point simpler: (numberp (/0.0 0.0)) returns t. That seems like a bug to me. If this is not considered a bug, and `numberp' should return non-nil for NaN, as it currently does, then what are all the possible NaN values to test? The Elisp manual mentions that the read syntax for (/ 0.0 0.0) is 0.0e+NaN. On my system it is in fact -0.0e+NaN. Are there additional NaN values, or would this be a sufficient test for NaN-ness, to replace `numberp': (let ((foo (/0.0 0.0))) (and (not (equal -0.0e+NaN foo)) (not (equal 0.0e+NaN foo (Note that (= -0.0e+NaN foo) returns nil, while (equal -0.0e+NaN foo) returns `t'.) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Q on NaN
> (numberp (/0.0 0.0)) returns t. That seems like a bug to me. Maybe it is, maybe it isn't. (elisp)Arithmetic Operations says: If you divide an integer by 0, an `arith-error' error is signaled. (*Note Errors::.) Floating point division by zero returns either infinity or a NaN if your machine supports IEEE floating point; otherwise, it signals an `arith-error' error. So if the machine supports IEEE floating point (most modern machines do), you aren't supposed to get `arith-error' in this case. Maybe this is a bit counter-intuitive for someone who never did futz with NaNs, but at least Emacs behaves consistently with the docs. I didn't say above that (/0.0 0.0) should give `arith-error'. I suggested that perhaps `numberp' should return nil for a NaN argument, since "NaN" means "not a number" and "numberp" means "a number". NaN is a floating-point value, but is it a number? As for a way to test for a NaN, try this: (= (/ 0.0 0.0) (/ 0.0 0.0)) It should evaluate to nil, since a NaN is defined to fail _any_ arithmetic comparison, even a comparison to itself. That doesn't tell me how to test if `foobar' is a NaN. See my previous email: I knew I could test `(equal foo 0.0e+Nan)', but I thought I would need to test against all of the possible NaN values. A bit of experimenting shows, however, that, at least on my system, the mantissa doesn't matter: (equal 0.0e+NaN -0.0e+NaN) is `t', as is (equal 1.0e+NaN -99.5e+NaN). There is effectively only a single NaN value. So I guess the answer to my original question is this: (and (condition-case nil (setq foo (/ 0.0 0.0)) (arith-error nil)) (not (equal 0.0e+NaN foo))) Ugly, perhaps, but usable. BTW, here is something I didn't expect: `M-: 0.0e+NaN' returns -0.0e+NaN `M-: -0.0e+NaN' returns 0.0e+NaN The reader seems to flip the (irrelevant) sign. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: Q on NaN
> I didn't say above that (/0.0 0.0) should give `arith-error'. Well, you seemed to: you complained that it did so in previous versions. No, I said "fair enough" to that change in behavior. I did not suggest it was a bug. My question was about numberp's behavior: > I suggested that perhaps `numberp' should return nil for > a NaN argument, since "NaN" > means "not a number" and "numberp" means "a number". > NaN is a floating-point value, but is it a number? Any floating-point value is a ``number'' as far as `numberp' is concerned. The fact that NaN is a short for not-a-number does not mean that Lisp should treat it like that. I can see that from the behavior, but then perhaps it should be mentioned explicitly in the doc. Since the names suggest something different, perhaps a note of clarification should be added. > As for a way to test for a NaN, try this: >(= (/ 0.0 0.0) (/ 0.0 0.0)) > It should evaluate to nil, since a NaN is defined to fail _any_ > arithmetic comparison, even a comparison to itself. > > That doesn't tell me how to test if `foobar' is a NaN. Exactly the same: (= foobar foobar). (Did you try that?) Right. Got it; thanks. A couple of people replied with the same solution. I am using (equal 0.0e+Nan), which also seems to work (and if equivalent, would perhaps be clearer, since it mentions NaN: anything equal to NaN is NaN). Does anyone know that these are not equivalent: (equal 0.0e+NaN) <=?=> (and (numberp x) (/= x x)) That is, are there any objects equal to 0.0e+NaN that are not NaN? It might also be useful to mention such an idiom - either expression - in the doc, or else to provide a predicate. > See my previous email: I knew I could test > `(equal foo 0.0e+Nan)', but I thought I would > need to test against all of the possible NaN values. No need: the arithmetic equality trick takes care of all of the possible values. Right. All NaNs are `equal', but they are not `=', even to themselves. Note that you should use `=', not `equal' (nor `eql', btw). Yes, for testing a numberp to see if it is not NaN. However, I am testing an arbitrary object. For that, (and (numberp x) (/= x x)) works and (equal x 0.0e+Nan) works. For the latter test, it must be `equal' or `eql', not `=' or `eq'. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
