* new apropos feature in Emacs-22
@ 2005-11-05 3:15 Luc Teirlinck
2005-11-05 10:26 ` Eli Zaretskii
2005-11-05 23:43 ` Richard M. Stallman
0 siblings, 2 replies; 69+ messages in thread
From: Luc Teirlinck @ 2005-11-05 3:15 UTC (permalink / raw)
>From `(emacs)Apropos':
Because `C-h a' looks only for commands matching the string you
specify, you may not find what you want on the first try. In that
case, don't just give up. You can give Apropos a list of words to
search for. When more than one word is specified, at least two of
those words must be present for an item to match. If you are looking
for commands to kill a chunk of text before point, try `C-h a kill back
behind before <RET>'. For even greater flexibility, you can also
supply a regular expression to Apropos (*note Regexps::).
The described behavior is new in Emacs-22. There are several problems
with it.
Firstly, the last sentence of the above paragraph is false. You can
not specify any regexp: a regexp that contains spaces or tabs and that
only matches itself will be mistaken for a list of keywords, unless you
use a special trick, say using "[f]ont lock mode" instead of
"font lock mode" (but no such trick is mentioned in the Emacs manual).
This restriction might not be too bad for apropos-command and
apropos-variable, where spaces make little sense, but for
apropos-documentation (and actually sometimes also apropos-value) it
could easily confuse people used to the prior behavior.
Secondly, the "at least two matching keywords" rule seems arbitrary.
Why not use the convention that a list of keywords is specified as, say
directory folder [1
or
next directory folder [2
Where the number after `[' denotes the number of required matching
keywords and the unbalanced `[' guarantees that the convention never
overwrites a valid regexp.
If the present convention is kept unchanged, then one should at the
very least update the involved docstrings: although the Emacs manual
mentions the new behavior, apparently none of the docstrings of the
involved commands do. All the docstrings still suggest that the
REGEXP argument will always be treated as a regular expression.
Sincerely,
Luc.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 3:15 new apropos feature in Emacs-22 Luc Teirlinck @ 2005-11-05 10:26 ` Eli Zaretskii 2005-11-05 15:52 ` Luc Teirlinck 2005-11-05 23:43 ` Richard M. Stallman 1 sibling, 1 reply; 69+ messages in thread From: Eli Zaretskii @ 2005-11-05 10:26 UTC (permalink / raw) Cc: emacs-devel > Date: Fri, 4 Nov 2005 21:15:45 -0600 (CST) > From: Luc Teirlinck <teirllm@dms.auburn.edu> > > Secondly, the "at least two matching keywords" rule seems arbitrary. > Why not use the convention that a list of keywords is specified as, say > > directory folder [1 > > or > > next directory folder [2 This feature (and any ad-hoc rules it implements) was discussed at length around the time the feature was added. Please be sure to read those discussions before you suggest to change the decisions made back then. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 10:26 ` Eli Zaretskii @ 2005-11-05 15:52 ` Luc Teirlinck 2005-11-05 16:43 ` Eli Zaretskii 2005-11-06 17:02 ` Stefan Monnier 0 siblings, 2 replies; 69+ messages in thread From: Luc Teirlinck @ 2005-11-05 15:52 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii wrote: This feature (and any ad-hoc rules it implements) was discussed at length around the time the feature was added. Please be sure to read those discussions before you suggest to change the decisions made back then. Nothing in that discussion changes the fact that: (string-equal (regexp-quote regexp) regexp) is just a horrible way to distinguish a regexp from a list of keywords. The prompt string of the apropos commands says: (regexp or words). Which of the two and how do I choose? The docstrings all say that it matches a regexp and do not mention keywords at all. To the person who wants to use a regexp, it is confusing that `M-x apropos-documentation RET font lock RET" produces tons of unexpected matches and unexpected highlighting. To the person who reads the Emacs manual and knows nothing about regexps, it is even a lot more confusing that things like: M-x apropos-documentation RET *scratch* buffer RET does not find any matches, even though there are several places matching both keywords. Things like: M-x apropos-documentation RET .emacs init RET are probably even worse, since _some_ matches are actually displayed, but not the ones the user may be trying to find. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 15:52 ` Luc Teirlinck @ 2005-11-05 16:43 ` Eli Zaretskii 2005-11-05 17:33 ` Drew Adams 2005-11-05 17:39 ` Luc Teirlinck 2005-11-06 17:02 ` Stefan Monnier 1 sibling, 2 replies; 69+ messages in thread From: Eli Zaretskii @ 2005-11-05 16:43 UTC (permalink / raw) Cc: emacs-devel > Date: Sat, 5 Nov 2005 09:52:38 -0600 (CST) > From: Luc Teirlinck <teirllm@dms.auburn.edu> > CC: emacs-devel@gnu.org > > Eli Zaretskii wrote: > > This feature (and any ad-hoc rules it implements) was discussed at > length around the time the feature was added. Please be sure to read > those discussions before you suggest to change the decisions made back > then. > > Nothing in that discussion changes the fact that: > > (string-equal (regexp-quote regexp) regexp) > > is just a horrible way to distinguish a regexp from a list of keywords. Please don't get angry with me: I was only trying to say that the seemingly arbitrary rule of "at least two matching keywords" might have some valid reasons which are spelled out in the discussions. I do agree that the doc strings should be updated to reflect the fact that a list of keywords are accepted as well as regexps. > To the person who wants to use a regexp, it is confusing that > `M-x apropos-documentation RET font lock RET" produces tons of > unexpected matches and unexpected highlighting. I think the idea was that a list of words is more natural input at that point than a regexp. People nowadays are used to Google-style queries more than to regexps. FWIW, I rarely myself use regexps in apropos. > To the person who reads the Emacs manual and knows nothing about > regexps, it is even a lot more confusing that things like: > > M-x apropos-documentation RET *scratch* buffer RET > > does not find any matches, even though there are several places matching > both keywords. > > Things like: > > M-x apropos-documentation RET .emacs init RET > > are probably even worse, since _some_ matches are actually displayed, > but not the ones the user may be trying to find. I think these problems were raised and discussed back then, but I might be wrong. ^ permalink raw reply [flat|nested] 69+ messages in thread
* RE: new apropos feature in Emacs-22 2005-11-05 16:43 ` Eli Zaretskii @ 2005-11-05 17:33 ` Drew Adams 2005-11-05 19:46 ` Eli Zaretskii 2005-11-05 17:39 ` Luc Teirlinck 1 sibling, 1 reply; 69+ messages in thread From: Drew Adams @ 2005-11-05 17:33 UTC (permalink / raw) I think the idea was that a list of words is more natural input at that point than a regexp. People nowadays are used to Google-style queries more than to regexps. FWIW, I rarely myself use regexps in apropos. Why try to mix regexp input with keyword input in the same command? That's just asking for trouble. Why not have two different commands - `apropos-with-keywords' and `apropos'? That's a cleaner way to add treatment of keywords. (Worse, but still better than this amalgam, would be to extend the `C-u' options to provide for keyword input. The default should be the traditional, regexp behavior, however.) Sorry, I missed the original discussion. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 17:33 ` Drew Adams @ 2005-11-05 19:46 ` Eli Zaretskii 2005-11-05 20:38 ` Drew Adams 0 siblings, 1 reply; 69+ messages in thread From: Eli Zaretskii @ 2005-11-05 19:46 UTC (permalink / raw) Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Sat, 5 Nov 2005 09:33:12 -0800 > > I think the idea was that a list of words is more natural input at > that point than a regexp. People nowadays are used to Google-style > queries more than to regexps. FWIW, I rarely myself use regexps in > apropos. > > Why try to mix regexp input with keyword input in the same command? That's > just asking for trouble. Why not have two different commands - > `apropos-with-keywords' and `apropos'? That's a cleaner way to add treatment > of keywords. Please be sure to read the discussions about the various aspects of this feature. It starts here: http://lists.gnu.org/archive/html/emacs-devel/2002-05/msg00397.html You will see that I already suggested back then to have a separate command, in this message: http://lists.gnu.org/archive/html/emacs-devel/2002-05/msg00400.html The ensuing discussion mentioned some drawbacks of that suggestion. ^ permalink raw reply [flat|nested] 69+ messages in thread
* RE: new apropos feature in Emacs-22 2005-11-05 19:46 ` Eli Zaretskii @ 2005-11-05 20:38 ` Drew Adams 2005-11-05 22:10 ` Luc Teirlinck 2005-11-05 23:00 ` Kim F. Storm 0 siblings, 2 replies; 69+ messages in thread From: Drew Adams @ 2005-11-05 20:38 UTC (permalink / raw) Please be sure to read the discussions about the various aspects of this feature. It starts here: http://lists.gnu.org/archive/html/emacs-devel/2002-05/msg00397.html You will see that I already suggested back then to have a separate command, in this message: http://lists.gnu.org/archive/html/emacs-devel/2002-05/msg00400.html The ensuing discussion mentioned some drawbacks of that suggestion. Thanks for the links. I'll keep quiet after this - suffice it to say that I don't agree with this new feature, and the "drawbacks" mentioned to using a separate command were skimpy. 80% of that thread was about how to implement a keyword-search feature within apropos, not whether or not that was a good idea. This was the only "drawback" that I saw mentioned in the whole thread (please correct me, if I missed something): - All apropos commands should `accept the same type of "search patterns".' And this question was raised, but not pursued (that I saw): `What would apropos-keywords look for? `commands', `variables' `documentation', or "all of the above" ?' That one "drawback" wasn't discussed at all, that I saw. I don't see _why_ all apropos commands _should_ accept the same type of "search patterns" - what is the argument for this? I didn't see any. Are we perhaps worried about people _expecting_ that all commands that have the word "apropos" in their names behave the same way wrt input (unlikely, IMO)? Is that the unstated worry? If so: 1) I think that's being a bit skittish. 2) We could, instead, introduce a command (or a whole series of different commands, to respond to the question raised but not answered) that uses keywords and does _not_ have the word "apropos" in its name. If that (the name) is the only real concern, then let us choose a different name for the keyword-search command(s) (hey, how about `keyword-search'?) How did the (useful!) feature of keyword search get injected and locked into the existing apropos commands? (Virus? ;-)) As I said, we're asking for trouble by trying to mix regexp syntax and keyword syntax. The former is confusing enough - imagine how it will be when people fall into it by accident! My bet is that neither the regexp syntax nor the keyword syntax will be clear cut or work well. Now, I'll shut up, after one last request: Can we please have available some function(s) that will give the original, regexp-syntax-only behavior, so that we may individually get back to something reasonable? That is, can we have functions (not necessarily aimed at novices) that we can use to build commands that do what the apropos family did before? It could be `apropos-internal' (plus equivalents for doc etc.) - or something else, if `apropos-internal' has already been infected too ;-). ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 20:38 ` Drew Adams @ 2005-11-05 22:10 ` Luc Teirlinck 2005-11-05 23:00 ` Kim F. Storm 1 sibling, 0 replies; 69+ messages in thread From: Luc Teirlinck @ 2005-11-05 22:10 UTC (permalink / raw) Cc: emacs-devel Drew Adams wrote: The default should be the traditional, regexp behavior, however. I believe that the idea was to make apropos easier for inexperienced users knowing little about regexps. But the present functionality still can easily confuse such users for very natural keywords like *scratch*, .emacs or ses+. Now, I'll shut up, after one last request: Can we please have available some function(s) that will give the original, regexp-syntax-only behavior, so that we may individually get back to something reasonable? That is, can we have functions (not necessarily aimed at novices) that we can use to build commands that do what the apropos family did before? I see as solutions, in order of preference: 1. A proper syntactic convention that uses keyword search for some invalid regexp: unbalanced [, final \, whatever. 2. A customizable option for all apropos commands, that specifies either keyword lists only, or regexps only, or, for people who do not mind about unreliable and potentially confusing heuristics, the present behavior. To be friendly to people uncomfortable with regexps, keywords only could be the default. If the present behavior is kept unchanged, then at least it should be documented properly, with the potential pitfalls clearly pointed out, both in the docstrings and the Emacs manual. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 20:38 ` Drew Adams 2005-11-05 22:10 ` Luc Teirlinck @ 2005-11-05 23:00 ` Kim F. Storm 2005-11-05 23:18 ` Lennart Borgman ` (2 more replies) 1 sibling, 3 replies; 69+ messages in thread From: Kim F. Storm @ 2005-11-05 23:00 UTC (permalink / raw) Cc: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > Thanks for the links. I'll keep quiet after this - suffice it to say that I > don't agree with this new feature, and the "drawbacks" mentioned to using a > separate command were skimpy. There was one major reason for this change, and that reason has not changed: To make it easier for the emacs "novice" to find information with apropos. The assumption is that most users will be accustomed to use keyword search, and only the experts will use regular expressions. So we changed the standard apropos commands to accept keywords, and to keep things simple, we chose the simple rule of "any two words matches". Personally, I would have preferred to let apropos use keywords only (and I haven't used regexps in apropos since this change was made), but as a compromise, we retained regexp matching if the search pattern looks like a regexp (and an expert user know how you can easily specify " +" for a space to force the old semantics). > That one "drawback" wasn't discussed at all, that I saw. I don't see _why_ > all apropos commands _should_ accept the same type of "search patterns" - > what is the argument for this? I didn't see any. IMO, it is the only logical thing to do. I never thought I'd have to argue about that... > Are we perhaps worried about people _expecting_ that all commands that have > the word "apropos" in their names behave the same way wrt input (unlikely, > IMO)? Is that the unstated worry? If so: > > 1) I think that's being a bit skittish. It's being "user friendly", and specifically "novice user friendly". > 2) We could, instead, introduce a command (or a whole series of different > commands, to respond to the question raised but not answered) that uses > keywords and does _not_ have the word "apropos" in its name. If that (the > name) is the only real concern, then let us choose a different name for the > keyword-search command(s) (hey, how about `keyword-search'?) _If_ we were to change the current situation, we should make the normal commands accept keywords only, and make new commands for regexp matches. > How did the (useful!) feature of keyword search get injected and locked into > the existing apropos commands? (Virus? ;-)) > > As I said, we're asking for trouble by trying to mix regexp syntax and > keyword syntax. The former is confusing enough - imagine how it will be when > people fall into it by accident! My bet is that neither the regexp syntax > nor the keyword syntax will be clear cut or work well. I doubt this is a real problem. Do you have any evidence (actual user complaints) to prove your case? A user falling into this by accident will probably rephrase the query and try again. Just like goggling may require a few different sets of keywords before you find something useful. And the prompt does say ... (regexp or words), so if the user gets a lot of false hits, there is a clue to what went wrong. > > Now, I'll shut up, after one last request: > > Can we please have available some function(s) that will give the original, > regexp-syntax-only behavior, so that we may individually get back to > something reasonable? That is, can we have functions (not necessarily aimed > at novices) that we can use to build commands that do what the apropos > family did before? It could be `apropos-internal' (plus equivalents for doc > etc.) - or something else, if `apropos-internal' has already been infected > too ;-). I don't understand why you need this. If you (as an expert user) want regexp mathing, specify a regexp -- it's as simple as that! E.g. instead of "find file" (keyword search), write "find +file" (regexp). But I agree that the doc strings could be improved. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 23:00 ` Kim F. Storm @ 2005-11-05 23:18 ` Lennart Borgman 2005-11-05 23:28 ` Luc Teirlinck 2005-11-05 23:31 ` Drew Adams 2005-11-05 23:21 ` Drew Adams 2005-11-06 1:57 ` Luc Teirlinck 2 siblings, 2 replies; 69+ messages in thread From: Lennart Borgman @ 2005-11-05 23:18 UTC (permalink / raw) Cc: Drew Adams, emacs-devel Kim F. Storm wrote: >_If_ we were to change the current situation, we should make the normal >commands accept keywords only, and make new commands for regexp matches. > > I remember I was confused by this. May I suggest a simple solution: - Use keyword matching as default (ie like now really) - If something looking like a regexp was entered then enter a simple y-or-n-p and ask the user if it is a regexp. Hm. That is for interactive use of course. Maybe a parameter too ... Well, I do not know if this is the right solution. Whatever we decide on help functions must not be confusing! ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 23:18 ` Lennart Borgman @ 2005-11-05 23:28 ` Luc Teirlinck 2005-11-05 23:37 ` Lennart Borgman 2005-11-05 23:31 ` Drew Adams 1 sibling, 1 reply; 69+ messages in thread From: Luc Teirlinck @ 2005-11-05 23:28 UTC (permalink / raw) Cc: emacs-devel, drew.adams, storm Lennart Borgman wrote: - If something looking like a regexp was entered Most strings are valid regexps. Only a few exceptions are not. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 23:28 ` Luc Teirlinck @ 2005-11-05 23:37 ` Lennart Borgman 0 siblings, 0 replies; 69+ messages in thread From: Lennart Borgman @ 2005-11-05 23:37 UTC (permalink / raw) Cc: storm, drew.adams, emacs-devel Luc Teirlinck wrote: >Lennart Borgman wrote: > > - If something looking like a regexp was entered > >Most strings are valid regexps. Only a few exceptions are not. > > Yes, but most strings does not look as regexps ;-) ^ permalink raw reply [flat|nested] 69+ messages in thread
* RE: new apropos feature in Emacs-22 2005-11-05 23:18 ` Lennart Borgman 2005-11-05 23:28 ` Luc Teirlinck @ 2005-11-05 23:31 ` Drew Adams 2005-11-05 23:36 ` Drew Adams 2005-11-05 23:39 ` Lennart Borgman 1 sibling, 2 replies; 69+ messages in thread From: Drew Adams @ 2005-11-05 23:31 UTC (permalink / raw) Hi Lennart, May I suggest a __simple___ solution: It's a joke, right? ;-) - Use keyword matching as default (ie like now really) - If something looking like a regexp was entered then enter a simple y-or-n-p and ask the user if it is a regexp. Hm. That is for interactive use of course. Maybe a parameter too ... Well, I do not know if this is the right solution. Whatever we decide on help functions must not be confusing! Do you see? Do you see the complexity and confusion that creeps in when two completely different syntaxes and different use cases are mixed up together in the same command? We're forced to pile on hack after hack to disambiguate the two cases. "Is this intended as a regexp?" "Do you really want to use a regexp?" Plus a parameter for non-interactive... Plus an error message or two... Plus... And Luc: Add a signal-character at the end, to indicate that it's really a regexp... This is not the way to go. I have not seen one argument for _not_ using separate commands (or command families): 1) keyword-search commands, 2) regexp-search commands. Call #1 "apropos" and #2 "about-regexp" if you like, but let's not try to mix them in the same command. Best, Drew ^ permalink raw reply [flat|nested] 69+ messages in thread
* RE: new apropos feature in Emacs-22 2005-11-05 23:31 ` Drew Adams @ 2005-11-05 23:36 ` Drew Adams 2005-11-05 23:39 ` Lennart Borgman 1 sibling, 0 replies; 69+ messages in thread From: Drew Adams @ 2005-11-05 23:36 UTC (permalink / raw) I meant to send that reply to Lennart, not to the list. I'm truly sorry. - Drew Hi Lennart, ... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 23:31 ` Drew Adams 2005-11-05 23:36 ` Drew Adams @ 2005-11-05 23:39 ` Lennart Borgman 1 sibling, 0 replies; 69+ messages in thread From: Lennart Borgman @ 2005-11-05 23:39 UTC (permalink / raw) Cc: emacs-devel Drew Adams wrote: >Hi Lennart, > > May I suggest a __simple___ solution: > >It's a joke, right? ;-) > > No.... but I will not defend it ;-) ^ permalink raw reply [flat|nested] 69+ messages in thread
* RE: new apropos feature in Emacs-22 2005-11-05 23:00 ` Kim F. Storm 2005-11-05 23:18 ` Lennart Borgman @ 2005-11-05 23:21 ` Drew Adams 2005-11-06 1:57 ` Luc Teirlinck 2 siblings, 0 replies; 69+ messages in thread From: Drew Adams @ 2005-11-05 23:21 UTC (permalink / raw) _If_ we were to change the current situation, we should make the normal commands accept keywords only, and make new commands for regexp matches. Sold!! That works, for me - I don't care what names we give the commands. They should be separate commands (regexp vs keyword) - that's all. `apropos' for keywords and `foobar' for regexps is fine by me. I still haven't seen an argument against keeping the two kinds of search separate, in separate commands - what's the drawback? Go ahead and reserve the name "apropos" for keyword search - no problem. Please don't make Norman Newbie wonder what black hole he fell down because he messed up the syntax... "Novice user friendly", indeed. (I said I'd shut up, so I'll skip the line-by-line.) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 23:00 ` Kim F. Storm 2005-11-05 23:18 ` Lennart Borgman 2005-11-05 23:21 ` Drew Adams @ 2005-11-06 1:57 ` Luc Teirlinck 2005-11-06 4:32 ` Eli Zaretskii 2 siblings, 1 reply; 69+ messages in thread From: Luc Teirlinck @ 2005-11-06 1:57 UTC (permalink / raw) Cc: drew.adams, emacs-devel Kim Storm wrote: Personally, I would have preferred to let apropos use keywords only (and I haven't used regexps in apropos since this change was made), but as a compromise, One more example that compromises can be way worse than any of the alternatives they compromise between. In order of preference, I would distinguish between regexps and keyword lists (or individual keywords) by (1) an unambiguous notational convention, (2) by a user option, or (3) by a combination of user option and separate functions. The separate functions would call the regular functions while binding the user option. we retained regexp matching if the search pattern looks like a regexp You are trying to do the impossible. "*scratch*" is clearly intended as a literal keyword and "home directory" is likely to be meant as a regexp, but your code concludes exactly the opposite. No code can decide whether something "looks like a regexp". I doubt this is a real problem. Do you have any evidence (actual user complaints) to prove your case? The current code has only been tested in CVS, by people familiar with regexps. Such people are aware that specifying *scratch*, .emacs or ses+ as keywords is not going to work and know how to write the proper regexps to get around that. The assumption is that most users will be accustomed to use keyword search, and only the experts will use regular expressions. Are you sure that most newbies are accustomed to _your brand of_ keyword search: at least two alternatives in any order, with no way to specify other requirements, _and_ with plenty of forbidden characters, that are natural in an Emacs context, like `*', `.' `+'? I never encountered that before. In the keyword searches that I am familiar with you can enclose the keywords in quotation marks to force sequential in order occurrence. When doing web searches I nearly invariably use quotation marks. Moreover, in all keyword searches that I am familiar with, it is perfectly possible to specify keywords like *scratch*, .emacs or ses+. I believe that after your change, newbies _still_ will have to learn about regexps to accomplish what they are used to in search engines. The only difference is that extra complexity and confusion is added on top of the normal regexp rules. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 1:57 ` Luc Teirlinck @ 2005-11-06 4:32 ` Eli Zaretskii 2005-11-06 5:36 ` Luc Teirlinck 2005-11-06 9:19 ` David Kastrup 0 siblings, 2 replies; 69+ messages in thread From: Eli Zaretskii @ 2005-11-06 4:32 UTC (permalink / raw) Cc: emacs-devel > Date: Sat, 5 Nov 2005 19:57:38 -0600 (CST) > From: Luc Teirlinck <teirllm@dms.auburn.edu> > Cc: drew.adams@oracle.com, emacs-devel@gnu.org > > Are you sure that most newbies are accustomed to _your brand of_ > keyword search: at least two alternatives in any order, with no way to > specify other requirements, _and_ with plenty of forbidden characters, > that are natural in an Emacs context, like `*', `.' `+'? Whether newbies are accustomed to this remains to be proven, but the characters ``natural in the Emacs context'' above come from an experienced user. > In the keyword searches that I am familiar with you can enclose the > keywords in quotation marks to force sequential in order occurrence. That's an advanced feature, you know. > I believe that after your change, newbies _still_ will have to learn > about regexps to accomplish what they are used to in search engines. Please explain why you think so. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 4:32 ` Eli Zaretskii @ 2005-11-06 5:36 ` Luc Teirlinck 2005-11-06 17:05 ` Eli Zaretskii 2005-11-06 18:47 ` Kim F. Storm 2005-11-06 9:19 ` David Kastrup 1 sibling, 2 replies; 69+ messages in thread From: Luc Teirlinck @ 2005-11-06 5:36 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii wrote: Whether newbies are accustomed to this remains to be proven, but the characters ``natural in the Emacs context'' above come from an experienced user. .emacs and *scratch* are only for experienced users? > In the keyword searches that I am familiar with you can enclose the > keywords in quotation marks to force sequential in order occurrence. That's an advanced feature, you know. Really? I always use quotation marks in websearches and would not know how to search without them. For instance, Richard asked us for a string that gave him all postings in the old thread we are talking about and nothing else and I said: "apropos commands and regexps" (_with_ the quotation marks included). It works. Exactly all 56 postings in the thread, nothing else, `apropos commands' without quotation marks gives 124 hits, 56 correct ones and 68 false ones. With the at least two hits rule, specifying additional keywords makes things worse. > I believe that after your change, newbies _still_ will have to learn > about regexps to accomplish what they are used to in search engines. Please explain why you think so. Several reasons. Because you may want to search for, say, the words "overwrite mode" in that order, separated only by non-word constituents. The fact that "mode" occurs somewhere in a doc string and "overwrite" somewhere else is usually completely irrelevant and produces many false hits. Sequential occurrence is _much_ less likely to be an accident than two distinct keywords matching miles away in unrelated contexts. Just do: M-x apropos-documentation RET overwrite mode RET and then: `C-s overwrite' and you will notice that the vast majority of the matches in the 919 lines long buffer have absolutely nothing to do with overwrite mode. _And_ because sometimes you might want to search for keywords containing characters that happen to be special in regexps, say .emacs, .mailrc, whatever. Why are these only for experienced users? Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 5:36 ` Luc Teirlinck @ 2005-11-06 17:05 ` Eli Zaretskii 2005-11-06 17:22 ` David Kastrup ` (2 more replies) 2005-11-06 18:47 ` Kim F. Storm 1 sibling, 3 replies; 69+ messages in thread From: Eli Zaretskii @ 2005-11-06 17:05 UTC (permalink / raw) Cc: emacs-devel > Date: Sat, 5 Nov 2005 23:36:17 -0600 (CST) > From: Luc Teirlinck <teirllm@dms.auburn.edu> > CC: emacs-devel@gnu.org > > Eli Zaretskii wrote: > > Whether newbies are accustomed to this remains to be proven, but the > characters ``natural in the Emacs context'' above come from an > experienced user. > > .emacs and *scratch* are only for experienced users? You were talking about `.', `+', and `*' in general. And yes, at least *scratch* is not something an unexperienced user will look for, I think. > > In the keyword searches that I am familiar with you can enclose the > > keywords in quotation marks to force sequential in order occurrence. > > That's an advanced feature, you know. > > Really? I always use quotation marks in websearches Then in my experience, you are a minority. > and would not know how to search without them. Just lose the quotes, it works ;-) > For instance, Richard asked us for a > string that gave him all postings in the old thread we are talking > about and nothing else and I said: > > "apropos commands and regexps" (_with_ the quotation marks included). > > It works. It could also misfire, e.g., if the actual phrase in the archives is "regexps and apropos commands". If you lose the quotes (and "and" as well), you will find it regardless of the order. In general, quotes are useful only if you know _exactly_ how the phrase appears in the text, which is a relatively rare situation. (I'm sure you know all this already.) > > I believe that after your change, newbies _still_ will have to learn > > about regexps to accomplish what they are used to in search engines. > > Please explain why you think so. > > Several reasons. > > Because you may want to search for, say, the words "overwrite mode" in > that order, separated only by non-word constituents. That's your ``always use quotes'' rule again; see above for why it might not be useful for someone (like a newbie) who does not know the exact phrase she is looking for. > The fact that "mode" occurs somewhere in a doc string and > "overwrite" somewhere else is usually completely irrelevant and > produces many false hits. False hits is a downside of any search engine (including `apropos' in its pre-Emacs22 incarnation, btw). Scoring and sorting according to score--a new feature introduced together with the one we are discussing--are supposed to alleviate that. > Sequential occurrence is _much_ less likely to be an accident Yes, _if_ you know the exact phrase. A rather big IF, I'd say. Mostly false for newbies, in my experience. > _And_ because sometimes you might want to search for keywords > containing characters that happen to be special in regexps, say > .emacs, .mailrc, whatever. A regexp ".emacs" will find a literal ".emacs", so this is not a big problem. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 17:05 ` Eli Zaretskii @ 2005-11-06 17:22 ` David Kastrup 2005-11-06 18:43 ` Eli Zaretskii 2005-11-06 18:31 ` Luc Teirlinck 2005-11-06 20:16 ` Luc Teirlinck 2 siblings, 1 reply; 69+ messages in thread From: David Kastrup @ 2005-11-06 17:22 UTC (permalink / raw) Cc: Luc Teirlinck, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Date: Sat, 5 Nov 2005 23:36:17 -0600 (CST) >> From: Luc Teirlinck <teirllm@dms.auburn.edu> >> _And_ because sometimes you might want to search for keywords >> containing characters that happen to be special in regexps, say >> .emacs, .mailrc, whatever. > > A regexp ".emacs" will find a literal ".emacs", so this is not a big > problem. But it will also find "XEmacs" for an innocent little search term like that. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 17:22 ` David Kastrup @ 2005-11-06 18:43 ` Eli Zaretskii 0 siblings, 0 replies; 69+ messages in thread From: Eli Zaretskii @ 2005-11-06 18:43 UTC (permalink / raw) Cc: teirllm, emacs-devel > Cc: Luc Teirlinck <teirllm@dms.auburn.edu>, emacs-devel@gnu.org > From: David Kastrup <dak@gnu.org> > Date: Sun, 06 Nov 2005 18:22:37 +0100 > > > A regexp ".emacs" will find a literal ".emacs", so this is not a big > > problem. > > But it will also find "XEmacs" for an innocent little search term like > that. Yes, and why is that a problem? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 17:05 ` Eli Zaretskii 2005-11-06 17:22 ` David Kastrup @ 2005-11-06 18:31 ` Luc Teirlinck 2005-11-06 18:46 ` Eli Zaretskii 2005-11-07 21:54 ` Richard M. Stallman 2005-11-06 20:16 ` Luc Teirlinck 2 siblings, 2 replies; 69+ messages in thread From: Luc Teirlinck @ 2005-11-06 18:31 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii wrote: > _And_ because sometimes you might want to search for keywords > containing characters that happen to be special in regexps, say > .emacs, .mailrc, whatever. A regexp ".emacs" will find a literal ".emacs", so this is not a big problem. With the current code, ".emacs init file" will trigger a regexp search, whereas a newbie user unfamiliar with regexps might have expected the usual "at least two matches" behavior. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 18:31 ` Luc Teirlinck @ 2005-11-06 18:46 ` Eli Zaretskii 2005-11-07 9:45 ` Alan Mackenzie 2005-11-07 21:54 ` Richard M. Stallman 1 sibling, 1 reply; 69+ messages in thread From: Eli Zaretskii @ 2005-11-06 18:46 UTC (permalink / raw) Cc: emacs-devel > Date: Sun, 6 Nov 2005 12:31:27 -0600 (CST) > From: Luc Teirlinck <teirllm@dms.auburn.edu> > CC: emacs-devel@gnu.org > > With the current code, ".emacs init file" will trigger a regexp > search, whereas a newbie user unfamiliar with regexps might have > expected the usual "at least two matches" behavior. A search engine quite frequently brings unexpected matches, based on its convoluted heuristics. Perhaps you are unfamiliar with that phenomenon because you tend to use quoted phrases (which defeat those heuristics), but it's normal for majority of users I've seen. Searching large bodies of text will never be an exact science. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 18:46 ` Eli Zaretskii @ 2005-11-07 9:45 ` Alan Mackenzie 2005-11-07 20:43 ` Eli Zaretskii 2005-11-07 20:58 ` Eli Zaretskii 0 siblings, 2 replies; 69+ messages in thread From: Alan Mackenzie @ 2005-11-07 9:45 UTC (permalink / raw) Cc: emacs-devel On Sun, 6 Nov 2005, Eli Zaretskii wrote: >> With the current code, ".emacs init file" will trigger a regexp >> search, whereas a newbie user unfamiliar with regexps might have >> expected the usual "at least two matches" behavior. >A search engine quite frequently brings unexpected matches, based on its >convoluted heuristics. Perhaps you are unfamiliar with that phenomenon >because you tend to use quoted phrases (which defeat those heuristics), >but it's normal for majority of users I've seen. I don't think this is an attribute that Emacs should emulate. I have frequently cursed the inability of search engines to accept regular expressions as input. Surely an Emacs user should be able to formulate a search criterion without having to jump through hoops of dwimmyness, without the uncertainty of not knowing how Emacs interprets his search string. As David Kastrup points out, these uncertainties come up in search strings that will be used all the time, not occasional things that will occur once in a blue moon. Searching for a regular expression and searching for a match to any of a list of keywords are distinct operations. Surely they should have distinct commands too. -- Alan Mackenzie (Munich, Germany) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-07 9:45 ` Alan Mackenzie @ 2005-11-07 20:43 ` Eli Zaretskii 2005-11-07 20:58 ` Eli Zaretskii 1 sibling, 0 replies; 69+ messages in thread From: Eli Zaretskii @ 2005-11-07 20:43 UTC (permalink / raw) Cc: emacs-devel > Date: Mon, 7 Nov 2005 09:45:11 +0000 (GMT) > From: Alan Mackenzie <acm@muc.de> > cc: emacs-devel@gnu.org > > On Sun, 6 Nov 2005, Eli Zaretskii wrote: > > >> With the current code, ".emacs init file" will trigger a regexp > >> search, whereas a newbie user unfamiliar with regexps might have > >> expected the usual "at least two matches" behavior. > > >A search engine quite frequently brings unexpected matches, based on its > >convoluted heuristics. Perhaps you are unfamiliar with that phenomenon > >because you tend to use quoted phrases (which defeat those heuristics), > >but it's normal for majority of users I've seen. > > I don't think this is an attribute that Emacs should emulate. We are not emulating any behavior, we just get hit by the same problems as other search engines. > Surely an Emacs user should be able to formulate a search criterion > without having to jump through hoops of dwimmyness, without the > uncertainty of not knowing how Emacs interprets his search string. As > David Kastrup points out, these uncertainties come up in search strings > that will be used all the time, not occasional things that will occur > once in a blue moon. You are talking about something completely unrelated to what I was saying. While that's okay, why start it by quoting me? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-07 9:45 ` Alan Mackenzie 2005-11-07 20:43 ` Eli Zaretskii @ 2005-11-07 20:58 ` Eli Zaretskii 1 sibling, 0 replies; 69+ messages in thread From: Eli Zaretskii @ 2005-11-07 20:58 UTC (permalink / raw) Cc: emacs-devel > Date: Mon, 7 Nov 2005 09:45:11 +0000 (GMT) > From: Alan Mackenzie <acm@muc.de> > Cc: emacs-devel@gnu.org > > I have frequently cursed the inability of search engines to accept > regular expressions as input. Which ones? Numazu, for example, does support regexps. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 18:31 ` Luc Teirlinck 2005-11-06 18:46 ` Eli Zaretskii @ 2005-11-07 21:54 ` Richard M. Stallman 1 sibling, 0 replies; 69+ messages in thread From: Richard M. Stallman @ 2005-11-07 21:54 UTC (permalink / raw) Cc: eliz, emacs-devel With the current code, ".emacs init file" will trigger a regexp search, whereas a newbie user unfamiliar with regexps might have expected the usual "at least two matches" behavior. Perhaps we should change the criteria so that a period does not make it a regexp. A different criterion would be ok as long as it is simple. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 17:05 ` Eli Zaretskii 2005-11-06 17:22 ` David Kastrup 2005-11-06 18:31 ` Luc Teirlinck @ 2005-11-06 20:16 ` Luc Teirlinck 2005-11-06 22:54 ` Kim F. Storm 2 siblings, 1 reply; 69+ messages in thread From: Luc Teirlinck @ 2005-11-06 20:16 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii wrote: That's your ``always use quotes'' rule again; see above for why it might not be useful for someone (like a newbie) who does not know the exact phrase she is looking for. Phrases like "global font lock mode" or "text only terminal" are conceptually single items, even though, without quoting, to the computer they look like four or three unrelated keywords. That is exactly why one _needs_ quoting in searches. A newbie using apropos can not be assumed to be 100% ignorant: one way or the other he managed to find out about the apropos commands. So he should be familiar with at least some multi-word phrases that are conceptually a single item. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 20:16 ` Luc Teirlinck @ 2005-11-06 22:54 ` Kim F. Storm 0 siblings, 0 replies; 69+ messages in thread From: Kim F. Storm @ 2005-11-06 22:54 UTC (permalink / raw) Cc: eliz, emacs-devel Luc Teirlinck <teirllm@dms.auburn.edu> writes: > Eli Zaretskii wrote: > > That's your ``always use quotes'' rule again; see above for why it > might not be useful for someone (like a newbie) who does not know the > exact phrase she is looking for. > > Phrases like "global font lock mode" or "text only terminal" are > conceptually single items, even though, without quoting, to the > computer they look like four or three unrelated keywords. That is > exactly why one _needs_ quoting in searches. With apropos-sort-by-scores turned on, apropos-documentation returns the following entries for "global font lock mode" (in this sequence): global-font-lock-mode Command: Toggle Font-Lock mode in every buffer. font-lock-mode Command: Toggle Font Lock mode. font-lock-global-modes Variable: *Modes for which Font Lock mode is automagically turned on. hi-lock-mode Command: Toggle minor mode for interactively adding font-lock highlighting patterns. font-lock-support-mode Variable: *Support mode for Font Lock mode. jit-lock-mode Function: Toggle Just-in-time Lock mode. {the list is much longer, but most entries have some relevance} On the other hand, if you search for the regexp "global font lock mode", you get just two entries (not including the obvious "global-font-lock-mode"): font-lock-global-modes Variable: *Modes for which Font Lock mode is automagically turned on. font-lock-mode Command: Toggle Font Lock mode. BTW, I strongly doubt that any novice user will search for anything remotely similar to "font lock". Instead they will search for "syntax highlighting" -- where regexp and keyword search produces similar results -- or they will search for "highlight syntax" where regexp shows nothing, while keywords show that same result as before. To me it is a bit strange that someone who favours regexp search is so worried about the potential pitfalls of the novice, while those of us who advocate keyword searches don't see the big problem... > A newbie using apropos can not be assumed to be 100% ignorant: one way > or the other he managed to find out about the apropos commands. So he > should be familiar with at least some multi-word phrases that are > conceptually a single item. And keyword search will find then -- and place them high on the list with sort-by-score enabled. In any case, I'll try to make some corrections to the scoring algorithm to make it behave better when the search string/regexp matches literally as well as a regexp (e.g. for .emacs or *scratch*). It's almost there, but there are a few rough edges... -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 5:36 ` Luc Teirlinck 2005-11-06 17:05 ` Eli Zaretskii @ 2005-11-06 18:47 ` Kim F. Storm 2005-11-06 19:19 ` Luc Teirlinck ` (2 more replies) 1 sibling, 3 replies; 69+ messages in thread From: Kim F. Storm @ 2005-11-06 18:47 UTC (permalink / raw) Cc: eliz, emacs-devel Luc Teirlinck <teirllm@dms.auburn.edu> writes: > > Because you may want to search for, say, the words "overwrite mode" in > that order, separated only by non-word constituents. The fact that > "mode" occurs somewhere in a doc string and "overwrite" somewhere else > is usually completely irrelevant and produces many false hits. > Sequential occurrence is _much_ less likely to be an accident than two > distinct keywords matching miles away in unrelated contexts. Just do: > > M-x apropos-documentation RET overwrite mode RET > > and then: `C-s overwrite' and you will notice that the vast majority > of the matches in the 919 lines long buffer have absolutely nothing to > do with overwrite mode. If we set apropos-sort-by-scores to t, then the most relevant entries would be listed first. The lesser important entries are showed later. IIRC, sort by scores was not turned on by default because it was said to confuse people who expect at least the simple apropos commands to list e.g. variables and functions in alphabetical order. But for apropos-documentation, it doesn't really make much sense to ever sort things alphabetically, so maybe it makes sense to unconditionally set apropos-sort-by-scores to t for apropos-documentation. Then the "false matches" will at least be listed after the good ones. A patch is attached below. It seems to improve things "a lot". > _And_ because sometimes you might want to search for keywords > containing characters that happen to be special in regexps, say > .emacs, .mailrc, whatever. Why are these only for experienced users? Yes, .emacs is a hard one -- but it is a very special case IMO. Perhaps we could make an expection for it. In any case C-s .emacs easily finds the relevant matches. Did you try to do C-h C-d .mailrc ? I don't see any false matches there. And for C-h C-d *scratch* RET, it finds all the relevant matches AFAICS. I still don't see the "serious" problem here. *** apropos.el 19 Sep 2005 00:24:21 +0200 1.106 --- apropos.el 06 Nov 2005 19:04:04 +0100 *************** *** 106,114 **** (defcustom apropos-sort-by-scores nil "*Non-nil means sort matches by scores; best match is shown first. ! The computed score is shown for each match." :group 'apropos ! :type 'boolean) (defvar apropos-mode-map (let ((map (make-sparse-keymap))) --- 106,116 ---- (defcustom apropos-sort-by-scores nil "*Non-nil means sort matches by scores; best match is shown first. ! If value is `verbose', the computed score is shown for each match." :group 'apropos ! :type '(choice (const :tag "off" nil) ! (const :tag "on" t) ! (const :tag "show scores" verbose))) (defvar apropos-mode-map (let ((map (make-sparse-keymap))) *************** *** 570,575 **** --- 572,578 ---- (or do-all (setq do-all apropos-do-all)) (setq apropos-accumulator () apropos-files-scanned ()) (let ((standard-input (get-buffer-create " apropos-temp")) + (apropos-sort-by-scores (or apropos-sort-by-scores t)) ;; verbose? f v sf sv) (unwind-protect (save-excursion *************** *** 822,828 **** ;; changed the variable! ;; Just say `no' to variables containing faces! 'face apropos-symbol-face) ! (if apropos-sort-by-scores (insert " (" (number-to-string (cadr apropos-item)) ") ")) ;; Calculate key-bindings if we want them. (and do-keys --- 825,831 ---- ;; changed the variable! ;; Just say `no' to variables containing faces! 'face apropos-symbol-face) ! (if (eq apropos-sort-by-scores 'verbose) (insert " (" (number-to-string (cadr apropos-item)) ") ")) ;; Calculate key-bindings if we want them. (and do-keys ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 18:47 ` Kim F. Storm @ 2005-11-06 19:19 ` Luc Teirlinck 2005-11-07 7:04 ` Luc Teirlinck 2005-11-07 21:55 ` Richard M. Stallman 2 siblings, 0 replies; 69+ messages in thread From: Luc Teirlinck @ 2005-11-06 19:19 UTC (permalink / raw) Cc: eliz, emacs-devel Yes, .emacs is a hard one -- but it is a very special case IMO. This is just an example, of course. Plenty of standard files (most, actually) have `.'s in their names, plenty of standard buffers (most of them) have `*'s in their names, several functions have *'s in their names, say let* or list*, several variables have *'s in their names (cl actually has tons of these variables and functions), some have `+' in their name. I can go on and on. Most of the characters that are "special" in regexps are common outside of regexps too. Did you try to do C-h C-d .mailrc ? Is that a personal binding of yours? For me, C-h C-d runs `describe-distribution'. Did you try to do C-h C-d .mailrc ? I don't see any false matches there. And for C-h C-d *scratch* RET, it finds all the relevant matches AFAICS. I still don't see the "serious" problem here. The problem is that a if you put .mailrc, *scratch*, let* or whatever in a list of keywords, then that list of keywords turns into a regexp. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 18:47 ` Kim F. Storm 2005-11-06 19:19 ` Luc Teirlinck @ 2005-11-07 7:04 ` Luc Teirlinck 2005-11-07 21:55 ` Richard M. Stallman 2 siblings, 0 replies; 69+ messages in thread From: Luc Teirlinck @ 2005-11-07 7:04 UTC (permalink / raw) Cc: eliz, emacs-devel Kin Storm wrote: Did you try to do C-h C-d .mailrc ? I don't see any false matches there. (I guess you somehow mean `M-x apropos-documentation' instead of `C-h C-d'.) Just to make sure that you understand the real problem: with the current code, `mail alias .mailrc' will not match the text "mail alias in your .mailrc file" although a user unfamiliar with regexps and familiar with your "at least two matches" rule would expect it to match. But, if we go for Stefan's solution, that problem would disappear anyway. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 18:47 ` Kim F. Storm 2005-11-06 19:19 ` Luc Teirlinck 2005-11-07 7:04 ` Luc Teirlinck @ 2005-11-07 21:55 ` Richard M. Stallman 2 siblings, 0 replies; 69+ messages in thread From: Richard M. Stallman @ 2005-11-07 21:55 UTC (permalink / raw) Cc: eliz, teirllm, emacs-devel Your patch for three values of apropos-sort-by-scores is good. The idea of always showing scores for apropos-documentation also seems good, but I think there should be a separate variable for that; it shouldn't be forced to t. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 4:32 ` Eli Zaretskii 2005-11-06 5:36 ` Luc Teirlinck @ 2005-11-06 9:19 ` David Kastrup 1 sibling, 0 replies; 69+ messages in thread From: David Kastrup @ 2005-11-06 9:19 UTC (permalink / raw) Cc: Luc Teirlinck, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Date: Sat, 5 Nov 2005 19:57:38 -0600 (CST) >> From: Luc Teirlinck <teirllm@dms.auburn.edu> >> Cc: drew.adams@oracle.com, emacs-devel@gnu.org >> >> Are you sure that most newbies are accustomed to _your brand of_ >> keyword search: at least two alternatives in any order, with no way to >> specify other requirements, _and_ with plenty of forbidden characters, >> that are natural in an Emacs context, like `*', `.' `+'? > > Whether newbies are accustomed to this remains to be proven, but the > characters ``natural in the Emacs context'' above come from an > experienced user. > >> In the keyword searches that I am familiar with you can enclose the >> keywords in quotation marks to force sequential in order occurrence. > > That's an advanced feature, you know. > >> I believe that after your change, newbies _still_ will have to learn >> about regexps to accomplish what they are used to in search engines. > > Please explain why you think so. We have string search and replace, and regexp search and replace. Maybe regexp-apropos could be bound on C-h C-a . -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 16:43 ` Eli Zaretskii 2005-11-05 17:33 ` Drew Adams @ 2005-11-05 17:39 ` Luc Teirlinck 1 sibling, 0 replies; 69+ messages in thread From: Luc Teirlinck @ 2005-11-05 17:39 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii wrote: > Nothing in that discussion changes the fact that: > > (string-equal (regexp-quote regexp) regexp) > > is just a horrible way to distinguish a regexp from a list of keywords. Please don't get angry with me: I was not angry and did not intend to sound angry. I am sorry if something in the above quote gave the impression I was. I was only trying to say that the seemingly arbitrary rule of "at least two matching keywords" might have some valid reasons which are spelled out in the discussions. My _main_ objection was the confused semantics. I just thought that it might be possible to fix the semantics while at the same time giving the user more flexibility, but this was secondary. I think these problems were raised and discussed back then, but I might be wrong. I read through the entire thread and could not find it. The danger of misinterpreting an intended regexp as a list of keywords was mentioned, but not the opposite danger of misinterpreting a list of keywords as a regexp. This danger can occur even if a single keyword is specified, say .emacs, *scratch* , ses+. Unless something is done to avert that problem, then at least that problem should be mentioned clearly in `(emacs)Apropos' (and in the docstrings). The only mention of regexps in `(emacs)Apropos' is: For even greater flexibility, you can also supply a regular expression to Apropos (*note Regexps::). It does not explicitly mention that this "greater flexibility" means that you can not use certain characters in your keywords. It does also not give any tips on how to make sure that an intended regexp really gets interpreted by Emacs as a regexp. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 15:52 ` Luc Teirlinck 2005-11-05 16:43 ` Eli Zaretskii @ 2005-11-06 17:02 ` Stefan Monnier 2005-11-06 17:08 ` Eli Zaretskii 2005-11-06 19:55 ` Luc Teirlinck 1 sibling, 2 replies; 69+ messages in thread From: Stefan Monnier @ 2005-11-06 17:02 UTC (permalink / raw) Cc: eliz, emacs-devel > The prompt string of the apropos commands says: (regexp or words). > Which of the two and how do I choose? The docstrings all say that it > matches a regexp and do not mention keywords at all. Rather than have two different commands or use yet another C-u prefix, I suggest we replicate the M-r binding of isearch which allows toggling between string and regexp searches. It should of course toggle the prompt as well between "(regexp)" and "(words)". Stefan ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 17:02 ` Stefan Monnier @ 2005-11-06 17:08 ` Eli Zaretskii 2005-11-06 19:55 ` Luc Teirlinck 1 sibling, 0 replies; 69+ messages in thread From: Eli Zaretskii @ 2005-11-06 17:08 UTC (permalink / raw) Cc: teirllm, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Sun, 06 Nov 2005 12:02:26 -0500 > Cc: eliz@gnu.org, emacs-devel@gnu.org > > > The prompt string of the apropos commands says: (regexp or words). > > Which of the two and how do I choose? The docstrings all say that it > > matches a regexp and do not mention keywords at all. > > Rather than have two different commands or use yet another C-u prefix, > I suggest we replicate the M-r binding of isearch which allows toggling > between string and regexp searches. It should of course toggle the prompt > as well between "(regexp)" and "(words)". I suggest that the prompt should also say that M-r toggles. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 17:02 ` Stefan Monnier 2005-11-06 17:08 ` Eli Zaretskii @ 2005-11-06 19:55 ` Luc Teirlinck 1 sibling, 0 replies; 69+ messages in thread From: Luc Teirlinck @ 2005-11-06 19:55 UTC (permalink / raw) Cc: eliz, emacs-devel Stefan Monnier wrote: Rather than have two different commands or use yet another C-u prefix, I suggest we replicate the M-r binding of isearch which allows toggling between string and regexp searches. It should of course toggle the prompt as well between "(regexp)" and "(words)". That seems like a good solution. Maybe we could also have a user option to determine which of "(regexp)" or "(words)" comes up by default, so people who always use one of the two do not have to do an extra M-r each time. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 3:15 new apropos feature in Emacs-22 Luc Teirlinck 2005-11-05 10:26 ` Eli Zaretskii @ 2005-11-05 23:43 ` Richard M. Stallman 2005-11-06 0:27 ` Luc Teirlinck 1 sibling, 1 reply; 69+ messages in thread From: Richard M. Stallman @ 2005-11-05 23:43 UTC (permalink / raw) Cc: emacs-devel If the present convention is kept unchanged, then one should at the very least update the involved docstrings: although the Emacs manual mentions the new behavior, apparently none of the docstrings of the involved commands do. All the docstrings still suggest that the REGEXP argument will always be treated as a regular expression. We should certainly update the doc strings and manual, if we don't change the behavior. Someone else mentioned that there was a previous discussion. I would like to reread it too. Can someone tell me what range of dates it was, and a string or strings I can search for to find those messages among all the rest? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-05 23:43 ` Richard M. Stallman @ 2005-11-06 0:27 ` Luc Teirlinck 2005-11-07 15:34 ` Richard M. Stallman 0 siblings, 1 reply; 69+ messages in thread From: Luc Teirlinck @ 2005-11-06 0:27 UTC (permalink / raw) Cc: emacs-devel Richard Stallman wrote: Someone else mentioned that there was a previous discussion. I would like to reread it too. The thread starts at: http://lists.gnu.org/archive/html/emacs-devel/2002-05/msg00397.html Can someone tell me what range of dates it was, May 2002, as the above URL shows. and a string or strings I can search for to find those messages among all the rest? "apropos commands and regexps" (_with_ the quotation marks included). Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-06 0:27 ` Luc Teirlinck @ 2005-11-07 15:34 ` Richard M. Stallman 2005-11-07 17:54 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 69+ messages in thread From: Richard M. Stallman @ 2005-11-07 15:34 UTC (permalink / raw) Cc: emacs-devel I looked at the previous discussion, and it seems to me that the only change we need is in doc strings, prompts, and argument names. Here's what I am thinking of installing. *** apropos.el 18 Sep 2005 09:53:38 -0400 1.106 --- apropos.el 06 Nov 2005 15:09:10 -0500 *************** *** 126,135 **** (defvar apropos-mode-hook nil "*Hook run when mode is turned on.") ! (defvar apropos-regexp nil "Regexp used in current apropos run.") ! (defvar apropos-orig-regexp nil "Regexp as entered by user.") (defvar apropos-all-regexp nil --- 126,135 ---- (defvar apropos-mode-hook nil "*Hook run when mode is turned on.") ! (defvar apropos-pattern nil "Regexp used in current apropos run.") ! (defvar apropos-orig-pattern nil "Regexp as entered by user.") (defvar apropos-all-regexp nil *************** *** 270,278 **** ""))) (defun apropos-rewrite-regexp (regexp) ! "Rewrite a list of words to a regexp matching all permutations. ! If REGEXP is already a regexp, don't modify it." ! (setq apropos-orig-regexp regexp) (setq apropos-words () apropos-all-words ()) (if (string-equal (regexp-quote regexp) regexp) ;; We don't actually make a regexp matching all permutations. --- 270,279 ---- ""))) (defun apropos-rewrite-regexp (regexp) ! "Rewrite a space-separated words list to a regexp matching all permutations. ! If REGEXP contains any special regexp characters, that means it ! is already a regexp, so return it unchanged." ! (setq apropos-orig-pattern regexp) (setq apropos-words () apropos-all-words ()) (if (string-equal (regexp-quote regexp) regexp) ;; We don't actually make a regexp matching all permutations. *************** *** 376,382 **** (if (or current-prefix-arg apropos-do-all) "variable" "user option") ! " (regexp or words): ")) current-prefix-arg)) (apropos-command regexp nil (if (or do-all apropos-do-all) --- 377,383 ---- (if (or current-prefix-arg apropos-do-all) "variable" "user option") ! " (word list or regexp): ")) current-prefix-arg)) (apropos-command regexp nil (if (or do-all apropos-do-all) *************** *** 389,396 **** ;;;###autoload (defalias 'command-apropos 'apropos-command) ;;;###autoload ! (defun apropos-command (apropos-regexp &optional do-all var-predicate) ! "Show commands (interactively callable functions) that match APROPOS-REGEXP. With optional prefix DO-ALL, or if `apropos-do-all' is non-nil, also show noninteractive functions. --- 390,402 ---- ;;;###autoload (defalias 'command-apropos 'apropos-command) ;;;###autoload ! (defun apropos-command (apropos-pattern &optional do-all var-predicate) ! "Show commands (interactively callable functions) that match APROPOS-PATTERN. ! APROPOS-PATTERN can be a word, a list of words (separated by spaces), ! or a regexp (using some regexp special characters). If it is a word, ! search for matches for that word as a substring. If it is a list of words, ! search for matches for any two (or more) of those words. ! With optional prefix DO-ALL, or if `apropos-do-all' is non-nil, also show noninteractive functions. *************** *** 401,415 **** (if (or current-prefix-arg apropos-do-all) "or function ") ! "(regexp or words): ")) current-prefix-arg)) ! (setq apropos-regexp (apropos-rewrite-regexp apropos-regexp)) (let ((message (let ((standard-output (get-buffer-create "*Apropos*"))) (print-help-return-message 'identity)))) (or do-all (setq do-all apropos-do-all)) (setq apropos-accumulator ! (apropos-internal apropos-regexp (or var-predicate (if do-all 'functionp 'commandp)))) (let ((tem apropos-accumulator)) --- 407,421 ---- (if (or current-prefix-arg apropos-do-all) "or function ") ! "(word list or regexp): ")) current-prefix-arg)) ! (setq apropos-pattern (apropos-rewrite-regexp apropos-pattern)) (let ((message (let ((standard-output (get-buffer-create "*Apropos*"))) (print-help-return-message 'identity)))) (or do-all (setq do-all apropos-do-all)) (setq apropos-accumulator ! (apropos-internal apropos-pattern (or var-predicate (if do-all 'functionp 'commandp)))) (let ((tem apropos-accumulator)) *************** *** 457,471 **** ;;;###autoload ! (defun apropos (apropos-regexp &optional do-all) ! "Show all bound symbols whose names match APROPOS-REGEXP. With optional prefix DO-ALL or if `apropos-do-all' is non-nil, also show unbound symbols and key bindings, which is a little more time-consuming. Returns list of symbols and documentation found." ! (interactive "sApropos symbol (regexp or words): \nP") ! (setq apropos-regexp (apropos-rewrite-regexp apropos-regexp)) (apropos-symbols-internal ! (apropos-internal apropos-regexp (and (not do-all) (not apropos-do-all) (lambda (symbol) --- 463,482 ---- ;;;###autoload ! (defun apropos (apropos-pattern &optional do-all) ! "Show all bound symbols whose names match APROPOS-PATTERN. ! APROPOS-PATTERN can be a word, a list of words (separated by spaces), ! or a regexp (using some regexp special characters). If it is a word, ! search for matches for that word as a substring. If it is a list of words, ! search for matches for any two (or more) of those words. ! With optional prefix DO-ALL or if `apropos-do-all' is non-nil, also show unbound symbols and key bindings, which is a little more time-consuming. Returns list of symbols and documentation found." ! (interactive "sApropos symbol (word list or regexp): \nP") ! (setq apropos-pattern (apropos-rewrite-regexp apropos-pattern)) (apropos-symbols-internal ! (apropos-internal apropos-pattern (and (not do-all) (not apropos-do-all) (lambda (symbol) *************** *** 520,540 **** ;;;###autoload ! (defun apropos-value (apropos-regexp &optional do-all) ! "Show all symbols whose value's printed image matches APROPOS-REGEXP. With optional prefix DO-ALL or if `apropos-do-all' is non-nil, also looks at the function and at the names and values of properties. Returns list of symbols and values found." ! (interactive "sApropos value (regexp or words): \nP") ! (setq apropos-regexp (apropos-rewrite-regexp apropos-regexp)) (or do-all (setq do-all apropos-do-all)) (setq apropos-accumulator ()) (let (f v p) (mapatoms (lambda (symbol) (setq f nil v nil p nil) ! (or (memq symbol '(apropos-regexp ! apropos-orig-regexp apropos-all-regexp apropos-words apropos-all-words do-all apropos-accumulator symbol f v p)) --- 531,556 ---- ;;;###autoload ! (defun apropos-value (apropos-pattern &optional do-all) ! "Show all symbols whose value's printed image matches APROPOS-PATTERN. ! APROPOS-PATTERN can be a word, a list of words (separated by spaces), ! or a regexp (using some regexp special characters). If it is a word, ! search for matches for that word as a substring. If it is a list of words, ! search for matches for any two (or more) of those words. ! With optional prefix DO-ALL or if `apropos-do-all' is non-nil, also looks at the function and at the names and values of properties. Returns list of symbols and values found." ! (interactive "sApropos value (word list or regexp): \nP") ! (setq apropos-pattern (apropos-rewrite-regexp apropos-pattern)) (or do-all (setq do-all apropos-do-all)) (setq apropos-accumulator ()) (let (f v p) (mapatoms (lambda (symbol) (setq f nil v nil p nil) ! (or (memq symbol '(apropos-pattern ! apropos-orig-pattern apropos-all-regexp apropos-words apropos-all-words do-all apropos-accumulator symbol f v p)) *************** *** 559,572 **** ;;;###autoload ! (defun apropos-documentation (apropos-regexp &optional do-all) ! "Show symbols whose documentation contain matches for APROPOS-REGEXP. With optional prefix DO-ALL or if `apropos-do-all' is non-nil, also use documentation that is not stored in the documentation file and show key bindings. Returns list of symbols and documentation found." ! (interactive "sApropos documentation (regexp or words): \nP") ! (setq apropos-regexp (apropos-rewrite-regexp apropos-regexp)) (or do-all (setq do-all apropos-do-all)) (setq apropos-accumulator () apropos-files-scanned ()) (let ((standard-input (get-buffer-create " apropos-temp")) --- 575,593 ---- ;;;###autoload ! (defun apropos-documentation (apropos-pattern &optional do-all) ! "Show symbols whose documentation contain matches for APROPOS-PATTERN. ! APROPOS-PATTERN can be a word, a list of words (separated by spaces), ! or a regexp (using some regexp special characters). If it is a word, ! search for matches for that word as a substring. If it is a list of words, ! search for matches for any two (or more) of those words. ! With optional prefix DO-ALL or if `apropos-do-all' is non-nil, also use documentation that is not stored in the documentation file and show key bindings. Returns list of symbols and documentation found." ! (interactive "sApropos documentation (word list or regexp): \nP") ! (setq apropos-pattern (apropos-rewrite-regexp apropos-pattern)) (or do-all (setq do-all apropos-do-all)) (setq apropos-accumulator () apropos-files-scanned ()) (let ((standard-input (get-buffer-create " apropos-temp")) *************** *** 610,616 **** (if (funcall predicate symbol) (progn (setq symbol (prin1-to-string (funcall function symbol))) ! (if (string-match apropos-regexp symbol) (progn (if apropos-match-face (put-text-property (match-beginning 0) (match-end 0) --- 631,637 ---- (if (funcall predicate symbol) (progn (setq symbol (prin1-to-string (funcall function symbol))) ! (if (string-match apropos-pattern symbol) (progn (if apropos-match-face (put-text-property (match-beginning 0) (match-end 0) *************** *** 637,643 **** (let (p p-out) (while pl (setq p (format "%s %S" (car pl) (nth 1 pl))) ! (if (or (not compare) (string-match apropos-regexp p)) (if apropos-property-face (put-text-property 0 (length (symbol-name (car pl))) 'face apropos-property-face p)) --- 658,664 ---- (let (p p-out) (while pl (setq p (format "%s %S" (car pl) (nth 1 pl))) ! (if (or (not compare) (string-match apropos-pattern p)) (if apropos-property-face (put-text-property 0 (length (symbol-name (car pl))) 'face apropos-property-face p)) *************** *** 653,659 **** p-out)) ! ;; Finds all documentation related to APROPOS-REGEXP in internal-doc-file-name. (defun apropos-documentation-check-doc-file () (let (type symbol (sepa 2) sepb beg end) --- 674,680 ---- p-out)) ! ;; Finds all documentation related to APROPOS-PATTERN in internal-doc-file-name. (defun apropos-documentation-check-doc-file () (let (type symbol (sepa 2) sepb beg end) *************** *** 782,788 **** If SPACING is non-nil, it should be a string; separate items with that string. If non-nil TEXT is a string that will be printed as a heading." (if (null apropos-accumulator) ! (message "No apropos matches for `%s'" apropos-orig-regexp) (setq apropos-accumulator (sort apropos-accumulator (lambda (a b) --- 803,809 ---- If SPACING is non-nil, it should be a string; separate items with that string. If non-nil TEXT is a string that will be printed as a heading." (if (null apropos-accumulator) ! (message "No apropos matches for `%s'" apropos-orig-pattern) (setq apropos-accumulator (sort apropos-accumulator (lambda (a b) ^ permalink raw reply [flat|nested] 69+ messages in thread
* RE: new apropos feature in Emacs-22 2005-11-07 15:34 ` Richard M. Stallman @ 2005-11-07 17:54 ` Drew Adams 2005-11-07 18:56 ` Stefan Monnier 2005-11-07 20:52 ` Eli Zaretskii 2005-11-08 4:58 ` Luc Teirlinck 2005-11-09 23:25 ` Kim F. Storm 2 siblings, 2 replies; 69+ messages in thread From: Drew Adams @ 2005-11-07 17:54 UTC (permalink / raw) This feature changes the syntax and meaning of the input to apropos functions. We've discussed the effects on the users of apropos commands. There is also a (similar) effect on the programmatic use to consider. While it is true that there are internal apropos functions that programs could use instead of using the end-user commands: 1. There is no guarantee that programs do not use the end-user commands. 2. In some cases, there is no internal function that directly does what's needed. For example, there is no internal equivalent of `apropos-variable' (IIUC). 3. There is (still) no documentation for most of the internal commands (apropos-documentation-check-doc-file, apropos-documentation-check-elc-file, apropos-documentation-internal, apropos-symbols-internal, apropos-value-internal). This can suggest to programmers that the internal functions are not intended to be used externally. Most of the discussion has centered on _how_ to obtain the syntax and behavior of both the old (regexp) and the new (keywords) apropos at the same time, in the same command - not on whether or not that is desirable. The latest suggestion for combining the old and new in the same command was to use `M-r' to toggle between old and new (in addition to `C-u' to toggle `do-all') - and to add a new user option for selecting the default behavior. This, like the other suggestions, is workable, but it doesn't help existing programmatic use of the commands. In order to not break existing code: 1. An extra (e.g. optional) parameter would need to be provided to the commands. 2. Its default value (nil) would need to reflect the old behavior. #2 conflicts with the desire to make the default syntax and behavior be keyword search, in order to be more "novice user-friendly". We could treat the interactive and programmatic values oppositely wrt to this parameter, of course, but that would be downright mischievous. I argued that the old and new syntaxes and behaviors should be implemented in different commands. That would give all users what they want, without the complexities of modes and mixed syntaxes. It would also not break any existing code. (I also said that I didn't care which commands got the "apropos" name, but I've changed my mind on that, after thinking about existing programs that might expect the old behavior from the "apropos" names. That is, I don't really care about the names, but existing programs might.) I've still seen _no argument_ (i.e. no rationale) voiced against using separate commands. One could argue "Occam's razor: don't multiply things needlessly", but that applies equally to all approaches discussed so far - whether we multiply the number of commands or the number of use modes (e.g. `M-r' toggle) for the existing commands. So, I repeat the question: _Why not_ leave the apropos commands as they were, and create new, more "novice user-friendly", keyword-search commands? The question deserves some reply, at least. It should have been addressed before launching a discussion of _how_ to change the existing commands. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-07 17:54 ` Drew Adams @ 2005-11-07 18:56 ` Stefan Monnier 2005-11-07 19:25 ` Drew Adams 2005-11-07 22:39 ` Lennart Borgman 2005-11-07 20:52 ` Eli Zaretskii 1 sibling, 2 replies; 69+ messages in thread From: Stefan Monnier @ 2005-11-07 18:56 UTC (permalink / raw) Cc: emacs-devel > I argued that the old and new syntaxes and behaviors should be implemented > in different commands. That would give all users what they want, without > the complexities of modes and mixed syntaxes. It would also not break any > existing code. Having separate commands means that you can't have both behaviors on the same key-binding. I like using the keybindings, and I sometimes need regexps but generally prefer the keyword search. That's the main reason why I'm proposing the M-r solution. I'd argue that the M-r solution should also be added to query-replace, BTW. Stefan ^ permalink raw reply [flat|nested] 69+ messages in thread
* RE: new apropos feature in Emacs-22 2005-11-07 18:56 ` Stefan Monnier @ 2005-11-07 19:25 ` Drew Adams 2005-11-07 22:39 ` Lennart Borgman 1 sibling, 0 replies; 69+ messages in thread From: Drew Adams @ 2005-11-07 19:25 UTC (permalink / raw) > I argued that the old and new syntaxes and behaviors should be implemented > in different commands. That would give all users what they want, without > the complexities of modes and mixed syntaxes. It would also not break any > existing code. Having separate commands means that you can't have both behaviors on the same key-binding. I like using the keybindings, and I sometimes need regexps but generally prefer the keyword search. That's the main reason why I'm proposing the M-r solution. A good argument - worth stating explicitly for the discussion. Thx. I guess I'd still prefer that we offer separate commands, with the built-in bindings going to the novice-friendly commands. But I agree that key-binding is a good argument for not using separate commands. I prefer separate commands because I think we're asking for trouble by mixing two radically different input syntaxes - especially if we're worried about novices. Although radically different, the syntaxes have some overlap (even if that sounds paradoxical). They can seem the same (with similar behavior) in some common cases, as others have pointed out, but they are not the same. Sometimes, les faux amis are worse than les enemis, because of the additional element of confusion. I'd argue that the M-r solution should also be added to query-replace, BTW. Do you mean for regexp vs literal input? I don't disagree with some such a toggle. In fact, I use a command (bound to M-%) that works this way: - No PREFIX argument (nil) means replace literal string matches. - Positive PREFIX argument means replace word matches. - Negative PREFIX argument means replace regexp matches. So, you see that I'm not insensitive to the single-key-binding argument. Anyway, this is changing the subject; it should be a separate thread, if pursued. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-07 18:56 ` Stefan Monnier 2005-11-07 19:25 ` Drew Adams @ 2005-11-07 22:39 ` Lennart Borgman 1 sibling, 0 replies; 69+ messages in thread From: Lennart Borgman @ 2005-11-07 22:39 UTC (permalink / raw) Cc: Drew Adams, emacs-devel Stefan Monnier wrote: >Having separate commands means that you can't have both behaviors on the >same key-binding. I like using the keybindings, and I sometimes need >regexps but generally prefer the keyword search. That's the main reason >why I'm proposing the M-r solution. I'd argue that the M-r solution should >also be added to query-replace, BTW. > > I like this idea if it is used consistently. Then it is easy to remember. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-07 17:54 ` Drew Adams 2005-11-07 18:56 ` Stefan Monnier @ 2005-11-07 20:52 ` Eli Zaretskii 2005-11-07 22:59 ` Drew Adams 1 sibling, 1 reply; 69+ messages in thread From: Eli Zaretskii @ 2005-11-07 20:52 UTC (permalink / raw) Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Mon, 7 Nov 2005 09:54:00 -0800 > > Most of the discussion has centered on _how_ to obtain the syntax and > behavior of both the old (regexp) and the new (keywords) apropos at the same > time, in the same command - not on whether or not that is desirable. That's because everybody agreed that it was desirable. There was no need to discuss that about which we were in almost perfect agreement. > So, I repeat the question: _Why not_ leave the apropos commands as they > were, and create new, more "novice user-friendly", keyword-search commands? > The question deserves some reply, at least. It should have been addressed > before launching a discussion of _how_ to change the existing commands. This question was asked and answered. I posted the URL here. ^ permalink raw reply [flat|nested] 69+ messages in thread
* RE: new apropos feature in Emacs-22 2005-11-07 20:52 ` Eli Zaretskii @ 2005-11-07 22:59 ` Drew Adams 2005-11-08 4:47 ` Eli Zaretskii 0 siblings, 1 reply; 69+ messages in thread From: Drew Adams @ 2005-11-07 22:59 UTC (permalink / raw) > Most of the discussion has centered on _how_ to obtain the syntax and > behavior of both the old (regexp) and the new (keywords) apropos at the same > time, in the same command - not on whether or not that is desirable. That's because everybody agreed that it was desirable. There was no need to discuss that about which we were in almost perfect agreement. I've seen at least a couple of posts that indicate support for not combining these in the same command. But you might be right that we are in the minority. It's hard to tell, if the question isn't discussed - which is why I raised it. > So, I repeat the question: _Why not_ leave the apropos > commands as they were, and create new, more "novice > user-friendly", keyword-search commands? The question > deserves some reply, at least. It should have been addressed > before launching a discussion of _how_ to change the existing > commands. This question was asked and answered. I posted the URL here. Stefan gave a good answer (key bindings) - today. But I did not see that question asked or answered in the thread you cited. Can you please point out the relevant passage? Or did you mean only this, which I quoted earlier: - All apropos commands should `accept the same type of "search patterns".' I already asked if that was all you meant, or if I was missing something you saw in the thread. I have assumed the former, for lack of a reply, but let me ask again. If that is the only answer in the thread to the question, then just what constitutes an "apropos command" in this regard? Is it any command that returns information about something? Is it any command that has "apropos" in its name? Does it refer only to the existing set of commands with "apropos" in their names? When I asked why all "apropos commands" should accept the same type of input, Kim replied that it was obviously for user-friendliness. If the existing set of commands with "apropos" in their names continued to accept only regexps, and a new suite of commands, called, say, `keywords-about-'* accepted only keywords, would that not be user-friendly? Isn't it friendlier to users to make sure that the input syntax for a command is simple, clear-cut, and unambiguous - with no surprises? Is having two sets of commands, clearly distinguished by name, more confusing than making users figure out how to finagle a crossbreed syntax to get one or the other behavior? That said, Stefan's proposal solves the syntax problem while still using the same command - the two syntaxes would never be mixed (active at the same time). The only problem I see with it is the problem of a default behavior that both: - is suitable for newbies (=> keyword search, by default) and - doesn't break existing code (=> regexp search, by default) If we can somehow cut that knot, we might all agree on a solution. If not, I'd still argue for separate commands. One thing that might work is to create new commands for users, with the toggle behavior that Stefan described (and the default in favor of keywords). If the names are new, that change won't affect existing code. And we can then deprecate the interactive use of the existing apropos functions - or at least advertise only the new commands. That last step should satisfy those who don't want two different sets of commands. The only loss would be the current command names, for interactive use. "Apropos", in this context, just means "about". We might call the new commands `about', `about-variable', `about-documentation', etc. - but that would be a bit misleading. On the other hand, the action involved is really just a literal keyword lookup - a search. So, more appropriate names would be `search-symbols', `search-variables', `search-documentation', etc. Or, better, `find-symbols' etc. - because symbols etc. are not searched; they are found. Newbies would in fact be more likely to stumble upon `find-commands' than `apropos-command'. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-07 22:59 ` Drew Adams @ 2005-11-08 4:47 ` Eli Zaretskii 0 siblings, 0 replies; 69+ messages in thread From: Eli Zaretskii @ 2005-11-08 4:47 UTC (permalink / raw) Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Mon, 7 Nov 2005 14:59:31 -0800 > > > So, I repeat the question: _Why not_ leave the apropos > > commands as they were, and create new, more "novice > > user-friendly", keyword-search commands? The question > > deserves some reply, at least. It should have been addressed > > before launching a discussion of _how_ to change the existing > > commands. > > This question was asked and answered. I posted the URL here. > > Stefan gave a good answer (key bindings) - today. But I did not see that > question asked or answered in the thread you cited. Can you please point out > the relevant passage? I raised that in the second or third message in the thread. > Or did you mean only this, which I quoted earlier: > > - All apropos commands should `accept the same type of "search patterns".' Yes, that's what I got as a reply back then, and since everybody but me seemed to agree on that principle, I didn't fight it. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-07 15:34 ` Richard M. Stallman 2005-11-07 17:54 ` Drew Adams @ 2005-11-08 4:58 ` Luc Teirlinck 2005-11-08 12:48 ` Kim F. Storm 2005-11-11 7:42 ` Richard M. Stallman 2005-11-09 23:25 ` Kim F. Storm 2 siblings, 2 replies; 69+ messages in thread From: Luc Teirlinck @ 2005-11-08 4:58 UTC (permalink / raw) Cc: emacs-devel I looked at the previous discussion, and it seems to me that the only change we need is in doc strings, prompts, and argument names. Here's what I am thinking of installing. The help echos in `menu-bar-apropos-menu' (Help -> Search Documentation) and the Info nodes (emacs)Help, (emacs)Help Summary and (emacs)Apropos would also need updating and/or clarification. I guess (emacs)Apropos should wait until we have decided on the final details. Perhaps we should change the criteria so that a period does not make it a regexp. A different criterion would be ok as long as it is simple. I grepped for `apropos' in the lisp directory. I now believe that making the default recognize even less regexps carries a risk of breaking some things, relatively close to a release. There were tons of complex matches and I do not have the time to try to understand all of them and see what would break them. I believe that (emacs)Apropos should _explicitly_ warn that, if one wants to search by keywords, keywords should not contain regexp special characters and warn in particular that filenames containing dots can normally not be used as keywords. As people will sometimes _want_ to use things like .emacs, .mailrc or .XDefaults as keywords, especially for apropos-documentation, some escape convention should be provided. Why not use my original proposal: final unquoted `[' (or final single `\') is ignored and means that the input is unconditionally a list of keywords, for this specialized (but real) need? If we are willing to make somewhat more changes, there could be a user option `apropos-search-style' whose default value nil could be the present default with the `[' escape convention added. There would also be values 'keyword and 'regexp for keyword only and regexp only. If we are willing to do somewhat more, then M-r could be unbound for the nil value and toggle between the two other values. I believe that, certainly with the M-r binding available, most people knowing about the option would set it to one of the two non-nil values. But I would guess that a default of 'regexp (which would be 100% backward compatible) will probably be deemed unacceptable and (unlike before my grepping) I now am afraid that an all keyword default would break several things. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-08 4:58 ` Luc Teirlinck @ 2005-11-08 12:48 ` Kim F. Storm 2005-11-08 23:53 ` Miles Bader 2005-11-11 7:42 ` Richard M. Stallman 1 sibling, 1 reply; 69+ messages in thread From: Kim F. Storm @ 2005-11-08 12:48 UTC (permalink / raw) Cc: rms, emacs-devel Luc Teirlinck <teirllm@dms.auburn.edu> writes: > I grepped for `apropos' in the lisp directory. I now believe that > making the default recognize even less regexps carries a risk of > breaking some things, relatively close to a release. There were tons > of complex matches and I do not have the time to try to understand all > of them and see what would break them. I grepped for apropos too, and I didn't find any "complex matches". Most of the matches has nothing to do with apropos.el functionality. There are some (clever) rules in gnus-art to make a hyperlink out of e.g. M-x apropos-documentation RET init file RET but this will DTRT, as it takes the string between RET ... RET and pass it to e.g. apropos-documentation which is exactly TRTD. There is also this little snippet in wid-edit.el: (if (and (fboundp symbol) (boundp symbol)) ;; If there are two doc strings, give the user a way to pick one. (apropos (concat "\\`" (regexp-quote string) "\\'")) But this explicitly makes the arg. into a regexp. The rest seems to be trivial, and will DTRT as is. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-08 12:48 ` Kim F. Storm @ 2005-11-08 23:53 ` Miles Bader 2005-11-09 0:21 ` Lennart Borgman 0 siblings, 1 reply; 69+ messages in thread From: Miles Bader @ 2005-11-08 23:53 UTC (permalink / raw) Cc: Luc Teirlinck, rms, emacs-devel So is Luc's belly-aching over apropos actually based on any real data (users getting confused by apropos behavior)? The mere presence of potential confusion does not mean that it's likely to happen in practice. Given that the current behavior offers a nice advantage -- it supports both traditional emacs users who might use a regexp, and newbies will will likely just give a list of plain words, all without an annoying and confusing proliferation of commands -- it seems to me there needs to be a good reason to change it, more than just a _potential_ for confusion. [If you were to judge Emacs generally on a potential-for-confusion basis, I think you'd have no alternative but to just toss the whole thing out and tell users to use pico instead... :-] -miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-08 23:53 ` Miles Bader @ 2005-11-09 0:21 ` Lennart Borgman 0 siblings, 0 replies; 69+ messages in thread From: Lennart Borgman @ 2005-11-09 0:21 UTC (permalink / raw) Cc: emacs-devel Miles Bader wrote: >So is Luc's belly-aching over apropos actually based on any real data >(users getting confused by apropos behavior)? > >The mere presence of potential confusion does not mean that it's >likely to happen in practice. > And the absence of complaints unfortunately does not mean that everyone is not confused. If I ever did learn something while teaching it was to my surprise that a very common reason for not asking is beeing confused ;-) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-08 4:58 ` Luc Teirlinck 2005-11-08 12:48 ` Kim F. Storm @ 2005-11-11 7:42 ` Richard M. Stallman 2005-11-11 9:29 ` Kim F. Storm ` (2 more replies) 1 sibling, 3 replies; 69+ messages in thread From: Richard M. Stallman @ 2005-11-11 7:42 UTC (permalink / raw) Cc: emacs-devel I believe that (emacs)Apropos should _explicitly_ warn that, if one wants to search by keywords, keywords should not contain regexp special characters and warn in particular that filenames containing dots can normally not be used as keywords. I will do that. As people will sometimes _want_ to use things like .emacs, .mailrc or .XDefaults as keywords, especially for apropos-documentation, some escape convention should be provided. Why not use my original proposal: final unquoted `[' (or final single `\') is ignored and means that the input is unconditionally a list of keywords, for this specialized (but real) need? I don't think this will be very useful, because the people it is most aimed at are beginners and they are unlikely to remember that this is available. The only think I can think of that would help beginners with such inputs would be to detect such cases and ask the user "Did you mean this as a regexp or as a list of keywords?" That question would help people without requiring them to remember in advance that the two options exist. I have not looked at the program callers of the apropos commands. If this is likely to break them, maybe we should not do it. Otherwise, would you like to do it? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-11 7:42 ` Richard M. Stallman @ 2005-11-11 9:29 ` Kim F. Storm 2005-11-11 10:57 ` Miles Bader 2005-11-12 3:15 ` Luc Teirlinck 2005-11-12 3:36 ` Luc Teirlinck 2 siblings, 1 reply; 69+ messages in thread From: Kim F. Storm @ 2005-11-11 9:29 UTC (permalink / raw) Cc: Luc Teirlinck, emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > The only think I can think of that would help beginners with such > inputs would be to detect such cases and ask the user "Did you mean > this as a regexp or as a list of keywords?" That question would > help people without requiring them to remember in advance that the > two options exist. > I have not looked at the program callers of the apropos commands. > If this is likely to break them, maybe we should not do it. > Otherwise, would you like to do it? This is on my to-do list. The main problem is that current callers always supply a regexp. I'm thinking about adding a new optional argument ENABLE-KEYWORDS to all apropos commands and set it via an interactive "p" spec, i.e. so it is set to an integer for interactive use (meaning: ask user). Other callers could specify "nil" (default) to mean interpret PATTERN as regexp, "t" to mean interpret PATTERN as words, and ">0" to mean ask user, and "<0" to mean "automatically determine" without asking. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-11 9:29 ` Kim F. Storm @ 2005-11-11 10:57 ` Miles Bader 2005-11-11 16:16 ` Kim F. Storm 2005-11-12 3:38 ` Richard M. Stallman 0 siblings, 2 replies; 69+ messages in thread From: Miles Bader @ 2005-11-11 10:57 UTC (permalink / raw) Cc: Luc Teirlinck, rms, emacs-devel 2005/11/11, Kim F. Storm <storm@cua.dk>: > I'm thinking about adding a new optional argument ENABLE-KEYWORDS > to all apropos commands and set it via an interactive "p" spec, > i.e. so it is set to an integer for interactive use (meaning: ask user). > > Other callers could specify "nil" (default) to mean interpret PATTERN > as regexp, "t" to mean interpret PATTERN as words, and ">0" to mean ask > user, and "<0" to mean "automatically determine" without asking. I think it would be a _lot_ more intuitive to just have apropos functions interpret PATTERN as a regexp if it's a string, and as a list of keywords if it's a list. There could be a "read-apropos-pattern" function that would convert the user's input into the appropriate lisp value, which could be used directly in the (interactive ) form of various apropos commands. -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-11 10:57 ` Miles Bader @ 2005-11-11 16:16 ` Kim F. Storm 2005-11-12 3:38 ` Richard M. Stallman 1 sibling, 0 replies; 69+ messages in thread From: Kim F. Storm @ 2005-11-11 16:16 UTC (permalink / raw) Cc: emacs-devel, Luc Teirlinck, rms, miles Miles Bader <snogglethorpe@gmail.com> writes: > I think it would be a _lot_ more intuitive to just have apropos > functions interpret PATTERN as a regexp if it's a string, and as a > list of keywords if it's a list. There could be a > "read-apropos-pattern" function that would convert the user's input > into the appropriate lisp value, which could be used directly in the > (interactive ) form of various apropos commands. Very good idea. I'll see what I can do! -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-11 10:57 ` Miles Bader 2005-11-11 16:16 ` Kim F. Storm @ 2005-11-12 3:38 ` Richard M. Stallman 1 sibling, 0 replies; 69+ messages in thread From: Richard M. Stallman @ 2005-11-12 3:38 UTC (permalink / raw) Cc: emacs-devel, teirllm, storm I think it would be a _lot_ more intuitive to just have apropos functions interpret PATTERN as a regexp if it's a string, and as a list of keywords if it's a list. There could be a "read-apropos-pattern" function that would convert the user's input into the appropriate lisp value, which could be used directly in the (interactive ) form of various apropos commands. That is a very good idea. Would someone like to do it? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-11 7:42 ` Richard M. Stallman 2005-11-11 9:29 ` Kim F. Storm @ 2005-11-12 3:15 ` Luc Teirlinck 2005-11-12 17:49 ` Richard M. Stallman 2005-11-12 3:36 ` Luc Teirlinck 2 siblings, 1 reply; 69+ messages in thread From: Luc Teirlinck @ 2005-11-12 3:15 UTC (permalink / raw) Cc: emacs-devel Richard Stallman wrote: The only think I can think of that would help beginners with such inputs would be to detect such cases and ask the user "Did you mean this as a regexp or as a list of keywords?" That question would help people without requiring them to remember in advance that the two options exist. It would be _very_ annoying if that question were asked each time that an input could be interpreted as a regexp, especially for people who are always going to use a regexp. Also, I believe that if a beginning user uses apropos, it usually is because they read some doc somewhere that told them that, for more info, they could run a specific apropos command with a specific regexp. If a _true_ newbie literally follows somebody else's instructions and he gets asked: keywords or regexps?, then he may not know what to do. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-12 3:15 ` Luc Teirlinck @ 2005-11-12 17:49 ` Richard M. Stallman 0 siblings, 0 replies; 69+ messages in thread From: Richard M. Stallman @ 2005-11-12 17:49 UTC (permalink / raw) Cc: emacs-devel The only think I can think of that would help beginners with such inputs would be to detect such cases and ask the user "Did you mean this as a regexp or as a list of keywords?" That question would help people without requiring them to remember in advance that the two options exist. It would be _very_ annoying if that question were asked each time that an input could be interpreted as a regexp, I agree. What I proposed was to ask this question only in cases like ".emacs file" where users might plausibly think they were keywords; that is to say, only when period is the only special regexp character. Those cases would not be very common, so the total annoyance will be small. Also, I believe that if a beginning user uses apropos, it usually is because they read some doc somewhere that told them that, for more info, they could run a specific apropos command with a specific regexp. It is probably because they read some documentation. I don't follow the last part of your sentence. Anyway, I don't think that makes this question unuseful. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-11 7:42 ` Richard M. Stallman 2005-11-11 9:29 ` Kim F. Storm 2005-11-12 3:15 ` Luc Teirlinck @ 2005-11-12 3:36 ` Luc Teirlinck 2005-11-12 21:19 ` Juri Linkov 2 siblings, 1 reply; 69+ messages in thread From: Luc Teirlinck @ 2005-11-12 3:36 UTC (permalink / raw) Cc: emacs-devel Why not use my original proposal: final unquoted `[' (or final single `\') is ignored and means that the input is unconditionally a list of keywords, for this specialized (but real) need? I don't think this will be very useful, because the people it is most aimed at are beginners and they are unlikely to remember that this is available. Complete beginners do not even know about the apropos commands. Users must have learned about them somewhere, probably in `(emacs)Apropos'. If you them tell there that they normally can not use regexp special characters in keywords, then I believe that it would be good to tell them about a way out. Maybe they may not remember the exact character when they need it, but they will remember that the manual mentioned a way out and they can check it back up. It might also be useful to have an option `apropos-search-style', whose default is the present method, but can also specify 'keywords or 'regexp. I know that I can force regexp search by using stuff like `[o]verwrite mode', but it is easy to forget and then I get confused by all the nonsense I get. I never intend to use anything else but regexp search and I am convinced that this must be true for many other users too. In that case being forced to always make the input into something Kim's procedure recognizes as a regexp is a nuisance. It makes apropos annoyingly different from other commands that use regexps. Sincerely, Luc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-12 3:36 ` Luc Teirlinck @ 2005-11-12 21:19 ` Juri Linkov 2005-11-14 4:55 ` Richard M. Stallman 0 siblings, 1 reply; 69+ messages in thread From: Juri Linkov @ 2005-11-12 21:19 UTC (permalink / raw) Cc: rms, emacs-devel > Complete beginners do not even know about the apropos commands. Users > must have learned about them somewhere, probably in `(emacs)Apropos'. More likely, from the Help buffer after typing `C-h ?' or `f1 f1': a command-apropos. Give a substring, and see a list of commands (functions that are interactively callable) that contain that substring. See also the apropos command. Note that this description is incomplete. It says nothing about patterns, word lists or regexps. Maybe it is simple enough for beginners. But it might be confusing for beginners if after reading this description and typing `a' they will see a prompt asking for "(word list or regexp): ". -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-12 21:19 ` Juri Linkov @ 2005-11-14 4:55 ` Richard M. Stallman 2005-11-15 0:52 ` Juri Linkov 0 siblings, 1 reply; 69+ messages in thread From: Richard M. Stallman @ 2005-11-14 4:55 UTC (permalink / raw) Cc: teirllm, emacs-devel More likely, from the Help buffer after typing `C-h ?' or `f1 f1': a command-apropos. Give a substring, and see a list of commands (functions that are interactively callable) that contain that substring. See also the apropos command. I will clarify that. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-14 4:55 ` Richard M. Stallman @ 2005-11-15 0:52 ` Juri Linkov 2005-11-15 23:22 ` Richard M. Stallman 0 siblings, 1 reply; 69+ messages in thread From: Juri Linkov @ 2005-11-15 0:52 UTC (permalink / raw) Cc: teirllm, emacs-devel > More likely, from the Help buffer after typing `C-h ?' or `f1 f1': > > a command-apropos. Give a substring, and see a list of commands > (functions that are interactively callable) that contain > that substring. See also the apropos command. > > I will clarify that. In the new text: a command-apropos. Give a list of words or a regexp, to get a list of commands whose names match (they contain two or more of the words, =========== or a match for the regexp). See also the apropos command. I don't understand why two or more of the words, if it is possible to give just one word and find a command whose names contains one word. Maybe more correct text is "they contain one or more of the words". I see there is a new key binding `C-h d' for `apropos-documentation'. Wouldn't it be better to reserve `C-h d' for something more useful and to bind `apropos-documentation' to a new key prefix `C-h a'? This will allow key bindings for the whole family of apropos commands: C-h a d - apropos-documentation C-h a v - apropos-variable C-h a c - apropos-command C-h a l - apropos-value C-h a a - apropos -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-15 0:52 ` Juri Linkov @ 2005-11-15 23:22 ` Richard M. Stallman 2005-11-17 7:38 ` Juri Linkov 0 siblings, 1 reply; 69+ messages in thread From: Richard M. Stallman @ 2005-11-15 23:22 UTC (permalink / raw) Cc: teirllm, emacs-devel a command-apropos. Give a list of words or a regexp, to get a list of commands whose names match (they contain two or more of the words, =========== or a match for the regexp). See also the apropos command. I don't understand why two or more of the words, if it is possible to give just one word and find a command whose names contains one word. Because, when you give multiple words, only instances that contain two or more of the words are shown. Maybe more correct text is "they contain one or more of the words". That would be incorrect, in the case of a list of two or more words. But I agree this is a problem. Who can find a correct solution? I see there is a new key binding `C-h d' for `apropos-documentation'. Wouldn't it be better to reserve `C-h d' for something more useful and to bind `apropos-documentation' to a new key prefix `C-h a'? Things are complex enough already, so I don't want to go that way. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-15 23:22 ` Richard M. Stallman @ 2005-11-17 7:38 ` Juri Linkov 2005-11-17 10:06 ` Kim F. Storm 0 siblings, 1 reply; 69+ messages in thread From: Juri Linkov @ 2005-11-17 7:38 UTC (permalink / raw) Cc: teirllm, emacs-devel > a command-apropos. Give a list of words or a regexp, to get a list of > commands whose names match (they contain two or more of the words, > =========== > or a match for the regexp). See also the apropos command. > > I don't understand why two or more of the words, if it is possible to > give just one word and find a command whose names contains one word. > > Because, when you give multiple words, only instances that contain > two or more of the words are shown. > > Maybe more correct text is "they contain one or more of the words". > > That would be incorrect, in the case of a list of two or more words. > But I agree this is a problem. Who can find a correct solution? What about not saying about the number of words: a command-apropos. Give a list of words or a regexp, to get a list of commands whose names match (they contain given words, or a match for the regexp). See also the apropos command. > I see there is a new key binding `C-h d' for `apropos-documentation'. > Wouldn't it be better to reserve `C-h d' for something more useful > and to bind `apropos-documentation' to a new key prefix `C-h a'? > > Things are complex enough already, so I don't want to go that way. Other useful apropos command are still unbound, so allocating a prefix key for them would be good. If not existing `C-h a', then maybe another prefix key like `C-h A' or `C-h C-a'. As for `C-h d', it might be useful to reserve it for other Help keys. For example, I think that `describe-char' which is currently on `C-u C-x =' is a typical Help command like other `describe-...' commands (`describe-key', `describe-function', `describe-mode', ...). I think it needs a key binding on the `C-h' keymap and also to be mentioned in `help-for-help-internal' and in the Help menu. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-17 7:38 ` Juri Linkov @ 2005-11-17 10:06 ` Kim F. Storm 0 siblings, 0 replies; 69+ messages in thread From: Kim F. Storm @ 2005-11-17 10:06 UTC (permalink / raw) Cc: teirllm, rms, emacs-devel Juri Linkov <juri@jurta.org> writes: > As for `C-h d', it might be useful to reserve it for other Help keys. IMO, apropos-documentation is often more useful than apropos-command currently on C-h a, and for a novice user, it makes little sense to restrict the search to just the command name. Perhaps we could put apropos-documenation on C-h a. That said, I also think that it would be very useful if C-h C-a was a prefix for the various apropos commands. > For example, I think that `describe-char' which is currently on `C-u > C-x =' is a typical Help command like other `describe-...' commands > (`describe-key', `describe-function', `describe-mode', ...). I think > it needs a key binding on the `C-h' keymap and also to be mentioned in > `help-for-help-internal' and in the Help menu. We have both C-h k and C-h c to describe key bindings (full and short story), so perhaps the C-h c binding could be used for "describe char at point". -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-07 15:34 ` Richard M. Stallman 2005-11-07 17:54 ` Drew Adams 2005-11-08 4:58 ` Luc Teirlinck @ 2005-11-09 23:25 ` Kim F. Storm 2005-11-10 5:44 ` Richard M. Stallman 2 siblings, 1 reply; 69+ messages in thread From: Kim F. Storm @ 2005-11-09 23:25 UTC (permalink / raw) Cc: Luc Teirlinck, emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > I looked at the previous discussion, and it seems to me that the > only change we need is in doc strings, prompts, and argument names. > Here's what I am thinking of installing. These changes are definitely an improvement. Could you please install those changes soon, so I can go on to fix the remaining issues with apropos. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: new apropos feature in Emacs-22 2005-11-09 23:25 ` Kim F. Storm @ 2005-11-10 5:44 ` Richard M. Stallman 0 siblings, 0 replies; 69+ messages in thread From: Richard M. Stallman @ 2005-11-10 5:44 UTC (permalink / raw) Cc: teirllm, emacs-devel Could you please install those changes soon, so I can go on to fix the remaining issues with apropos. I installed them. Thanks. ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2005-11-17 10:06 UTC | newest] Thread overview: 69+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-11-05 3:15 new apropos feature in Emacs-22 Luc Teirlinck 2005-11-05 10:26 ` Eli Zaretskii 2005-11-05 15:52 ` Luc Teirlinck 2005-11-05 16:43 ` Eli Zaretskii 2005-11-05 17:33 ` Drew Adams 2005-11-05 19:46 ` Eli Zaretskii 2005-11-05 20:38 ` Drew Adams 2005-11-05 22:10 ` Luc Teirlinck 2005-11-05 23:00 ` Kim F. Storm 2005-11-05 23:18 ` Lennart Borgman 2005-11-05 23:28 ` Luc Teirlinck 2005-11-05 23:37 ` Lennart Borgman 2005-11-05 23:31 ` Drew Adams 2005-11-05 23:36 ` Drew Adams 2005-11-05 23:39 ` Lennart Borgman 2005-11-05 23:21 ` Drew Adams 2005-11-06 1:57 ` Luc Teirlinck 2005-11-06 4:32 ` Eli Zaretskii 2005-11-06 5:36 ` Luc Teirlinck 2005-11-06 17:05 ` Eli Zaretskii 2005-11-06 17:22 ` David Kastrup 2005-11-06 18:43 ` Eli Zaretskii 2005-11-06 18:31 ` Luc Teirlinck 2005-11-06 18:46 ` Eli Zaretskii 2005-11-07 9:45 ` Alan Mackenzie 2005-11-07 20:43 ` Eli Zaretskii 2005-11-07 20:58 ` Eli Zaretskii 2005-11-07 21:54 ` Richard M. Stallman 2005-11-06 20:16 ` Luc Teirlinck 2005-11-06 22:54 ` Kim F. Storm 2005-11-06 18:47 ` Kim F. Storm 2005-11-06 19:19 ` Luc Teirlinck 2005-11-07 7:04 ` Luc Teirlinck 2005-11-07 21:55 ` Richard M. Stallman 2005-11-06 9:19 ` David Kastrup 2005-11-05 17:39 ` Luc Teirlinck 2005-11-06 17:02 ` Stefan Monnier 2005-11-06 17:08 ` Eli Zaretskii 2005-11-06 19:55 ` Luc Teirlinck 2005-11-05 23:43 ` Richard M. Stallman 2005-11-06 0:27 ` Luc Teirlinck 2005-11-07 15:34 ` Richard M. Stallman 2005-11-07 17:54 ` Drew Adams 2005-11-07 18:56 ` Stefan Monnier 2005-11-07 19:25 ` Drew Adams 2005-11-07 22:39 ` Lennart Borgman 2005-11-07 20:52 ` Eli Zaretskii 2005-11-07 22:59 ` Drew Adams 2005-11-08 4:47 ` Eli Zaretskii 2005-11-08 4:58 ` Luc Teirlinck 2005-11-08 12:48 ` Kim F. Storm 2005-11-08 23:53 ` Miles Bader 2005-11-09 0:21 ` Lennart Borgman 2005-11-11 7:42 ` Richard M. Stallman 2005-11-11 9:29 ` Kim F. Storm 2005-11-11 10:57 ` Miles Bader 2005-11-11 16:16 ` Kim F. Storm 2005-11-12 3:38 ` Richard M. Stallman 2005-11-12 3:15 ` Luc Teirlinck 2005-11-12 17:49 ` Richard M. Stallman 2005-11-12 3:36 ` Luc Teirlinck 2005-11-12 21:19 ` Juri Linkov 2005-11-14 4:55 ` Richard M. Stallman 2005-11-15 0:52 ` Juri Linkov 2005-11-15 23:22 ` Richard M. Stallman 2005-11-17 7:38 ` Juri Linkov 2005-11-17 10:06 ` Kim F. Storm 2005-11-09 23:25 ` Kim F. Storm 2005-11-10 5:44 ` Richard M. Stallman
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.