* make `occur' use word at point as default @ 2005-08-28 12:37 Emilio Lopes 2005-08-29 8:39 ` Richard M. Stallman 0 siblings, 1 reply; 27+ messages in thread From: Emilio Lopes @ 2005-08-28 12:37 UTC (permalink / raw) 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 <eclig@gmx.net> * 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-08-28 12:37 make `occur' use word at point as default Emilio Lopes @ 2005-08-29 8:39 ` Richard M. Stallman 2005-08-29 17:39 ` Emilio Lopes 0 siblings, 1 reply; 27+ messages in thread From: Richard M. Stallman @ 2005-08-29 8:39 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-08-29 8:39 ` Richard M. Stallman @ 2005-08-29 17:39 ` Emilio Lopes 2005-08-29 19:33 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Emilio Lopes @ 2005-08-29 17:39 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: make `occur' use word at point as default 2005-08-29 17:39 ` Emilio Lopes @ 2005-08-29 19:33 ` Drew Adams 2005-08-29 20:07 ` David Kastrup 2005-08-30 7:57 ` Mathias Dahl 2005-08-30 13:43 ` Kai Großjohann 2 siblings, 1 reply; 27+ messages in thread From: Drew Adams @ 2005-08-29 19:33 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-08-29 19:33 ` Drew Adams @ 2005-08-29 20:07 ` David Kastrup 0 siblings, 0 replies; 27+ messages in thread From: David Kastrup @ 2005-08-29 20:07 UTC (permalink / raw) Cc: emacs-devel "Drew Adams" <drew.adams@oracle.com> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-08-29 17:39 ` Emilio Lopes 2005-08-29 19:33 ` Drew Adams @ 2005-08-30 7:57 ` Mathias Dahl 2005-08-30 13:43 ` Kai Großjohann 2 siblings, 0 replies; 27+ messages in thread From: Mathias Dahl @ 2005-08-30 7:57 UTC (permalink / raw) Emilio Lopes <eclig@gmx.net> 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-08-29 17:39 ` Emilio Lopes 2005-08-29 19:33 ` Drew Adams 2005-08-30 7:57 ` Mathias Dahl @ 2005-08-30 13:43 ` Kai Großjohann 2005-08-31 14:35 ` Richard M. Stallman 2 siblings, 1 reply; 27+ messages in thread From: Kai Großjohann @ 2005-08-30 13:43 UTC (permalink / raw) Emilio Lopes <eclig@gmx.net> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-08-30 13:43 ` Kai Großjohann @ 2005-08-31 14:35 ` Richard M. Stallman 2005-08-31 16:03 ` Drew Adams 2005-09-01 5:47 ` Juri Linkov 0 siblings, 2 replies; 27+ messages in thread From: Richard M. Stallman @ 2005-08-31 14:35 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: make `occur' use word at point as default 2005-08-31 14:35 ` Richard M. Stallman @ 2005-08-31 16:03 ` Drew Adams 2005-09-01 15:52 ` Richard M. Stallman 2005-09-01 5:47 ` Juri Linkov 1 sibling, 1 reply; 27+ messages in thread From: Drew Adams @ 2005-08-31 16:03 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-08-31 16:03 ` Drew Adams @ 2005-09-01 15:52 ` Richard M. Stallman 2005-09-01 17:09 ` Drew Adams 0 siblings, 1 reply; 27+ messages in thread From: Richard M. Stallman @ 2005-09-01 15:52 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: make `occur' use word at point as default 2005-09-01 15:52 ` Richard M. Stallman @ 2005-09-01 17:09 ` Drew Adams 2005-09-01 19:29 ` Juri Linkov 2005-09-03 1:41 ` Richard M. Stallman 0 siblings, 2 replies; 27+ messages in thread From: Drew Adams @ 2005-09-01 17:09 UTC (permalink / raw) 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')? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-01 17:09 ` Drew Adams @ 2005-09-01 19:29 ` Juri Linkov 2005-09-01 23:59 ` Drew Adams 2005-09-03 1:41 ` Richard M. Stallman 1 sibling, 1 reply; 27+ messages in thread From: Juri Linkov @ 2005-09-01 19:29 UTC (permalink / raw) Cc: emacs-devel > 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/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: make `occur' use word at point as default 2005-09-01 19:29 ` Juri Linkov @ 2005-09-01 23:59 ` Drew Adams 0 siblings, 0 replies; 27+ messages in thread From: Drew Adams @ 2005-09-01 23:59 UTC (permalink / raw) > 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. If we chose that scheme, I would hope that it would be chosen based on its own special merits (whatever they might be), rather than on either: - the false perception that there is a scarcity of key-pairs to bind, or - an assumption that "default-value" implies the default-value arg to completing-read and "completion" implies the obarray arg, and never-the-twain-shall-meet (that is, assuming one side of the point under discussion: how to access default values) So, what are those special merits for M-n? Saying that M-n is more "natural" (and my saying that it is less "natural") doesn't get us very far. Another reason for dedicating a separate key pair to cycling default values (as completions), besides the desire to avoid confusion with navigation of the list of previous choices, would be to foresee the dedication of different _kinds_ of completion to different key pairs. In my library, for instance, I use the down/up arrows for cycling among the values that match the current input using normal, prefix completion. I use next/prior for cycling among the values that match the input using regexp completion (sort of an "apropos" completion). There are 3 separate pairs of keys that cycle possible inputs: - M-n/M-p: previous inputs (history list) - down/up: prefix completions (also C-n/C-p) - next/prior: apropos completions I can imagine that Emacs might itself employ different kinds of completion some day (still other kinds are imaginable), and we might then want different key pairs for these. 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. I did not advocate or even mention such unification at all, in fact. I mentioned my library that uses up/down, C-n/C-p, and next/prior. I've seen other libraries that also use up/down and C-n/C-p. I don't know any libraries with the bindings you refer to, and I'm not aware of any standard Emacs libraries that cycle completions. I don't doubt their existence; I'm just ignorant of them. Wrt your implied question of whether or not I advocate such unification: There might conceivably be good reasons for a particular package to use special bindings, so unification might not be appropriate across the board. However, if this is not the case - if other things are equal, and if the packages you refer to are part of Emacs, then yes, why not unify their bindings? Put me down now as a unification advocate, in that sense. But, to me, it is most important to let all default values be both: - cyclable (accessible, in sequence, by some key binding) - targets of completion What key(s) we bind for cycling those values is a secondary choice. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-01 17:09 ` Drew Adams 2005-09-01 19:29 ` Juri Linkov @ 2005-09-03 1:41 ` Richard M. Stallman 2005-09-03 2:01 ` Drew Adams 1 sibling, 1 reply; 27+ messages in thread From: Richard M. Stallman @ 2005-09-03 1:41 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: make `occur' use word at point as default 2005-09-03 1:41 ` Richard M. Stallman @ 2005-09-03 2:01 ` Drew Adams 2005-09-03 2:04 ` Drew Adams 2005-09-04 0:58 ` Richard M. Stallman 0 siblings, 2 replies; 27+ messages in thread From: Drew Adams @ 2005-09-03 2:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: make `occur' use word at point as default 2005-09-03 2:01 ` Drew Adams @ 2005-09-03 2:04 ` Drew Adams 2005-09-03 13:33 ` Benjamin Riefenstahl 2005-09-04 0:58 ` Richard M. Stallman 1 sibling, 1 reply; 27+ messages in thread From: Drew Adams @ 2005-09-03 2:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-03 2:04 ` Drew Adams @ 2005-09-03 13:33 ` Benjamin Riefenstahl 0 siblings, 0 replies; 27+ messages in thread From: Benjamin Riefenstahl @ 2005-09-03 13:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-03 2:01 ` Drew Adams 2005-09-03 2:04 ` Drew Adams @ 2005-09-04 0:58 ` Richard M. Stallman 2005-09-06 15:19 ` Drew Adams 1 sibling, 1 reply; 27+ messages in thread From: Richard M. Stallman @ 2005-09-04 0:58 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: make `occur' use word at point as default 2005-09-04 0:58 ` Richard M. Stallman @ 2005-09-06 15:19 ` Drew Adams 2005-09-07 5:05 ` Richard M. Stallman 2005-09-07 5:27 ` Juri Linkov 0 siblings, 2 replies; 27+ messages in thread From: Drew Adams @ 2005-09-06 15:19 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-06 15:19 ` Drew Adams @ 2005-09-07 5:05 ` Richard M. Stallman 2005-09-07 5:25 ` Drew Adams 2005-09-07 5:46 ` Juri Linkov 2005-09-07 5:27 ` Juri Linkov 1 sibling, 2 replies; 27+ messages in thread From: Richard M. Stallman @ 2005-09-07 5:05 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: make `occur' use word at point as default 2005-09-07 5:05 ` Richard M. Stallman @ 2005-09-07 5:25 ` Drew Adams 2005-09-07 5:46 ` Juri Linkov 1 sibling, 0 replies; 27+ messages in thread From: Drew Adams @ 2005-09-07 5:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-07 5:05 ` Richard M. Stallman 2005-09-07 5:25 ` Drew Adams @ 2005-09-07 5:46 ` Juri Linkov 2005-09-08 2:41 ` Richard M. Stallman 1 sibling, 1 reply; 27+ messages in thread From: Juri Linkov @ 2005-09-07 5:46 UTC (permalink / raw) Cc: drew.adams, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-07 5:46 ` Juri Linkov @ 2005-09-08 2:41 ` Richard M. Stallman 0 siblings, 0 replies; 27+ messages in thread From: Richard M. Stallman @ 2005-09-08 2:41 UTC (permalink / raw) Cc: drew.adams, emacs-devel 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-06 15:19 ` Drew Adams 2005-09-07 5:05 ` Richard M. Stallman @ 2005-09-07 5:27 ` Juri Linkov 1 sibling, 0 replies; 27+ messages in thread From: Juri Linkov @ 2005-09-07 5:27 UTC (permalink / raw) Cc: emacs-devel > 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.) Yes, and I want to add that if the user types RET with empty input, then it should put onto the history list not the whole list of default values, but only the first element of such list, i.e. the same element that minibuffer-reading functions return. BTW, currently there is an inconsistency in the `read-from-minibuffer' function. Typing RET with empty input after evaluation of: (read-from-minibuffer "prompt: " nil nil nil nil "default") adds the string "default" to the history list, even though this function returns an empty string. I don't know whether this should be fixed or maybe it causes no problems. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-08-31 14:35 ` Richard M. Stallman 2005-08-31 16:03 ` Drew Adams @ 2005-09-01 5:47 ` Juri Linkov 2005-09-01 13:08 ` Stefan Monnier 1 sibling, 1 reply; 27+ messages in thread From: Juri Linkov @ 2005-09-01 5:47 UTC (permalink / raw) Cc: emacs-devel > 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/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-01 5:47 ` Juri Linkov @ 2005-09-01 13:08 ` Stefan Monnier 2005-09-01 19:29 ` Juri Linkov 0 siblings, 1 reply; 27+ messages in thread From: Stefan Monnier @ 2005-09-01 13:08 UTC (permalink / raw) Cc: rms, emacs-devel > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: make `occur' use word at point as default 2005-09-01 13:08 ` Stefan Monnier @ 2005-09-01 19:29 ` Juri Linkov 0 siblings, 0 replies; 27+ messages in thread From: Juri Linkov @ 2005-09-01 19:29 UTC (permalink / raw) Cc: rms, emacs-devel >> 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/ ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2005-09-08 2:41 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-08-28 12:37 make `occur' use word at point as default Emilio Lopes 2005-08-29 8:39 ` Richard M. Stallman 2005-08-29 17:39 ` Emilio Lopes 2005-08-29 19:33 ` Drew Adams 2005-08-29 20:07 ` David Kastrup 2005-08-30 7:57 ` Mathias Dahl 2005-08-30 13:43 ` Kai Großjohann 2005-08-31 14:35 ` Richard M. Stallman 2005-08-31 16:03 ` Drew Adams 2005-09-01 15:52 ` Richard M. Stallman 2005-09-01 17:09 ` Drew Adams 2005-09-01 19:29 ` Juri Linkov 2005-09-01 23:59 ` Drew Adams 2005-09-03 1:41 ` Richard M. Stallman 2005-09-03 2:01 ` Drew Adams 2005-09-03 2:04 ` Drew Adams 2005-09-03 13:33 ` Benjamin Riefenstahl 2005-09-04 0:58 ` Richard M. Stallman 2005-09-06 15:19 ` Drew Adams 2005-09-07 5:05 ` Richard M. Stallman 2005-09-07 5:25 ` Drew Adams 2005-09-07 5:46 ` Juri Linkov 2005-09-08 2:41 ` Richard M. Stallman 2005-09-07 5:27 ` Juri Linkov 2005-09-01 5:47 ` Juri Linkov 2005-09-01 13:08 ` Stefan Monnier 2005-09-01 19:29 ` Juri Linkov
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.