* bug#7567: Please add a history variable to read-regexp @ 2010-12-06 2:24 Lennart Borgman 2010-12-06 22:43 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Lennart Borgman @ 2010-12-06 2:24 UTC (permalink / raw To: 7567 Also take care of the strange query-replace-from-history-variable in read-regexp. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 2:24 bug#7567: Please add a history variable to read-regexp Lennart Borgman @ 2010-12-06 22:43 ` Lennart Borgman 2010-12-06 22:57 ` Drew Adams 2010-12-06 23:03 ` Juri Linkov 2010-12-07 3:48 ` Stefan Monnier 2012-09-20 8:30 ` bug#7567: Please add a history argument " Juri Linkov 2 siblings, 2 replies; 29+ messages in thread From: Lennart Borgman @ 2010-12-06 22:43 UTC (permalink / raw To: 7567 On Mon, Dec 6, 2010 at 3:24 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > Also take care of the strange query-replace-from-history-variable in > read-regexp. No answer. Was something unclear here? The current read-regexp use is problematic for example in multi-isearch-read-matching-buffers and multi-occur-in-matching-buffers. I think a common history variable could be used for those cases, but they currently use the default regexp-history variable which seems totally inappropriate. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 22:43 ` Lennart Borgman @ 2010-12-06 22:57 ` Drew Adams 2010-12-06 23:00 ` Lennart Borgman 2010-12-06 23:03 ` Juri Linkov 1 sibling, 1 reply; 29+ messages in thread From: Drew Adams @ 2010-12-06 22:57 UTC (permalink / raw To: 'Lennart Borgman', 7567 > > Also take care of the strange query-replace-from-history-variable in > > read-regexp. > > No answer. Was something unclear here? > > The current read-regexp use is problematic for example in > multi-isearch-read-matching-buffers and > multi-occur-in-matching-buffers. I think a common history variable > could be used for those cases, but they currently use the default > regexp-history variable which seems totally inappropriate. I don't mean to meddle here, but it's not clear to me why `regexp-history' is not appropriate in the contexts you mention. The user is inputting a regexp. Why shouldn't previous regexps the user inputted be available in the input history for this operation? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 22:57 ` Drew Adams @ 2010-12-06 23:00 ` Lennart Borgman 2010-12-06 23:11 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: Lennart Borgman @ 2010-12-06 23:00 UTC (permalink / raw To: Drew Adams; +Cc: 7567 On Mon, Dec 6, 2010 at 11:57 PM, Drew Adams <drew.adams@oracle.com> wrote: >> > Also take care of the strange query-replace-from-history-variable in >> > read-regexp. >> >> No answer. Was something unclear here? >> >> The current read-regexp use is problematic for example in >> multi-isearch-read-matching-buffers and >> multi-occur-in-matching-buffers. I think a common history variable >> could be used for those cases, but they currently use the default >> regexp-history variable which seems totally inappropriate. > > I don't mean to meddle here, but it's not clear to me why `regexp-history' is > not appropriate in the contexts you mention. The user is inputting a regexp. > Why shouldn't previous regexps the user inputted be available in the input > history for this operation? Thanks for asking, I thought it was clear. Why should that regexp be used to make buffer names? It is probably a regexp that has been used for matching strings in buffers. (It might of course be a regexp from a search in *Buffer List*, but that is not the normal case.) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 23:00 ` Lennart Borgman @ 2010-12-06 23:11 ` Drew Adams 2010-12-06 23:23 ` Lennart Borgman 2010-12-08 1:51 ` Juri Linkov 0 siblings, 2 replies; 29+ messages in thread From: Drew Adams @ 2010-12-06 23:11 UTC (permalink / raw To: 'Lennart Borgman'; +Cc: 7567 > Thanks for asking, I thought it was clear. You're welcome. > Why should that regexp be used to make buffer names? It is probably a > regexp that has been used for matching strings in buffers. Why is it "probably" that? I use regexps interactively all over the place. Matching text in a buffer is only one use. > (It might of course be a regexp from a search in *Buffer List*, > but that is not the normal case.) IMO, there is no "normal" case. This is a general limitation wrt history vars. But it cannot really be otherwise. You might want some particular values to be available on a given history list in some context, and you (or I) might want them to not be available on that list in another context. We can add more history vars to get finer-grained control, but then you miss out if you want to access something that it was decided should be on another history list. It's impossible to have it both ways, because the user's intention is a variable that cannot easily and always be taken into consideration. IOW, there are some things the programmer can decide when writing the function call that reads input (you can use any history var you want, including new ones), but still you cannot always know what the user really needs/wants. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 23:11 ` Drew Adams @ 2010-12-06 23:23 ` Lennart Borgman 2010-12-07 0:31 ` Drew Adams 2010-12-07 4:09 ` Drew Adams 2010-12-08 1:51 ` Juri Linkov 1 sibling, 2 replies; 29+ messages in thread From: Lennart Borgman @ 2010-12-06 23:23 UTC (permalink / raw To: Drew Adams; +Cc: 7567 On Tue, Dec 7, 2010 at 12:11 AM, Drew Adams <drew.adams@oracle.com> wrote: >> Thanks for asking, I thought it was clear. > > You're welcome. > >> Why should that regexp be used to make buffer names? It is probably a >> regexp that has been used for matching strings in buffers. > > Why is it "probably" that? > > I use regexps interactively all over the place. Matching text in a buffer is > only one use. Can you give examples of other interactive uses, please? That might make it easier to know what we are really talking about. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 23:23 ` Lennart Borgman @ 2010-12-07 0:31 ` Drew Adams 2010-12-07 4:09 ` Drew Adams 1 sibling, 0 replies; 29+ messages in thread From: Drew Adams @ 2010-12-07 0:31 UTC (permalink / raw To: 'Lennart Borgman'; +Cc: 7567 > >> Why should that regexp be used to make buffer names? It is > >> probably a regexp that has been used for matching strings in buffers. > > > > Why is it "probably" that? > > > > I use regexps interactively all over the place. Matching > > text in a buffer is only one use. > > Can you give examples of other interactive uses, please? That might > make it easier to know what we are really talking about. Use your imagination. But yes, of course anything _could_ be put in a buffer, so conceivably any use of a regexp could involve matching some buffer's text... What about the very functions you mentioned? Why wouldn't regexps they read also be useful in some buffer? Or vice versa, why couldn't some buffer-text regexp be useful for those functions? Anyway, if you insist, here are a few examples: `icicle-customize-apropos': Customize all user options matching REGEXP. Likewise, customize faces and groups. Likewise Icicles apropos functions. I even use it in the Icicles version of `apropos-zippy' (but the vanilla version uses (interactive "s...")). `icicle-find-tag': Navigate among all tags whose names match REGEXP. I use it for `icicle-keyword-list', which reads a list of keywords, each of which could actually be a regexp. I use it in `icicle-widen-candidates', which adds completion candidates based on an alternative regexp. And there are specialized vanilla regexp histories, such as `dired-regexp-history'. And you yourself mentioned matching a buffer name. (I do that in `icicle-add-buffer-config', for instance: buffer names to match for inclusion and for exclusion as completion candidates.) Now you can imagine lots of others, I think. A regexp can be used anywhere, and a function to read a regexp can be used in any regexp use case. I guess what I'd really like to ask you is this: Please give a reason why `read-regexp', which is extremely general, should _not_ use the general regexp history variable. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 23:23 ` Lennart Borgman 2010-12-07 0:31 ` Drew Adams @ 2010-12-07 4:09 ` Drew Adams 1 sibling, 0 replies; 29+ messages in thread From: Drew Adams @ 2010-12-07 4:09 UTC (permalink / raw To: 'Lennart Borgman'; +Cc: 7567 In answer to a question from Lennart off list I realize that I misunderstood his request. In spite of the Subject line, which I think I skipped over, I mistakenly thought he was just requesting that `read-regexp' use a _different_ history variable (e.g. `read-regexp-history') in its call to `read-from-minibuffer'. I didn't realize that he was really requesting that `read-regexp' accept an additional, optional HISTORY arg, which would be passed to `read-from-minibuffer' (nil HISTORY would mean to pass `regexp-history', as now). Now that I understand, I agree with Lennart. There is no reason not to let `read-regexp' be even more general by parameterizing it with a HISTORY parameter. Sorry for misunderstanding. In case others also misunderstood, this is the idea: (defun read-regexp (prompt &optional default-value history) "... Non-nil HISTORY is a symbol to use as the history variable. If HISTORY is nil, `regexp-history' is used." ...) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 23:11 ` Drew Adams 2010-12-06 23:23 ` Lennart Borgman @ 2010-12-08 1:51 ` Juri Linkov 2010-12-08 3:03 ` Drew Adams 1 sibling, 1 reply; 29+ messages in thread From: Juri Linkov @ 2010-12-08 1:51 UTC (permalink / raw To: Drew Adams; +Cc: 7567 > It's impossible to have it both ways, because the user's intention is a variable > that cannot easily and always be taken into consideration. IOW, there are some > things the programmer can decide when writing the function call that reads input > (you can use any history var you want, including new ones), but still you cannot > always know what the user really needs/wants. Does Icicles provide a way for the user to select and switch history variables dynamically while the minibuffer is active? This looks like a possible way to overcome this limitation. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-08 1:51 ` Juri Linkov @ 2010-12-08 3:03 ` Drew Adams 0 siblings, 0 replies; 29+ messages in thread From: Drew Adams @ 2010-12-08 3:03 UTC (permalink / raw To: 'Juri Linkov'; +Cc: 7567 > > It's impossible to have it both ways, because the user's > > intention is a variable that cannot easily and always be > > taken into consideration. IOW, there are some > > things the programmer can decide when writing the function > > call that reads input (you can use any history var you want, > > including new ones), but still you cannot > > always know what the user really needs/wants. > > Does Icicles provide a way for the user to select and switch > history variables dynamically while the minibuffer is active? > This looks like a possible way to overcome this limitation. No, it doesn't. ;-) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 22:43 ` Lennart Borgman 2010-12-06 22:57 ` Drew Adams @ 2010-12-06 23:03 ` Juri Linkov 2010-12-06 23:46 ` Lennart Borgman 1 sibling, 1 reply; 29+ messages in thread From: Juri Linkov @ 2010-12-06 23:03 UTC (permalink / raw To: Lennart Borgman; +Cc: 7567 > No answer. Was something unclear here? Why so impatient, you waited for the answer only half a day :) > The current read-regexp use is problematic for example in > multi-isearch-read-matching-buffers and > multi-occur-in-matching-buffers. I think a common history variable > could be used for those cases, but they currently use the default > regexp-history variable which seems totally inappropriate. `regexp-history' is a common history variable for all commands that read a regexp from the minibuffer. I don't understand what is wrong with that? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 23:03 ` Juri Linkov @ 2010-12-06 23:46 ` Lennart Borgman 2010-12-08 1:44 ` Juri Linkov 0 siblings, 1 reply; 29+ messages in thread From: Lennart Borgman @ 2010-12-06 23:46 UTC (permalink / raw To: Juri Linkov; +Cc: 7567 On Tue, Dec 7, 2010 at 12:03 AM, Juri Linkov <juri@jurta.org> wrote: > >> The current read-regexp use is problematic for example in >> multi-isearch-read-matching-buffers and >> multi-occur-in-matching-buffers. I think a common history variable >> could be used for those cases, but they currently use the default >> regexp-history variable which seems totally inappropriate. > > `regexp-history' is a common history variable for all commands > that read a regexp from the minibuffer. I don't understand > what is wrong with that? Please take a look in the current code in query-replace-read-from. This currently does not use read-regexp (which it should) because it is easier to switch history variable if you don't. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 23:46 ` Lennart Borgman @ 2010-12-08 1:44 ` Juri Linkov 0 siblings, 0 replies; 29+ messages in thread From: Juri Linkov @ 2010-12-08 1:44 UTC (permalink / raw To: Lennart Borgman; +Cc: 7567 > Please take a look in the current code in query-replace-read-from. > This currently does not use read-regexp (which it should) because it > is easier to switch history variable if you don't. `query-replace' should share its history with `from' and `to' parts by default as it does now. But I agree that it could provide the same defaults as `read-regexp'. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-06 2:24 bug#7567: Please add a history variable to read-regexp Lennart Borgman 2010-12-06 22:43 ` Lennart Borgman @ 2010-12-07 3:48 ` Stefan Monnier 2010-12-08 1:57 ` Juri Linkov 2010-12-08 3:32 ` Lennart Borgman 2012-09-20 8:30 ` bug#7567: Please add a history argument " Juri Linkov 2 siblings, 2 replies; 29+ messages in thread From: Stefan Monnier @ 2010-12-07 3:48 UTC (permalink / raw To: Lennart Borgman; +Cc: 7567 So after reading the rest of the thread, I think I finally understand that you want to "add a history *argument* to read-regexp", right? Then it sounds perfectly acceptable. Using correct words always helps. Of course, explaining the problem in more details is also another way to avoid falling into such misunderstaning, via redundancy. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-07 3:48 ` Stefan Monnier @ 2010-12-08 1:57 ` Juri Linkov 2010-12-08 2:19 ` Lennart Borgman ` (2 more replies) 2010-12-08 3:32 ` Lennart Borgman 1 sibling, 3 replies; 29+ messages in thread From: Juri Linkov @ 2010-12-08 1:57 UTC (permalink / raw To: Stefan Monnier; +Cc: 7567 > So after reading the rest of the thread, I think I finally understand > that you want to "add a history *argument* to read-regexp", right? > Then it sounds perfectly acceptable. For consistency, `read-regexp' could have the same function signature as other minibuffer reading functions, e.g. like `read-string': (read-string PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD) (read-regexp PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-08 1:57 ` Juri Linkov @ 2010-12-08 2:19 ` Lennart Borgman 2010-12-09 1:25 ` Juri Linkov 2010-12-08 3:10 ` Drew Adams 2010-12-09 14:28 ` Stefan Monnier 2 siblings, 1 reply; 29+ messages in thread From: Lennart Borgman @ 2010-12-08 2:19 UTC (permalink / raw To: Juri Linkov; +Cc: 7567 On Wed, Dec 8, 2010 at 2:57 AM, Juri Linkov <juri@jurta.org> wrote: >> So after reading the rest of the thread, I think I finally understand >> that you want to "add a history *argument* to read-regexp", right? >> Then it sounds perfectly acceptable. > > For consistency, `read-regexp' could have the same function signature > as other minibuffer reading functions, e.g. like `read-string': > > (read-string PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD) > > (read-regexp PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD) I agree. In addition to that when we have that in place then a number of places in the code should be updated to use it instead of read-string. (And some new history vars for it should be added.) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-08 2:19 ` Lennart Borgman @ 2010-12-09 1:25 ` Juri Linkov 0 siblings, 0 replies; 29+ messages in thread From: Juri Linkov @ 2010-12-09 1:25 UTC (permalink / raw To: Lennart Borgman; +Cc: 7567 > In addition to that when we have that in place then a number of places > in the code should be updated to use it instead of read-string. (And > some new history vars for it should be added.) Please show these places. I think most of them should share the same regexp history. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-08 1:57 ` Juri Linkov 2010-12-08 2:19 ` Lennart Borgman @ 2010-12-08 3:10 ` Drew Adams 2010-12-09 14:31 ` Stefan Monnier 2010-12-09 14:28 ` Stefan Monnier 2 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2010-12-08 3:10 UTC (permalink / raw To: 'Juri Linkov', 'Stefan Monnier'; +Cc: 7567 > For consistency, `read-regexp' could have the same function signature > as other minibuffer reading functions, e.g. like `read-string': > > (read-string PROMPT &optional INITIAL-INPUT HISTORY > DEFAULT-VALUE INHERIT-INPUT-METHOD) > > (read-regexp PROMPT &optional INITIAL-INPUT HISTORY > DEFAULT-VALUE INHERIT-INPUT-METHOD) I agree with that. But I also think that it might be good to use `completing-read', to allow (lax) completion against the history. IOW, use the history for both completion and the usual history access. FWIW, I use completion for regexp reading, but more often against a different set of candidates from the history. E.g., for `icicle-customize-apropos', I use this to read a regexp that matches an option name: (completing-read "Customize (regexp): " obarray nil nil nil 'regexp-history) And for `icicle-find-tag' I use this to read a regexp that matches a tag: (completing-read "Find tag matching regexp: " ;;; $$$ Or should we just read a regexp against `regexp-history'? (if (fboundp 'tags-lazy-completion-table) (tags-lazy-completion-table) ; Emacs 23+ 'tags-complete-tag) ; Emacs < 23 nil nil nil 'find-tag-history (funcall (or find-tag-default-function (get major-mode 'find-tag-default-function) 'find-tag-default))) You can tell from the code comment here that I'm not sure the tag COLLECTION here is better than a regexp history as COLLECTION. (But in Icicles you can hit a key in the minibuffer to complete against the current history, so it's usually better to offer a different set for COLLECTION.) Anyway, I think that Juri's proposal (built on Lennart's) would be an improvement. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-08 3:10 ` Drew Adams @ 2010-12-09 14:31 ` Stefan Monnier 2010-12-09 16:14 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2010-12-09 14:31 UTC (permalink / raw To: Drew Adams; +Cc: 7567 > I agree with that. But I also think that it might be good to use > `completing-read', to allow (lax) completion against the history. > IOW, use the history for both completion and the usual history access. I think this is a bad idea: completing-read is for completion against "possible answers" which should be kept separate from history-completion. We could/should let TAB perform history completion for non-completing-reads, but if we do that, it should be under the control of the user. Personally, I think that M-p should perform history completion, and that's what my .emacs does. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-09 14:31 ` Stefan Monnier @ 2010-12-09 16:14 ` Drew Adams 2010-12-10 3:09 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2010-12-09 16:14 UTC (permalink / raw To: 'Stefan Monnier'; +Cc: 7567 > > I agree with that. But I also think that it might be good to use > > `completing-read', to allow (lax) completion against the history. > > IOW, use the history for both completion and the usual > > history access. > > I think this is a bad idea: completing-read is for completion against > "possible answers" which should be kept separate from > history-completion. I generally agree. In this case, there was no (is no) other completion, so there are no other-kind of completion candidates to keep the history separate from. But yes, I agree. > We could/should let TAB perform history > completion for non-completing-reads, but if we do that, it should > be under the control of the user. Agreed, especially the last part. I really meant only that it's good in general to have more use of (lax) completion and less use of things like `read-string' and `read-regexp' that provide what lax completion provides but without any completion. > Personally, I think that M-p should perform history completion, and > that's what my .emacs does. That would be OK. The big advantage of completion vs `M-p' etc. is that you can get more directly to a history entry, no matter how long ago you originally entered it. Another possibility - not at all the same thing, but useful in such a case as well as in others - is what Icicles does: Use another key (`M-o') to let you complete against the history and insert the result into the minibuffer (without committing it). This uses a recursive minibuffer and is available during any minibuffer input - not just during completing reads. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-09 16:14 ` Drew Adams @ 2010-12-10 3:09 ` Stefan Monnier 0 siblings, 0 replies; 29+ messages in thread From: Stefan Monnier @ 2010-12-10 3:09 UTC (permalink / raw To: Drew Adams; +Cc: 7567 > I really meant only that it's good in general to have more use of (lax) > completion and less use of things like `read-string' and `read-regexp' that > provide what lax completion provides but without any completion. That's OK: just don't do it by changing the callers of read-regexp but by changing read-regexp's behavior. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-08 1:57 ` Juri Linkov 2010-12-08 2:19 ` Lennart Borgman 2010-12-08 3:10 ` Drew Adams @ 2010-12-09 14:28 ` Stefan Monnier 2010-12-09 17:43 ` Drew Adams 2 siblings, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2010-12-09 14:28 UTC (permalink / raw To: Juri Linkov; +Cc: 7567 >> So after reading the rest of the thread, I think I finally understand >> that you want to "add a history *argument* to read-regexp", right? >> Then it sounds perfectly acceptable. > For consistency, `read-regexp' could have the same function signature > as other minibuffer reading functions, e.g. like `read-string': > (read-string PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD) > (read-regexp PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD) No: new such functions should not offer both INITIAL-INPUT and DEFAULT-VALUE. Instead, they should (like read-regexp) only accept DEFAULT-VALUE (and automatically add it to the prompt in the standard format). Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-09 14:28 ` Stefan Monnier @ 2010-12-09 17:43 ` Drew Adams 2010-12-10 3:06 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2010-12-09 17:43 UTC (permalink / raw To: 'Stefan Monnier', 'Juri Linkov'; +Cc: 7567 > No: new such functions should not offer both INITIAL-INPUT and > DEFAULT-VALUE. Instead, they should (like read-regexp) only accept > DEFAULT-VALUE (and automatically add it to the prompt in the standard > format). Let INITIAL-INPUT be. -- John Lennon No one is forced to use it. What did it ever do to you? ;-) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-09 17:43 ` Drew Adams @ 2010-12-10 3:06 ` Stefan Monnier 2010-12-10 3:46 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2010-12-10 3:06 UTC (permalink / raw To: Drew Adams; +Cc: 7567 >> No: new such functions should not offer both INITIAL-INPUT and >> DEFAULT-VALUE. Instead, they should (like read-regexp) only accept >> DEFAULT-VALUE (and automatically add it to the prompt in the standard >> format). > Let INITIAL-INPUT be. -- John Lennon > No one is forced to use it. What did it ever do to you? ;-) It's too low-level: better provide a DEFAULT-VALUE and then the function can decide to do as we do (i.e. put default in prompt and in M-n) or as they do (put it as the initial contents, selected so that delete-selection-mode can get rid of it in a pinch). Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-10 3:06 ` Stefan Monnier @ 2010-12-10 3:46 ` Drew Adams 2010-12-10 20:10 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2010-12-10 3:46 UTC (permalink / raw To: 'Stefan Monnier'; +Cc: 7567 > >> No: new such functions should not offer both INITIAL-INPUT and > >> DEFAULT-VALUE. Instead, they should (like read-regexp) only accept > >> DEFAULT-VALUE (and automatically add it to the prompt in > >> the standard format). > > > Let INITIAL-INPUT be. -- John Lennon > > > No one is forced to use it. What did it ever do to you? ;-) > > It's too low-level: better provide a DEFAULT-VALUE and then > the function What function? > can decide to do as we do (i.e. put default in prompt and in > M-n) or as they do They who/what? > (put it as the initial contents, selected so that > delete-selection-mode can get rid of it in a pinch). Who/what does that, and how? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-10 3:46 ` Drew Adams @ 2010-12-10 20:10 ` Stefan Monnier 0 siblings, 0 replies; 29+ messages in thread From: Stefan Monnier @ 2010-12-10 20:10 UTC (permalink / raw To: Drew Adams; +Cc: 7567 >> It's too low-level: better provide a DEFAULT-VALUE and then >> the function > What function? read-<foo> (i.e. read-regexp in the case at hand). >> can decide to do as we do (i.e. put default in prompt and in >> M-n) or as they do > They who/what? Most other GUI applications. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history variable to read-regexp 2010-12-07 3:48 ` Stefan Monnier 2010-12-08 1:57 ` Juri Linkov @ 2010-12-08 3:32 ` Lennart Borgman 1 sibling, 0 replies; 29+ messages in thread From: Lennart Borgman @ 2010-12-08 3:32 UTC (permalink / raw To: Stefan Monnier, Drew Adams; +Cc: 7567 On Tue, Dec 7, 2010 at 4:48 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > So after reading the rest of the thread, I think I finally understand > that you want to "add a history *argument* to read-regexp", right? > Then it sounds perfectly acceptable. > > Using correct words always helps. Of course, explaining the problem in > more details is also another way to avoid falling into such > misunderstaning, via redundancy. (Seems like this excuse was not sent.) Thanks. Sorry Drew, Stefan and Juri for the misunderstandings and trouble. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history argument to read-regexp 2010-12-06 2:24 bug#7567: Please add a history variable to read-regexp Lennart Borgman 2010-12-06 22:43 ` Lennart Borgman 2010-12-07 3:48 ` Stefan Monnier @ 2012-09-20 8:30 ` Juri Linkov 2012-09-20 21:59 ` Juri Linkov 2 siblings, 1 reply; 29+ messages in thread From: Juri Linkov @ 2012-09-20 8:30 UTC (permalink / raw To: 7567 This patch fixes bug#7567 by adding a history argument to `read-regexp': === modified file 'lisp/replace.el' --- lisp/replace.el 2012-09-09 22:15:24 +0000 +++ lisp/replace.el 2012-09-20 08:28:05 +0000 @@ -574,12 +575,14 @@ (defvar regexp-history nil (defvar occur-collect-regexp-history '("\\1") "History of regexp for occur's collect operation") -(defun read-regexp (prompt &optional default-value) +(defun read-regexp (prompt &optional default-value history) "Read regexp as a string using the regexp history and some useful defaults. Prompt for a regular expression with PROMPT (without a colon and space) in the minibuffer. The optional argument DEFAULT-VALUE provides the value to display in the minibuffer prompt that is returned if the user just types RET. +Non-nil HISTORY is a symbol to use as the history list. +If HISTORY is nil, `regexp-history' is used. Values available via M-n are the string at point, the last isearch regexp, the last isearch string, and the last replacement regexp." (let* ((defaults @@ -603,11 +606,11 @@ (defun read-regexp (prompt &optional def (format "%s (default %s): " prompt (query-replace-descr default-value)) (format "%s: " prompt))) - nil nil nil 'regexp-history defaults t))) + nil nil nil (or history 'regexp-history) defaults t))) (if (equal input "") (or default-value input) (prog1 input - (add-to-history 'regexp-history input))))) + (add-to-history (or history 'regexp-history) input))))) This allows more functions to use `read-regexp' with other history lists as was discussed here in bug#7567 a year ago. === modified file 'lisp/replace.el' --- lisp/replace.el 2012-09-09 22:15:24 +0000 +++ lisp/replace.el 2012-09-20 08:28:05 +0000 @@ -128,20 +128,21 @@ (defun query-replace-read-from (prompt r (if query-replace-interactive (car (if regexp-flag regexp-search-ring search-ring)) (let* ((history-add-new-input nil) + (prompt + (if query-replace-defaults + (format "%s (default %s -> %s): " prompt + (query-replace-descr (car query-replace-defaults)) + (query-replace-descr (cdr query-replace-defaults))) + (format "%s: " prompt))) (from ;; The save-excursion here is in case the user marks and copies ;; a region in order to specify the minibuffer input. ;; That should not clobber the region for the query-replace itself. (save-excursion - (read-from-minibuffer - (if query-replace-defaults - (format "%s (default %s -> %s): " prompt - (query-replace-descr (car query-replace-defaults)) - (query-replace-descr (cdr query-replace-defaults))) - (format "%s: " prompt)) - nil nil nil - query-replace-from-history-variable - nil t)))) + (if regexp-flag + (read-regexp prompt nil query-replace-from-history-variable) + (read-from-minibuffer + prompt nil nil nil query-replace-from-history-variable nil t))))) (if (and (zerop (length from)) query-replace-defaults) (cons (car query-replace-defaults) (query-replace-compile-replacement @@ -1130,9 +1135,9 @@ (defun occur-read-primary-args () "\\&" ;; Get the regexp for collection pattern. (let ((default (car occur-collect-regexp-history))) - (read-string + (read-regexp (format "Regexp to collect (default %s): " default) - nil 'occur-collect-regexp-history default))) + default 'occur-collect-regexp-history))) ;; Otherwise normal occur takes numerical prefix argument. (when current-prefix-arg (prefix-numeric-value current-prefix-arg)))))) @@ -1219,14 +1224,11 @@ (defun multi-occur-in-matching-buffers ( (cons (let* ((default (car regexp-history)) (input - (read-from-minibuffer + (read-regexp (if current-prefix-arg "List lines in buffers whose names match regexp: " "List lines in buffers whose filenames match regexp: ") - nil - nil - nil - 'regexp-history))) + nil 'regexp-history))) (if (equal input "") default input)) === modified file 'lisp/isearch.el' --- lisp/isearch.el 2012-09-09 22:15:24 +0000 +++ lisp/isearch.el 2012-09-20 08:23:25 +0000 @@ -1649,9 +1681,9 @@ (defun isearch-occur (regexp &optional n (isearch-done nil t) (isearch-clean-overlays) (let ((default (car occur-collect-regexp-history))) - (read-string + (read-regexp (format "Regexp to collect (default %s): " default) - nil 'occur-collect-regexp-history default))) + default 'occur-collect-regexp-history))) ;; Otherwise normal occur takes numerical prefix argument. (when current-prefix-arg (prefix-numeric-value current-prefix-arg)))))) === modified file 'lisp/progmodes/grep.el' --- lisp/progmodes/grep.el 2012-04-20 08:48:50 +0000 +++ lisp/progmodes/grep.el 2012-09-20 08:24:55 +0000 @@ -817,11 +831,11 @@ (defun grep-expand-template (template &o (defun grep-read-regexp () "Read regexp arg for interactive grep." (let ((default (grep-tag-default))) - (read-string + (read-regexp (concat "Search for" (if (and default (> (length default) 0)) (format " (default \"%s\"): " default) ": ")) - nil 'grep-regexp-history default))) + default 'grep-regexp-history))) (defun grep-read-files (regexp) "Read files arg for interactive grep." === modified file 'lisp/dired.el' --- lisp/dired.el 2012-09-18 23:40:39 +0000 +++ lisp/dired.el 2012-09-20 08:21:11 +0000 @@ -3178,8 +3196,8 @@ (defun dired-toggle-marks () (defvar dired-regexp-history nil "History list of regular expressions used in Dired commands.") -(defun dired-read-regexp (prompt) - (read-from-minibuffer prompt nil nil nil 'dired-regexp-history)) +(defun dired-read-regexp (prompt &optional default history) + (read-regexp prompt default (or history 'dired-regexp-history))) (defun dired-mark-files-regexp (regexp &optional marker-char) "Mark all files matching REGEXP for use in later commands. PS: The problems related to other arguments (PROMPT and DEFAULT-VALUE) of `read-regexp' are about to be fixed in bug#12321. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#7567: Please add a history argument to read-regexp 2012-09-20 8:30 ` bug#7567: Please add a history argument " Juri Linkov @ 2012-09-20 21:59 ` Juri Linkov 0 siblings, 0 replies; 29+ messages in thread From: Juri Linkov @ 2012-09-20 21:59 UTC (permalink / raw To: 7567-done Closed together with bug#12321. ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2012-09-20 21:59 UTC | newest] Thread overview: 29+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-06 2:24 bug#7567: Please add a history variable to read-regexp Lennart Borgman 2010-12-06 22:43 ` Lennart Borgman 2010-12-06 22:57 ` Drew Adams 2010-12-06 23:00 ` Lennart Borgman 2010-12-06 23:11 ` Drew Adams 2010-12-06 23:23 ` Lennart Borgman 2010-12-07 0:31 ` Drew Adams 2010-12-07 4:09 ` Drew Adams 2010-12-08 1:51 ` Juri Linkov 2010-12-08 3:03 ` Drew Adams 2010-12-06 23:03 ` Juri Linkov 2010-12-06 23:46 ` Lennart Borgman 2010-12-08 1:44 ` Juri Linkov 2010-12-07 3:48 ` Stefan Monnier 2010-12-08 1:57 ` Juri Linkov 2010-12-08 2:19 ` Lennart Borgman 2010-12-09 1:25 ` Juri Linkov 2010-12-08 3:10 ` Drew Adams 2010-12-09 14:31 ` Stefan Monnier 2010-12-09 16:14 ` Drew Adams 2010-12-10 3:09 ` Stefan Monnier 2010-12-09 14:28 ` Stefan Monnier 2010-12-09 17:43 ` Drew Adams 2010-12-10 3:06 ` Stefan Monnier 2010-12-10 3:46 ` Drew Adams 2010-12-10 20:10 ` Stefan Monnier 2010-12-08 3:32 ` Lennart Borgman 2012-09-20 8:30 ` bug#7567: Please add a history argument " Juri Linkov 2012-09-20 21:59 ` 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.