Re: make `occur' use word at point as default
But I think it would be more convenient to [use M-n to] access [additional default values] from the list [of default values]. Yes, that's what I had in mind. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
NEXT could conceivably be used to access another default. It's a good idea to reserve [next] for a complementary use with [prior] - that's a natural pair, and such pairs are relatively scarce. What's more, their names are perfect for forward-backward operations that do what they say. FWIW, I use [insert], instead of [prior], in the minibuffer for `switch-to-completions'. And I use [insert] in *Completions* to switch back to the minibuffer. Semi-lame mnemonic: insert cursor But I think it would be more convenient to [use M-n to] add [additional default values] to the list for [M-p] to access. It should be the user's acceptance (via RET) of an input candidate that puts an input onto the history list (for use by M-p) - it shouldn't be the mere act of Emacs making an input candidate available or the user's looking at a candidate via M-n. (I think that's already the case - just wanted to emphasize it.) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
But I think it would be more convenient to [use M-n to] add [additional default values] to the list for [M-p] to access. We seem to be miscommunicating; your additions turn this into something very different from what I was talking about. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
But I think it would be more convenient to [use M-n to] add [additional default values] to the list for [M-p] to access. We seem to be miscommunicating; your additions turn this into something very different from what I was talking about. Sorry; I tried. Could you please rephrase what you meant? We're getting lost in the translations. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
But I think it would be more convenient to [use M-n to] add [additional default values] to the list for [M-p] to access. We seem to be miscommunicating; your additions turn this into something very different from what I was talking about. Drew's response to your message seems right, but his reconstruction of your message is not. Could you confirm that you really meant this: But I think it would be more convenient to [use M-n to] access [additional default values] from the list [of default values]. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
Hi Drew, Drew Adams writes: I should have added that I doubt that such up and down cursor motions are very useful in the minibuffer. I regularly edit multi-line text in the minibuffer when I use replace-string and eval-expression. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
NEXT could conceivably be used to access another default. But I think it would be more convenient to add it to the list for C-p to access. I don't understand the last sentence. Do you mean add the [next] key to some list? What list? Do you mean C-p or M-p? Sorry, I don't follow you here. I meant M-p. Sorry. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
Why? There is currently a good deal of redundancy in the bindings for `next-history-element' and `previous-history-element'. These minibuffer history-list commands are bound to *FOUR PAIRS* of keys: (1) arrows [up] / [down], (2) C-n / C-p, (3) M-n / M-p, and (4) [next] / [prior]. (Well, actually, [prior] is then rebound to `switch-to-completions'.) C-n and C-p do not run these commands; they do the usual cursor motion. NEXT could conceivably be used to access another default. But I think it would be more convenient to add it to the list for C-p to access. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
There is currently a good deal of redundancy in the bindings for `next-history-element' and `previous-history-element'. These minibuffer history-list commands are bound to *FOUR PAIRS* of keys: (1) arrows [up] / [down], (2) C-n / C-p, (3) M-n / M-p, and (4) [next] / [prior]. (Well, actually, [prior] is then rebound to `switch-to-completions'.) C-n and C-p do not run these commands; they do the usual cursor motion. You're right. My bad. NEXT could conceivably be used to access another default. But I think it would be more convenient to add it to the list for C-p to access. I don't understand the last sentence. Do you mean add the [next] key to some list? What list? Do you mean C-p or M-p? Sorry, I don't follow you here. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
C-n and C-p ... do the usual cursor motion [in the minibuffer] I replied: You're right. My bad. I should have added that I doubt that such up and down cursor motions are very useful in the minibuffer. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
1. word at point - (current-word t) 2. tag at point - (funcall (or find-tag-default-function (get major-mode 'find-tag-default-function) 'find-tag-default)) These are pretty much the same. More specifically the tag should include the current-word as a substring, so I'd drop the number 1 and just keep number 2. 3. active region - (and transient-mark-mode mark-active (buffer-substring-no-properties (region-beginning) (region-end))) You could have done M-w before the current operation. Much simpler/quicker than doing M-n M-n M-n searching for it. 4. last isearch regexp - (car regexp-search-ring) This one makes sense. Maybe we could simply use the same ring for occur as for regexp-search so that it is available as M-p. 5. last kill from the kill ring - (current-kill 0) C-y brings it more quickl;y and reliably than M-n M-n M-n M-n. I.e. there are really only 2 different useful values and we could make one of the two available via M-p. Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
M-n and M-p are for the history list. M-n already pulls the default value into the minibuffer and adds it (possibly edited) to the history list. This is enough connection between the two. In this case, you seem to want the default value to be the _previous_ history value (so that empty input searches the same thing again). Yes, that's what the default is now. This means that M-n, M-p, and empty input will all do more or less the same thing: use the last (i.e. previous) history value. Each of them follows a convention. In this case, all three conventions converge. However, you might consider giving access to a list of default values (more than just 1 or 2) via _different_ keys from M-n and M-p - the arrow keys, for instance. Finding other keys would be difficult. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
However, you might consider giving access to a list of default values (more than just 1 or 2) via _different_ keys from M-n and M-p - the arrow keys, for instance. Finding other keys would be difficult. Why? There is currently a good deal of redundancy in the bindings for `next-history-element' and `previous-history-element'. These minibuffer history-list commands are bound to *FOUR PAIRS* of keys: (1) arrows [up] / [down], (2) C-n / C-p, (3) M-n / M-p, and (4) [next] / [prior]. (Well, actually, [prior] is then rebound to `switch-to-completions'.) [Not to mention M-r, and M-s, which also provide access to previous minibuffer input (and ESC ESC C-x, which provides access to previously executed commands).] Could none of those history-list bindings be sacrificed for accessing default values (such as those Juri Stefan have mentioned, and/or the values in `minibuffer-completion-table')? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
1. word at point - (current-word t) 2. tag at point - (funcall (or find-tag-default-function (get major-mode 'find-tag-default-function) 'find-tag-default)) These are pretty much the same. More specifically the tag should include the current-word as a substring, so I'd drop the number 1 and just keep number 2. I agree. 3. active region - (and transient-mark-mode mark-active (buffer-substring-no-properties (region-beginning) (region-end))) You could have done M-w before the current operation. Much simpler/quicker than doing M-n M-n M-n searching for it. 5. last kill from the kill ring - (current-kill 0) C-y brings it more quickl;y and reliably than M-n M-n M-n M-n. Doing M-w/C-y is simpler only for strings that don't contain special regexp characters. But in regexps they need to be quoted. `M-n M-n ...' could provide a default value with quoted special regexp characters. 4. last isearch regexp - (car regexp-search-ring) This one makes sense. Maybe we could simply use the same ring for occur as for regexp-search so that it is available as M-p. There is also another command that reads a regexp and that could share the same regexp ring - `query-replace'. It has a special variable `query-replace-from-history-variable' that defines the history list to use. So `occur' and `isearch' could have similar variables to allow occur/multi-occur/keep-lines/flush-lines/how-many and isearch-regexp to use the same ring with either: (setq regexp-history-variable 'regexp-history) (setq regexp-search-ring-variable 'regexp-history) or: (setq regexp-history-variable 'regexp-search-ring) (setq regexp-search-ring-variable 'regexp-search-ring) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
Could none of those history-list bindings be sacrificed for accessing default values (such as those Juri Stefan have mentioned, and/or the values in `minibuffer-completion-table')? There are two different issues here: accessing the completion values, and accessing the default values supplied explicitly via the `default' argument of the minibuffer reading functions. So please make this distinction when discussing them. These are two different sets of values (though, one is a subset of another). 1. a list of all possible completions. There are many packages that provide key bindings for accessing next/previous completion items. AFAIK, most popular key pairs are [left]/[right], C-s/C-r, TAB/M-TAB. You seem to be advocating for unified key bindings for these packages. 2. a list of default values. The most natural key to access a list of default values is M-n. It could work like M-p for a list of history values, but in the opposite direction. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
Could none of those history-list bindings be sacrificed for accessing default values (such as those Juri Stefan have mentioned, and/or the values in `minibuffer-completion-table')? There are two different issues here: accessing the completion values, and accessing the default values supplied explicitly via the `default' argument of the minibuffer reading functions. So please make this distinction when discussing them. These are two different sets of values (though, one is a subset of another). 1. a list of all possible completions. 2. a list of default values. Yes, there is a difference. That's partly what I meant to indicate by using quotes around default and separating this from the list of completions with and/or - but the difference is clearer as you express it - thanks. You distinguish the two in terms of their meaning: default value vs a value that completes an input (i.e. works via completion). These can be different, a priori. You also distinguish them operationally: one is accessed via the default-value argument to completing-read, the other via the obarray argument (minibuffer-completion-table). These two distinctions are not the same, so let's distinguish them, too ;-). The second distinction more or less assumes what we are debating (_how_ users are to access default values). You assume that default values are to be treated as the default-value arg to completing-read. And, besides begging the question, your second distinction is a bit premature: until now, the default-value arg to completing-read has in fact been a single value, not a list of values. So, I'll concentrate on the first distinction: default values vs completions. Given the fact that default value does not necessarily imply completion, and vice versa, we can nevertheless _choose_ to consider accessing the two in the same way - that is, to equate them _operationally_ (i.e., in terms of use). They are all, in principle, reasonable input values to expect the user to choose. IOW, having gone through the exercise of distinguishing their meanings logically, we can still choose to treat default value and completion the same way (giving them the same meaning, some might argue!). Let's assume that the minibuffer-completion-table passed to completing-read etc. is intelligently tailored to be a set of values the user would likely choose. That's not always the case today (the unfocussed obarray is often passed), but there is nothing standing in the way of programmers passing a well-chosen minibuffer-completion-table that is truly helpful in some particular context. Not to mention also passing a useful minibuffer-completion-predicate. In some cases, this sequence of completions could perhaps be sorted in some special way, in terms of likelihood of use, for instance. That might provide additional help to the user. In front of these completion values we might place some even-more-intelligently-crafted choices - the kinds of choices that you and Stefan suggested, perhaps. That is, there is nothing preventing us from tacking on super-smart choices to the front of a list of less brilliant choices. This is just another way of ordering the list. This gives us a sequence of possible choices, perhaps ordered in some smart way. I suggest that there is no reason not to make each of these choices available also as a _completion_ - that is, to let users complete input to obtain it. This is the main reason for bringing together the two lists you distinguished above. Then, the list of completions and the list of possible default values would be the same: each default value would be a completion target, and each completion would be a possible default value. If we did that, then the original question would remain, _how to access_ the values in this list? Completion would be one way now, thanks to unifying the two lists. Cycling via one or two keys could be another way. I suggested reusing one of the 4 redundant pairs currently dedicated to the history lists - the up/down arrows, for instance. You mentioned that some external libraries cycle completions using left/right, C-s/C-r etc. Whatever - in any case, I don't see a _scarcity_ of such pairs, as Richard suggested. An alternative, which you suggest, is to use M-n for this cycling (though you propose it only for the default-value list, which you separate from the completions list): The most natural key to access a list of default values is M-n. It could work like M-p for a list of history values, but in the opposite direction. To me, that's less desirable/natural, as it confuses the history list (which can already be navigated in both directions) with the default-value list. I personally would prefer to keep the two critters separate, operationally. However, you're right that M-n accesses the future here (possible inputs), while M-p (and M-n, up to the last input!) accesses past inputs, so that is also a perfectly _workable_ scheme.
Re: make `occur' use word at point as default
But the problem remains: too often I have to first mark a word or symbol, copy the region, start a command (`grep', `occur', `query-replace', whatever), paste it, press enter. That's three keystrokes too many. How about making the thing at point be accessible via M-n? By convention, M-n is supposed to insert _the default_. I do not want to make exceptions to that. We could conceivably make a second M-n insert another possible input that one might want. In effect, this would mean putting another element at the front of the history list. That could be a new convention that could be generalized to other things. Now is not the time to implement this, but I'm interested in hearing if there are any objections to the idea. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
But the problem remains: too often I have to first mark a word or symbol, copy the region, start a command (`grep', `occur', `query-replace', whatever), paste it, press enter. That's three keystrokes too many. How about making the thing at point be accessible via M-n? By convention, M-n is supposed to insert _the default_. I do not want to make exceptions to that. We could conceivably make a second M-n insert another possible input that one might want. In effect, this would mean putting another element at the front of the history list. That could be a new convention that could be generalized to other things. Now is not the time to implement this, but I'm interested in hearing if there are any objections to the idea. My opinion: Keep the history list (and ways of accessing it) separate from the default value (and ways of accessing it). M-n and M-p are for the history list. M-n already pulls the default value into the minibuffer and adds it (possibly edited) to the history list. This is enough connection between the two. In this case, you seem to want the default value to be the _previous_ history value (so that empty input searches the same thing again). This means that M-n, M-p, and empty input will all do more or less the same thing: use the last (i.e. previous) history value. That's a lot of convenience for accessing that one value, but it leaves no easy way to use the word/symbol at point - which several people have mentioned is an obvious thing to want to do with `occur'. For `occur', I would use the word/symbol at point as the default value, and let people use `M-p RET' to get the last history value. Consistent, and not terribly inconvenient, IMO (one extra keystroke: M-p). Wrt your general proposal - Given that you don't want the default value to be automatically inserted into the minibuffer (my preference), you should stick with M-n to insert it. I think extending this to a second M-n, for a possible second default value would be confusing, with little reward. However, you might consider giving access to a list of default values (more than just 1 or 2) via _different_ keys from M-n and M-p - the arrow keys, for instance. A reasonable (default) set of default-value candidates would be those in `minibuffer-completion-table' (perhaps as filtered by `minibuffer-completion-predicate'). This is what several existing libraries do, including my icicles library. You might look to such libraries for ideas on possibilities (food for thought). The icicles code is here: http://www.emacswiki.org/cgi-bin/emacs/icicles.el. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
We could conceivably make a second M-n insert another possible input that one might want. In effect, this would mean putting another element at the front of the history list. That could be a new convention that could be generalized to other things. This is already implemented by a small 9-line patch I proposed in http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg01755.html It allows M-n in the minibuffer to insert input from the list of default values. Each consecutive M-n inserts a new default value from the list. For `grep' and `occur' there are at least five useful default values: 1. word at point - (current-word t) 2. tag at point - (funcall (or find-tag-default-function (get major-mode 'find-tag-default-function) 'find-tag-default)) 3. active region - (and transient-mark-mode mark-active (buffer-substring-no-properties (region-beginning) (region-end))) 4. last isearch regexp - (car regexp-search-ring) 5. last kill from the kill ring - (current-kill 0) With this patch, it is possible to make a list of all these default values accessible in the minibuffer via M-n. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
Emilio Lopes [EMAIL PROTECTED] writes: I think something like isearch's C-w and friends extended to other commands which read from the minibuffer would be useful. I would like that. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
Emilio Lopes [EMAIL PROTECTED] writes: But the problem remains: too often I have to first mark a word or symbol, copy the region, start a command (`grep', `occur', `query-replace', whatever), paste it, press enter. That's three keystrokes too many. How about making the thing at point be accessible via M-n? Kai ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
The command `occur' currently uses the last item in the regexp history as the default value. Please do not change that. Peopel are accustomed to just typing RET to search for the same thing again. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
Richard M Stallman writes: The command `occur' currently uses the last item in the regexp history as the default value. Please do not change that. Peopel are accustomed to just typing RET to search for the same thing again. That's a good point. But the problem remains: too often I have to first mark a word or symbol, copy the region, start a command (`grep', `occur', `query-replace', whatever), paste it, press enter. That's three keystrokes too many. How do other people accomplish this? I think something like isearch's C-w and friends extended to other commands which read from the minibuffer would be useful. Opinions? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
The command `occur' currently uses the last item in the regexp history as the default value. Please do not change that. Peopel are accustomed to just typing RET to search for the same thing again. That's a good point. But the problem remains: too often I have to first mark a word or symbol, copy the region, start a command..., paste it, press enter. That's three keystrokes too many. How do other people accomplish this? I think something like isearch's C-w and friends extended to other commands which read from the minibuffer would be useful. Opinions? FWIW (since you asked), here is my (singleton, heretical) opinion (again): 1. I prefer to access previous values (search for the same thing again) via the history list - only. That's not what the default value is for, IMO. I agree with Emilio that the default value in the `occur' case should reflect the current word/symbol, not the last-used value. It's not hard to hit `M-p' to search again. 2. I prefer to have the default value placed in the minibuffer automatically, as input - that is, as INIT-VALUE. Yes, that means that I must empty the minibuffer (one keystroke), if the default value is not something I want to use. More often than not, however, I do use it, perhaps modifying it first. 3. I also cycle among the other `completing-read' default values, using the arrow keys, treating them the same way as the default value (possibly editing, re-completing, etc.). I use a library that lets me cycle, match, and complete such values either by prefix (normal completion) or by regexp. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
Drew Adams [EMAIL PROTECTED] writes: FWIW (since you asked), here is my (singleton, heretical) opinion (again): 1. I prefer to access previous values (search for the same thing again) via the history list - only. That's not what the default value is for, IMO. I agree with Emilio that the default value in the `occur' case should reflect the current word/symbol, not the last-used value. It's not hard to hit `M-p' to search again. I find that occur should probably heed an active transient region (quoting its contents), but I don't think it a good idea to use stuff from the buffer in other cases. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
make `occur' use word at point as default
The command `occur' currently uses the last item in the regexp history as the default value. I think it would be more useful to offer the word at point (if any) as default, since the previous history item can be easily fetched with M-p. 2005-08-28 Emilio C. Lopes [EMAIL PROTECTED] * replace.el (occur-read-primary-args): use word at point as default. diff -rN -c old-emacs-darcs.eclig/lisp/replace.el new-emacs-darcs.eclig/lisp/replace.el *** old-emacs-darcs.eclig/lisp/replace.el Sun Aug 28 14:30:13 2005 --- new-emacs-darcs.eclig/lisp/replace.el Sun Aug 28 13:37:51 2005 *** *** 903,909 (nreverse result (defun occur-read-primary-args () ! (list (let* ((default (car regexp-history)) (input (read-from-minibuffer (if default --- 903,909 (nreverse result (defun occur-read-primary-args () ! (list (let* ((default (or (current-word t) (car regexp-history))) (input (read-from-minibuffer (if default ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
