Re: Word search

Re: Word search

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]


Sorry Drew,

There was a mistake in my mail, I did not mean "C-sC-w" but I meant 
"C-sC-w". I tested it again and it does not work.

That you for the information on the incremental word search 
("C-sM-eC-w"). I tested it on the same node, and whether I terminate by 
"C-s" or  by "" it fails in the same way. To tell you the truth, I 
had not even tried that, as the plain non incremental one was not 
working in the first place.

Regards,
       Vincent.

Drew Adams a écrit :
> 	I fully agree with Juri's point that the current keys to enter word 
> 	search is inconvenient, and I find the double meaning of C-w between 
> 	usual editing and word search difficult (I would prefer to have a less 
> 	easy to remember key to enter word search provided that that it does not
>
> 	overload the meaning of usual edition keys like C-w).
>
> C-s C-w is not word search in the sense that you write below. C-s C-w yanks
> characters or words into the search string, starting at the cursor position.
> 	
> 	FYI, unfortunately I was never able to have word search work properly. 
> 	For instance, when I try word search in the *info* node "Word search" 
> 	and I type "C-sC-w" then I type "the words" (all of these things 
> 	without double quotes) and then I type "", I would expect to find 
> 	the first occurrence at the end of first line of info node text which is
> :
> 	
> 	---- excerpt from info node Word Search --------------
> 	Word search searches for a sequence of words without regard to how the
> 	words are separated. More precisely, you type a string of many words,
> 	---- end of excerpt -------------------------------------
> 	
> I think what you want is incremental search for words. In vanilla Emacs you can
> get to it this way: `C-s M-e C-w' - this is mentioned in the Emacs manual node
> you cited, Word Search. Library isearch+.el binds the same thing to `C-s M-w',
> which is a bit easier to use. 
>
> FYI, isearch+.el is here: http://www.emacswiki.org/cgi-bin/wiki/isearch%2b.el.
> It is described here: http://www.emacswiki.org/cgi-bin/wiki/IsearchPlus.
>
>
>
>
>
>   



_________________________________________________________________
Créez gratuitement votre disque dur virtuel Windows Live SkyDrive !
http://skydrive.live.com

[-- Attachment #2: Type: text/html, Size: 2631 bytes --]

RE: Word search

[Drew Adams]

Two comments: (1) help-gnu-emacs@gnu.org might be a more appropriate list.
Consider moving this there. (2) Please use plain-text for these mailing lists.

	Sorry Drew, There was a mistake in my mail, I did not mean
      "C-sC-w" but I meant "C-sC-w".

What's the difference? They look the same to me.

      I tested it again and it does not work.
	
	That you for the information on the incremental word search 
	("C-sM-eC-w"). I tested it on the same node, and whether I terminate by 
	"C-s" or by "" it fails in the same way. To tell you the truth, I 
	had not even tried that, as the plain non incremental one was not 
	working in the first place.

Not sure what you mean by terminate by "C-s" or by "". Does it at least work, in
the sense that it finds what you are looking for, regardless of how you
terminate the search? To terminate the search, you can just use RET or an arrow
key or another non-isearch key (except C-g). What do you mean by ""?

Re: Word search

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 3582 bytes --]


Dear Drew,

I am realizing that there was no mistake in the mail before the latest 
one I sent, but that the mailing system has stripped off a part of it. 
What I meant was "C-sxxxC-w" where instread of "xxx" I had written "RET" 
between less-than and greater-than signs. But it seems that this xxx has 
been stripped off by the mailing system.
Similarly I meant that I terminated the interactive search by "C-s" or 
by "xxx" where xxx has the same meaning as above (a carriage return 
key). The fact is that I am writing to you with Thunderbird using an 
adds-on that allows to use hotmail without going through the Web 
interface (it seems that there is some bug with this when HTML is used).

More  answers embedded below (please read at least the last one) :

Drew Adams a écrit :
> Two comments: (1) help-gnu-emacs@gnu.org might be a more appropriate list.
> Consider moving this there. (2) Please use plain-text for these mailing lists.
>
> 	Sorry Drew, There was a mistake in my mail, I did not mean
>       "C-sC-w" but I meant "C-sC-w".
>
> What's the difference? They look the same to me.
>   

They were not the same when I sent the mail there was RET bracketted 
with LT and GT signs in between "C-s" and "C-w". So when I am sending 
this mail "C-sC-w" is different from "C-sC-w"
>       I tested it again and it does not work.
> 	
> 	That you for the information on the incremental word search 
> 	("C-sM-eC-w"). I tested it on the same node, and whether I terminate by 
> 	"C-s" or by "" it fails in the same way. To tell you the truth, I 
> 	had not even tried that, as the plain non incremental one was not 
> 	working in the first place.
>
> Not sure what you mean by terminate by "C-s" or by "". 
When I sent the mail between the pair of double quotes "" there was a 
RET bracketted by LT and GT signs. So when I ma sending this mail "" is 
different from "".
> Does it at least work, in
> the sense that it finds what you are looking for, regardless of how you
> terminate the search? 
It does not find what I am looking for. When I type "C-sM-eC-w" I enter 
Incremental word search (I can see that as on the left side of the 
minibuffer is written "Word I-search").  Then if I type "the words" and 
then RET   I get an error message "[(wrong-type-argument 
integer-or-marker-p t)]" and the cursor of the *info* buffer remains at 
the same position, that is to say on the Top Left of the window, just on 
the "F" in "File: emacs,  Node: Word Search,  Next: Regexp Search,  
Prev: Nonincremental Search,  Up: Search"

More strange is the following: if I enter again the incremental word 
search, and I type on the right arrow key, what happens is that the 
content of the *info* buffer is copied character by character into the 
minibuffer. That is to say, assume that I type 5 times on the right 
arrow key, then the effect is as if I had entered the five characters 
"F" "i" "l" "e" and ":" consecutively (remember that when I enter the 
Word-I-search the *info* buffer point is pointing at the beginning the 
text "File: emacs,  Node: Word Search,  Next: Regexp Search,  Prev: 
Nonincremental Search,  Up: Search"

Regards,
       Vincent.
> To terminate the search, you can just use RET or an arrow
> key or another non-isearch key (except C-g). What do you mean by ""?
>
>
>
>   



_________________________________________________________________
Votre contact a choisi Hotmail, l'e-mail ultra sécurisé. Créez un compte gratuitement !
http://www.windowslive.fr/hotmail/default.asp

[-- Attachment #2: Type: text/html, Size: 3906 bytes --]

RE: Word search

[Drew Adams]

Again, please use plain-text mail, not HTML mail.

	From: Vincent Belaïche Sent: Wednesday, March 26, 2008 1:48 PM
	I am realizing that there was no mistake in the mail before the latest 
	one I sent, but that the mailing system has stripped off a part of it. 
	What I meant was "C-sxxxC-w" where instread of "xxx" I had written "RET"

	between less-than and greater-than signs. But it seems that this xxx has

	been stripped off by the mailing system.
	Similarly I meant that I terminated the interactive search by "C-s" or 
	by "xxx" where xxx has the same meaning as above (a carriage return 
	key). 

C-s does not terminate isearch. But RET (hitting `Enter') should.

	The fact is that I am writing to you with Thunderbird using an 
	adds-on that allows to use hotmail without going through the Web 
	interface (it seems that there is some bug with this when HTML is used).

Please do not use an HTML mail format for this mailing list. Please find out how
to use your plug-in or Thunderbird in a way that sends plain-text mail.
	
	> Two comments: (1) help-gnu-emacs@gnu.org might be a more appropriate
list.
	> Consider moving this there. (2) Please use plain-text for these
mailing lists.
	>
	> Sorry Drew, There was a mistake in my mail, I did not mean
	> "C-sC-w" but I meant "C-sC-w".
	>
	> What's the difference? They look the same to me.
	
	They were not the same when I sent the mail there was RET bracketted 
	with LT and GT signs in between "C-s" and "C-w". So when I am sending 
	this mail "C-sC-w" is different from "C-sC-w"

I cannot follow you. I don't see the difference in the HTML mail you sent.
Please use plain text and type the text you want people to read.

	> I tested it again and it does not work.
	> 
	> That you for the information on the incremental word search 
	> ("C-sM-eC-w"). I tested it on the same node, and whether I terminate
by 
	> "C-s" or by "" it fails in the same way. To tell you the truth, I 
	> had not even tried that, as the plain non incremental one was not 
	> working in the first place.
	>
	> Not sure what you mean by terminate by "C-s" or by "". 

	When I sent the mail between the pair of double quotes "" there was a 
	RET bracketted by LT and GT signs. So when I ma sending this mail "" is 
	different from "".

As you can see, it doesn't appear that way. Please use plain text, not HTML.

	> Does it at least work, in
	> the sense that it finds what you are looking for, regardless of how
you
	> terminate the search? 

	It does not find what I am looking for. When I type "C-sM-eC-w" I enter 
	Incremental word search (I can see that as on the left side of the 
	minibuffer is written "Word I-search"). Then if I type "the words" and 
	then RET I get an error message "[(wrong-type-argument 
	integer-or-marker-p t)]" 

That sounds like a bug. Please report it using `M-x report-emacs-bug'. Describe
step by step how to reproduce the problem, starting from emacs -Q (that is, with
no .emacs).

	...
	More strange is the following: if I enter again the incremental word 
	search, and I type on the right arrow key, what happens is that the 
	content of the *info* buffer is copied character by character into the 
	minibuffer. That is to say, assume that I type 5 times on the right 
	arrow key, then the effect is as if I had entered the five characters 
	"F" "i" "l" "e" and ":" consecutively (remember that when I enter the 
	Word-I-search the *info* buffer point is pointing at the beginning the 
	text "File: emacs, Node: Word Search, Next: Regexp Search, Prev: 
	Nonincremental Search, Up: Search"

I believe that is normal; the text is copied from the source buffer to the
isearch edit area. You then must hit RET to accept the edited text as your
search string. Then hit C-s to search for that text.

FYI: help-gnu-emacs@gnu.org is for help questions. M-x report-emacs-bug is for
bug reports. emacs-devel@gnu.org is for discussion of Emacs development.

Re: Word search

[Vincent Belaïche]

Dear Drew,

Thank you for your patience with me, and sorry for the disturbance. 
Finally I created another email address on Google, because the one on 
hotmail was too difficult to use in plain text. Please tell me clearly 
if you wish me to file a bug and stop any disturbance on this developers 
only list as you seemed to suggest in your previous email.

I am writing again to you as I made some more investigation on my word 
search problem, and I have more news about it. Hereinafter I tried only 
non-interactive word search with the sequence "C-s<RET>C-w SEARCHED FOR 
WORD SEQUENCE <RET>".

1) It *DOES NOT FULLY* work in *info* node "Word Search", which is 
better than *FULLY DOES NOT WORK* :
1.1) In the case of an existing word sequence, it will not find it. If 
for instance I search for the word sequence "the words" it will not find 
it, whereas this word sequence is at end of 1st line of text. The search 
will exit with the message in the minibuffer "[(wrong-type-argument 
integer-or-marker-p t)]" tailing the current content of minibuffer.
1.2) however, in the case of a non existing word sequence, it will 
correctly exit indicating that the sequence does not exists. For 
instance if in the same node I search for the word sequence "Drew 
Adams", it will cleanly exit with the following content of the 
minibuffer "Failing word search: Drew Adams [initial mode]"

2) however it FULLY works in the *scratch* buffer : it does not find 
anything if the sequence does not exist in the buffer, and it finds 
something if the sequence does exists. If for instance I search for 
"evaluation If" it will correctly point at the end of first word in 
second line

3) When in the *info* node "Word Search"  messages appear between square 
bracket at the end of the search buffer, which is not the same behaviour 
as in other modes (such message do not occur there, maybe some traces 
intended for debug only have been forgotten to disable).

4) The failure does not depend of which *info* node is considered (I 
made the same type of test in the Top node, as the point value fits into 
16 bits there).

5) Still in the *info* node "Word Search", I switched the buffer to text 
mode by the sequence "M-x text-mode", then I tried to make the same word 
search (searching for "the words") and it worked !

6) I opened some LaTeX files of mine, and tested word search there, and 
it also works in LaTeX-mode.

7) Then, I simply tried "M-x word-search-forward" in the *info* node 
"Word search" that was again in info mode (not text mode) to make the 
word search, I entered the word sequence "the words", and it worked ! So 
this is very strange, word search does not work in info mode when it is 
invoked though the "C-s<RET>C-w" key sequence, but it does work if it is 
invoked directly by "M-x word-search-forward"


Sorry for the long mail, I am just hoping that this information is 
useful to Emacs developpers,
            Vincent.

PS-1: FYI, when I sent my 1st email, I thought that word search was not 
working at all in my environment because when I learn things from *info* 
I try them as I am reading the documentation. So even if word search is 
not that useful in *info* as such, it is useful in the sense that people 
trying the command as they read the document may be puzzled by not 
achieving it working, and then may not use the command at all as this 
was my case for years ! So I am spamming again this email list only for 
the benefit of the community : I personally don't need to make word 
searches in *info*, I need that only in LaTeX, and it works there.

PS-2: You wrote :

> I believe that is normal; the text is copied from the source buffer to the
> isearch edit area. You then must hit RET to accept the edited text as your
> search string. Then hit C-s to search for that text.


Sorry to have believed that an arrow key could be used to terminate the 
sequence of words to be searched for. Actually  I was trying ARROW RIGHT 
because in the mail you sent before you had written :

> To terminate the search, you can just use RET or an arrow
> key or another non-isearch key (except C-g).


I now am realizing that there was a misunderstanding, because I meant to 
terminate the word sequence to be searched for so that search is 
executed as it is in the sate when the search sequence is entered by 
user, and you understood that I was trying to terminate the incremental 
search processes whereas it is in the state when the search is waiting 
for some more command (e.g. to search next occurrence).

This made me realize that the documentation on incremental word search 
is not that clear, I may contribute later on on this. But I think that 
some other problems concerning the way as the incremental word search is 
invoked and accessed have to be solved first.


Drew Adams a écrit :
> Again, please use plain-text mail, not HTML mail.
>
> 	From: Vincent Belaïche Sent: Wednesday, March 26, 2008 1:48 PM
> 	I am realizing that there was no mistake in the mail before the latest 
> 	one I sent, but that the mailing system has stripped off a part of it. 
> 	What I meant was "C-sxxxC-w" where instread of "xxx" I had written "RET"
>
> 	between less-than and greater-than signs. But it seems that this xxx has
>
> 	been stripped off by the mailing system.
> 	Similarly I meant that I terminated the interactive search by "C-s" or 
> 	by "xxx" where xxx has the same meaning as above (a carriage return 
> 	key). 
>
> C-s does not terminate isearch. But RET (hitting `Enter') should.
>
> 	The fact is that I am writing to you with Thunderbird using an 
> 	adds-on that allows to use hotmail without going through the Web 
> 	interface (it seems that there is some bug with this when HTML is used).
>
> Please do not use an HTML mail format for this mailing list. Please find out how
> to use your plug-in or Thunderbird in a way that sends plain-text mail.
> 	
> 	> Two comments: (1) help-gnu-emacs@gnu.org might be a more appropriate
> list.
> 	> Consider moving this there. (2) Please use plain-text for these
> mailing lists.
> 	>
> 	> Sorry Drew, There was a mistake in my mail, I did not mean
> 	> "C-sC-w" but I meant "C-sC-w".
> 	>
> 	> What's the difference? They look the same to me.
> 	
> 	They were not the same when I sent the mail there was RET bracketted 
> 	with LT and GT signs in between "C-s" and "C-w". So when I am sending 
> 	this mail "C-sC-w" is different from "C-sC-w"
>
> I cannot follow you. I don't see the difference in the HTML mail you sent.
> Please use plain text and type the text you want people to read.
>
> 	> I tested it again and it does not work.
> 	> 
> 	> That you for the information on the incremental word search 
> 	> ("C-sM-eC-w"). I tested it on the same node, and whether I terminate
> by 
> 	> "C-s" or by "" it fails in the same way. To tell you the truth, I 
> 	> had not even tried that, as the plain non incremental one was not 
> 	> working in the first place.
> 	>
> 	> Not sure what you mean by terminate by "C-s" or by "". 
>
> 	When I sent the mail between the pair of double quotes "" there was a 
> 	RET bracketted by LT and GT signs. So when I ma sending this mail "" is 
> 	different from "".
>
> As you can see, it doesn't appear that way. Please use plain text, not HTML.
>
> 	> Does it at least work, in
> 	> the sense that it finds what you are looking for, regardless of how
> you
> 	> terminate the search? 
>
> 	It does not find what I am looking for. When I type "C-sM-eC-w" I enter 
> 	Incremental word search (I can see that as on the left side of the 
> 	minibuffer is written "Word I-search"). Then if I type "the words" and 
> 	then RET I get an error message "[(wrong-type-argument 
> 	integer-or-marker-p t)]" 
>
> That sounds like a bug. Please report it using `M-x report-emacs-bug'. Describe
> step by step how to reproduce the problem, starting from emacs -Q (that is, with
> no .emacs).
>
> 	...
> 	More strange is the following: if I enter again the incremental word 
> 	search, and I type on the right arrow key, what happens is that the 
> 	content of the *info* buffer is copied character by character into the 
> 	minibuffer. That is to say, assume that I type 5 times on the right 
> 	arrow key, then the effect is as if I had entered the five characters 
> 	"F" "i" "l" "e" and ":" consecutively (remember that when I enter the 
> 	Word-I-search the *info* buffer point is pointing at the beginning the 
> 	text "File: emacs, Node: Word Search, Next: Regexp Search, Prev: 
> 	Nonincremental Search, Up: Search"
>
> I believe that is normal; the text is copied from the source buffer to the
> isearch edit area. You then must hit RET to accept the edited text as your
> search string. Then hit C-s to search for that text.
>
> FYI: help-gnu-emacs@gnu.org is for help questions. M-x report-emacs-bug is for
> bug reports. emacs-devel@gnu.org is for discussion of Emacs development.
>
>
>
>
>   

RE: Word search

[Drew Adams]

> Please tell me clearly if you wish me to file a bug

Your latest mail seems clear enough. The only missing info is the Emacs version.
I see the same things you describe in the Emacs 22.1 release:

In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
 of 2007-06-02 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/include'

FYI, an advantage of using `M-x report-emacs-bug' is that it sends this info and
more along with your text, and it sends it to the proper mailing list, depending
on the Emacs version used. But what you have sent now seems clear enough.
Thanks.

Re: Word search

[Vincent Belaïche]

Dear Drew,

Here is the version information provided by the report-emacs-bug command

In GNU Emacs 22.0.990.1 (i386-mingw-nt5.0.2195)
  of 2007-05-31 on COCOTTE
Windowing system distributor `Microsoft Corp.', version 5.0.2195
configured using `configure --with-gcc (3.4) --cflags 
-Ic:/Programme/GnuWin32/include'

       Vincent

PS-1 : I am under the process of configuring my Emacs to send mail with 
it with the SMTP library, when this is done, I promise that I use 
report-emacs-bug ;-).
PS-2 : There is no such include path as "/Programme/GnuWin32/include" on 
my PC, it compiled with the minGw libs for Windows.


Drew Adams a écrit :
>> Please tell me clearly if you wish me to file a bug
> 
> Your latest mail seems clear enough. The only missing info is the Emacs version.
> I see the same things you describe in the Emacs 22.1 release:
> 
> In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
>  of 2007-06-02 on RELEASE
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/include'
> 
> FYI, an advantage of using `M-x report-emacs-bug' is that it sends this info and
> more along with your text, and it sends it to the proper mailing list, depending
> on the Emacs version used. But what you have sent now seems clear enough.
> Thanks.
> 
> 

RE: Word search

[Drew Adams]

> PS-1 : I am under the process of configuring my Emacs to send 
> mail with it with the SMTP library, when this is done, I
> promise that I use report-emacs-bug ;-).

FYI - `M-x report-emacs-bug' should work with any mail client. You need not wait
until you configure Emacs to be your mail client.

I use `M-x report-emacs-bug' with MS Outlook as my mail client, for instance.
Exiting the bug report buffer with `C-c C-c' and confirming sending causes the
mail client to open a new message pre-addressed to the proper mailing list. I
just paste into the message body and then click Send. When you exit
`report-emacs-bug', it copies the report buffer contents, so you can immediately
paste them into your mail body.

Of course, if you do use Emacs for your mail client, so much the better. HTH.

Re: Word search

[Johan Bockgård]

Vincent Belaïche <vincent.belaiche@gmail.com> writes:

> If for instance I search for the word sequence "the words" it will not
> find it, whereas this word sequence is at end of 1st line of text. The
> search will exit with the message in the minibuffer
> "[(wrong-type-argument integer-or-marker-p t)]"

I already fixed this after your original report, five days ago.

Thanks.

-- 
Johan Bockgård

Re: Word search

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 2412 bytes --]


Hello valuated Emacs developpers,

Just to answer Richard's suggestion "let's ask them" and the wish to 
poll users : I am new to this mailing list and one suggestion I was 
going to make was concerning word search, when I discovered that this 
was already being discussed.

I am using Emacs mainly for editing LaTeX documents where auto-fill-mode 
+ indentation is active, and therefore word search is a must and 
incremental word search is a very very nice to have.

I fully agree with Juri's point that the current keys to enter word 
search is inconvenient, and I find the double meaning of C-w between 
usual editing and word search difficult (I would prefer to have a less 
easy to remember key to enter word search provided that that it does not 
overload the meaning of usual edition keys like C-w).

FYI, unfortunately I was never able to have word search work properly. 
For instance, when I try word search in the *info* node "Word search" 
and I type "C-sC-w" then I type "the words" (all of these things 
without double quotes) and then I type "", I would expect to find 
the first occurrence at the end of first line of info node text which is :

---- excerpt from info node Word Search --------------
Word search searches for a sequence of words without regard to how the
words are separated.  More precisely, you type a string of many words,
---- end of excerpt -------------------------------------

Instead of that, I get the following error message : 
"[(wrong-type-argument integer-or-marker-p t)]" which is displayed in 
the Minibuffer and has no trace in the *Message* buffer. Is that normal 
? My emacs version is "GNU Emacs 22.0.990.1 (i386-mingw-nt5.0.2195) of 
2007-05-31".

Sorry to dwell on it, if this is an already known or solved problem, I 
am jumping into this thread without having read all of it since the 
beginning.

BR,
        Vincent.


Richard Stallman a écrit :
>     But I doubt that many people use it because for many years of existence
>     of word search, very few people tried to find a way to enable incremental
>     word search (according to mailing list archives) until recently.
>
> Maybe you're right.  But let's ask them.
>
>
>
>
>   



_________________________________________________________________
Créez gratuitement votre disque dur virtuel Windows Live SkyDrive !
http://skydrive.live.com

[-- Attachment #2: Type: text/html, Size: 2743 bytes --]

Re: Word search

[Jason Rumney]

Vincent Belaïche wrote:
> FYI, unfortunately I was never able to have word search work properly.
> For instance, when I try word search in the *info* node "Word search"
> and I type "C-s C-w" then I type "the words" (all of these things
> without double quotes) and then I type " ", I would expect to find
> the first occurrence at the end of first line of info node text which is :
>
> ---- excerpt from info node Word Search --------------
> Word search searches for a sequence of words without regard to how the
> words are separated. More precisely, you type a string of many words,
> ---- end of excerpt -------------------------------------
>
> Instead of that, I get the following error message :
> "[(wrong-type-argument integer-or-marker-p t)]" which is displayed in
> the Minibuffer and has no trace in the *Message* buffer. Is that normal

I get this error with emacs -Q, but not when I execute the following 
three lines:

(require 'cedet)
(semantic-load-enable-minimum-features)
(global-semantic-idle-summary-mode 1)

So something in the mess of macros and hooks that implements 
global-semantic-idle-summary-mode seems to be fixing the problem.

Re: Word search

[Juri Linkov]

>> FYI, unfortunately I was never able to have word search work properly.
>> For instance, when I try word search in the *info* node "Word search"
>> and I type "C-s C-w" then I type "the words" (all of these things
>> without double quotes) and then I type " ", I would expect to find
>> the first occurrence at the end of first line of info node text which is :
>>
>> ---- excerpt from info node Word Search --------------
>> Word search searches for a sequence of words without regard to how the
>> words are separated. More precisely, you type a string of many words,
>> ---- end of excerpt -------------------------------------
>>
>> Instead of that, I get the following error message :
>> "[(wrong-type-argument integer-or-marker-p t)]" which is displayed in
>> the Minibuffer and has no trace in the *Message* buffer. Is that normal
>
> I get this error with emacs -Q, but not when I execute the following three
> lines:
>
> (require 'cedet)
> (semantic-load-enable-minimum-features)
> (global-semantic-idle-summary-mode 1)
>
> So something in the mess of macros and hooks that implements
> global-semantic-idle-summary-mode seems to be fixing the problem.

I have seen reports about `semantic' blocking isearch in Info because
it overwrites isearch functions with its own.  Even though it seems not
the problem reported by OP, I think we should find a way to avoid a
problem of conflicts between packages that redefine isearch functions.

But maybe there is no problem at all, if `semantic' doesn't really need
to change isearch functions in Info.  Then there is a bug in `semantic'
if it does this unintentionally.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Word search

[Drew Adams]

	I fully agree with Juri's point that the current keys to enter word 
	search is inconvenient, and I find the double meaning of C-w between 
	usual editing and word search difficult (I would prefer to have a less 
	easy to remember key to enter word search provided that that it does not

	overload the meaning of usual edition keys like C-w).

C-s C-w is not word search in the sense that you write below. C-s C-w yanks
characters or words into the search string, starting at the cursor position.
	
	FYI, unfortunately I was never able to have word search work properly. 
	For instance, when I try word search in the *info* node "Word search" 
	and I type "C-sC-w" then I type "the words" (all of these things 
	without double quotes) and then I type "", I would expect to find 
	the first occurrence at the end of first line of info node text which is
:
	
	---- excerpt from info node Word Search --------------
	Word search searches for a sequence of words without regard to how the
	words are separated. More precisely, you type a string of many words,
	---- end of excerpt -------------------------------------
	
I think what you want is incremental search for words. In vanilla Emacs you can
get to it this way: `C-s M-e C-w' - this is mentioned in the Emacs manual node
you cited, Word Search. Library isearch+.el binds the same thing to `C-s M-w',
which is a bit easier to use. 

FYI, isearch+.el is here: http://www.emacswiki.org/cgi-bin/wiki/isearch%2b.el.
It is described here: http://www.emacswiki.org/cgi-bin/wiki/IsearchPlus.

Re: Word search

[Johan Bockgård]

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:

> Instead of that, I get the following error message :
> "[(wrong-type-argument integer-or-marker-p t)]" which is displayed in
> the Minibuffer and has no trace in the *Message* buffer. Is that
> normal ?

Thanks for the report.  I've checked in a fix.

-- 
Johan Bockgård

First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Tobias Bading]

Hello everyone,

I'm using Emacs 22.1 compiled under MacOS X and Windoze XP from the  
EMACS_22_1 tag in the cvs repository for quite some time now and both  
of 'em work great, wouldn't want to live without them :-). However,  
there's a minor bug that really bugs me. It is reproducible on both  
platforms without any customizations, i.e. my .emacs file moved out  
of the way. It goes like this:
Start a fresh emacs, then C-s 1 RET, C-s 2 RET, C-s 3 RET to search  
for "1", "2" and "3". The value of variable search-ring is ("3" "2"  
"1") now. So far, so good. Now, let's try to search for "1" again  
using M-p (isearch-ring-retreat) in isearch-mode. A C-s C-s searches  
for "3", now a M-p and you're searching for "2", but the next M-p  
does not search for "1", but for "3" again! And another M-p brings  
you to "2". This is what I noticed on both platforms: After the  
initial C-s C-s sequence, the minibuffer shows "I-search: 3", the  
cursor is still in your buffer and the tool bar as well as the menu  
bar remain unchanged. After the first M-p the minibuffer displays "I- 
search: 2" and the cursor is at the end of the minibuffer. However,  
the tool bar and the menu bar still remain unchanged. I guess this is  
part of the problem, because the second M-p finally adapts the tool  
bar and the menu bar to the fact that the cursor is in the minibuffer  
now, i.e. the Minibuf menu item appears and a few icons are grayed  
out. Unfortunately, the second M-p also jumps back to the first  
element of search-ring instead of showing the third element. So to  
reach the third element of search-ring, you have to press M-p four  
times instead of twice :-(. I hope I'm not the only one having this  
problem and that there's a fix available :-).

Have a nice weekend,
Tobias

PS: The frame's title is incorrect after the first M-p as well,  
noticeable if you have a (setq frame-title-format "Emacs: %b") in  
your .emacs file.

PPS: isearch-forward-regexp has the same problem :-(.

Re: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Juri Linkov]

> I'm using Emacs 22.1 compiled under MacOS X and Windoze XP from the
> EMACS_22_1 tag in the cvs repository for quite some time now and both  of
> em work great, wouldn't want to live without them :-). However,  there's
> a minor bug that really bugs me. It is reproducible on both  platforms
> without any customizations, i.e. my .emacs file moved out  of the way. It
> goes like this:
> Start a fresh emacs, then C-s 1 RET, C-s 2 RET, C-s 3 RET to search for
> "1", "2" and "3". The value of variable search-ring is ("3" "2"  "1")
> now. So far, so good. Now, let's try to search for "1" again  using M-p
> (isearch-ring-retreat) in isearch-mode. A C-s C-s searches  for "3", now
> a M-p and you're searching for "2", but the next M-p  does not search for
> "1", but for "3" again! And another M-p brings  you to "2". This is what
> I noticed on both platforms: After the  initial C-s C-s sequence, the
> minibuffer shows "I-search: 3", the  cursor is still in your buffer and
> the tool bar as well as the menu  bar remain unchanged. After the first
> M-p the minibuffer displays "I-
> search: 2" and the cursor is at the end of the minibuffer. However, the
> tool bar and the menu bar still remain unchanged. I guess this is  part of
> the problem, because the second M-p finally adapts the tool  bar and the
> menu bar to the fact that the cursor is in the minibuffer  now, i.e. the
> Minibuf menu item appears and a few icons are grayed  out. Unfortunately,
> the second M-p also jumps back to the first  element of search-ring
> instead of showing the third element. So to  reach the third element of
> search-ring, you have to press M-p four  times instead of
> twice :-(. I hope I'm not the only one having this  problem and that
> there's a fix available :-).

Thank you for the bug report.  I hope it is possible to fix this
undesirable behavior by using the HISTPOS argument of read-from-minibuffer
where HISTPOS will point to the correct history position in the search
ring.  This also gives us the opportunity to rewrite isearch-edit-string
to remove unnecessary ad-hoc minibuffer precessing tricks that cause the
incorrect behavior you described in the second part of your bug report.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Juri Linkov]

> Thank you for the bug report.  I hope it is possible to fix this
> undesirable behavior by using the HISTPOS argument of read-from-minibuffer
> where HISTPOS will point to the correct history position in the search
> ring.  This also gives us the opportunity to rewrite isearch-edit-string
> to remove unnecessary ad-hoc minibuffer precessing tricks that cause the
> incorrect behavior you described in the second part of your bug report.

Below is a patch that fixes all these problems.  It uses
search-ring-yank-pointer and regexp-search-ring-yank-pointer
for the HISTPOS argument of read-from-minibuffer that gives
the correct initial minibuffer search history position for
isearch-edit-string.

It also gets rid of all trickery used to read the first character
typed in the minibuffer (that removes another set of problems;
see related old bug reports).  It adds a new backward-compatible
command `isearch-edit-string-set-word' bound to C-w in the minibuffer
that calls `kill-region' when the mark is active, and otherwise does
word search after exiting `isearch-edit-string' (the mark is not active
when `isearch-edit-string' just created the minibuffer, and without
the mark `kill-region' would fail anyway).

This preserves the behavior described in the Emacs manual:

`C-s <RET> C-w WORDS <RET>'
     Search for WORDS, ignoring details of punctuation.

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.313
diff -c -r1.313 isearch.el
*** lisp/isearch.el	28 Feb 2008 01:57:42 -0000	1.313
--- lisp/isearch.el	9 Mar 2008 21:57:02 -0000
***************
*** 436,441 ****
--- 436,442 ----
      (define-key map "\M-\t" 'isearch-complete-edit)
      (define-key map "\C-s"  'isearch-forward-exit-minibuffer)
      (define-key map "\C-r"  'isearch-reverse-exit-minibuffer)
+     (define-key map "\C-w"  'isearch-edit-string-set-word)
      (define-key map "\C-f"  'isearch-yank-char-in-minibuffer)
      (define-key map [right] 'isearch-yank-char-in-minibuffer)
      map)
***************
*** 1025,1061 ****
  	  ;; that can change their values.
  	  (setq old-point (point) old-other-end isearch-other-end)
  
- 	  (isearch-message) ;; for read-char
  	  (unwind-protect
! 	      (let* (;; Why does following read-char echo?
! 		     ;;(echo-keystrokes 0) ;; not needed with above message
! 		     (e (let ((cursor-in-echo-area t))
! 			  (read-event)))
  		     ;; Binding minibuffer-history-symbol to nil is a work-around
  		     ;; for some incompatibility with gmhist.
! 		     (minibuffer-history-symbol)
! 		     (message-log-max nil))
! 		;; If the first character the user types when we prompt them
! 		;; for a string is the yank-word character, then go into
! 		;; word-search mode.  Otherwise unread that character and
! 		;; read a key the normal way.
! 		;; Word search does not apply (yet) to regexp searches,
! 		;; no check is made here.
! 		(message "%s" (isearch-message-prefix nil nil t))
! 		(if (memq (lookup-key isearch-mode-map (vector e))
! 			  '(isearch-yank-word
! 			    isearch-yank-word-or-char))
! 		    (setq isearch-word t;; so message-prefix is right
! 			  isearch-new-word t)
! 		  (cancel-kbd-macro-events)
! 		  (isearch-unread e))
! 		(setq cursor-in-echo-area nil)
  		(setq isearch-new-string
                        (read-from-minibuffer
                         (isearch-message-prefix nil nil isearch-nonincremental)
                         isearch-string
                         minibuffer-local-isearch-map nil
!                        (if isearch-regexp 'regexp-search-ring 'search-ring)
                         nil t)
  		      isearch-new-message
  		      (mapconcat 'isearch-text-char-description
--- 1026,1046 ----
  	  ;; that can change their values.
  	  (setq old-point (point) old-other-end isearch-other-end)
  
  	  (unwind-protect
! 	      (let* ((message-log-max nil)
  		     ;; Binding minibuffer-history-symbol to nil is a work-around
  		     ;; for some incompatibility with gmhist.
! 		     (minibuffer-history-symbol))
  		(setq isearch-new-string
                        (read-from-minibuffer
                         (isearch-message-prefix nil nil isearch-nonincremental)
                         isearch-string
                         minibuffer-local-isearch-map nil
!                        (if isearch-regexp
! 			   (cons 'regexp-search-ring
! 				 (1+ (or regexp-search-ring-yank-pointer -1)))
! 			 (cons 'search-ring
! 			       (1+ (or search-ring-yank-pointer -1))))
                         nil t)
  		      isearch-new-message
  		      (mapconcat 'isearch-text-char-description
***************
*** 1116,1121 ****
--- 1101,1116 ----
       (isearch-abort)  ;; outside of let to restore outside global values
       )))
  
+ (defun isearch-edit-string-set-word ()
+   "Do word search after exiting `isearch-edit-string'.
+ If the mark is not active in the search string editing minibuffer,
+ then after exiting `isearch-edit-string', do word search.
+ Otherwise, kill text between point and mark in the minibuffer."
+   (interactive)
+   (if mark-active
+       (kill-region (point) (mark))
+     (setq isearch-word t isearch-new-word t)))
+ 
  (defun isearch-nonincremental-exit-minibuffer ()
    (interactive)
    (setq isearch-nonincremental t)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Stefan Monnier]

> Below is a patch that fixes all these problems.  It uses
> search-ring-yank-pointer and regexp-search-ring-yank-pointer
> for the HISTPOS argument of read-from-minibuffer that gives
> the correct initial minibuffer search history position for
> isearch-edit-string.

Thanks.

> It also gets rid of all trickery used to read the first character
> typed in the minibuffer (that removes another set of problems;
> see related old bug reports).  It adds a new backward-compatible
> command `isearch-edit-string-set-word' bound to C-w in the minibuffer
> that calls `kill-region' when the mark is active, and otherwise does
> word search after exiting `isearch-edit-string' (the mark is not active
> when `isearch-edit-string' just created the minibuffer, and without
> the mark `kill-region' would fail anyway).

> This preserves the behavior described in the Emacs manual:

> `C-s <RET> C-w WORDS <RET>'
>      Search for WORDS, ignoring details of punctuation.

This seems unrelated, right?
It looks like a good change.  But I wonder why we don't use an approach
similar to the M-r binding to isearch-toggle-regexp.  Of course, we'd
rather not eat yet-another key (e.g. bind M-w to isearch-toggle-word),
but maybe we could change isearch-toggle-regexp into
isearch-cycle-regexp-word, such that the command cycles between
plain/regexp/word searches.


        Stefan


> Index: lisp/isearch.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/isearch.el,v
> retrieving revision 1.313
> diff -c -r1.313 isearch.el
> *** lisp/isearch.el	28 Feb 2008 01:57:42 -0000	1.313
> --- lisp/isearch.el	9 Mar 2008 21:57:02 -0000
> ***************
> *** 436,441 ****
> --- 436,442 ----
>       (define-key map "\M-\t" 'isearch-complete-edit)
>       (define-key map "\C-s"  'isearch-forward-exit-minibuffer)
>       (define-key map "\C-r"  'isearch-reverse-exit-minibuffer)
> +     (define-key map "\C-w"  'isearch-edit-string-set-word)
>       (define-key map "\C-f"  'isearch-yank-char-in-minibuffer)
>       (define-key map [right] 'isearch-yank-char-in-minibuffer)
>       map)
> ***************
> *** 1025,1061 ****
>   	  ;; that can change their values.
>   	  (setq old-point (point) old-other-end isearch-other-end)
  
> - 	  (isearch-message) ;; for read-char
>   	  (unwind-protect
> ! 	      (let* (;; Why does following read-char echo?
> ! 		     ;;(echo-keystrokes 0) ;; not needed with above message
> ! 		     (e (let ((cursor-in-echo-area t))
> ! 			  (read-event)))
>   		     ;; Binding minibuffer-history-symbol to nil is a work-around
>   		     ;; for some incompatibility with gmhist.
> ! 		     (minibuffer-history-symbol)
> ! 		     (message-log-max nil))
> ! 		;; If the first character the user types when we prompt them
> ! 		;; for a string is the yank-word character, then go into
> ! 		;; word-search mode.  Otherwise unread that character and
> ! 		;; read a key the normal way.
> ! 		;; Word search does not apply (yet) to regexp searches,
> ! 		;; no check is made here.
> ! 		(message "%s" (isearch-message-prefix nil nil t))
> ! 		(if (memq (lookup-key isearch-mode-map (vector e))
> ! 			  '(isearch-yank-word
> ! 			    isearch-yank-word-or-char))
> ! 		    (setq isearch-word t;; so message-prefix is right
> ! 			  isearch-new-word t)
> ! 		  (cancel-kbd-macro-events)
> ! 		  (isearch-unread e))
> ! 		(setq cursor-in-echo-area nil)
>   		(setq isearch-new-string
>                         (read-from-minibuffer
>                          (isearch-message-prefix nil nil isearch-nonincremental)
>                          isearch-string
>                          minibuffer-local-isearch-map nil
> !                        (if isearch-regexp 'regexp-search-ring 'search-ring)
>                          nil t)
>   		      isearch-new-message
>   		      (mapconcat 'isearch-text-char-description
> --- 1026,1046 ----
>   	  ;; that can change their values.
>   	  (setq old-point (point) old-other-end isearch-other-end)
  
>   	  (unwind-protect
> ! 	      (let* ((message-log-max nil)
>   		     ;; Binding minibuffer-history-symbol to nil is a work-around
>   		     ;; for some incompatibility with gmhist.
> ! 		     (minibuffer-history-symbol))
>   		(setq isearch-new-string
>                         (read-from-minibuffer
>                          (isearch-message-prefix nil nil isearch-nonincremental)
>                          isearch-string
>                          minibuffer-local-isearch-map nil
> !                        (if isearch-regexp
> ! 			   (cons 'regexp-search-ring
> ! 				 (1+ (or regexp-search-ring-yank-pointer -1)))
> ! 			 (cons 'search-ring
> ! 			       (1+ (or search-ring-yank-pointer -1))))
>                          nil t)
>   		      isearch-new-message
>   		      (mapconcat 'isearch-text-char-description
> ***************
> *** 1116,1121 ****
> --- 1101,1116 ----
>        (isearch-abort)  ;; outside of let to restore outside global values
>        )))
  
> + (defun isearch-edit-string-set-word ()
> +   "Do word search after exiting `isearch-edit-string'.
> + If the mark is not active in the search string editing minibuffer,
> + then after exiting `isearch-edit-string', do word search.
> + Otherwise, kill text between point and mark in the minibuffer."
> +   (interactive)
> +   (if mark-active
> +       (kill-region (point) (mark))
> +     (setq isearch-word t isearch-new-word t)))
> + 
>   (defun isearch-nonincremental-exit-minibuffer ()
>     (interactive)
>     (setq isearch-nonincremental t)

> -- 
> Juri Linkov
> http://www.jurta.org/emacs/

Word search (was: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?)

[Juri Linkov]

>> It also gets rid of all trickery used to read the first character
>> typed in the minibuffer (that removes another set of problems;
>> see related old bug reports).  It adds a new backward-compatible
>> command `isearch-edit-string-set-word' bound to C-w in the minibuffer
>> that calls `kill-region' when the mark is active, and otherwise does
>> word search after exiting `isearch-edit-string' (the mark is not active
>> when `isearch-edit-string' just created the minibuffer, and without
>> the mark `kill-region' would fail anyway).
>
>> This preserves the behavior described in the Emacs manual:
>
>> `C-s <RET> C-w WORDS <RET>'
>>      Search for WORDS, ignoring details of punctuation.
>
> This seems unrelated, right?

This is slightly related, but now I see it can be installed with
a separate patch.

> It looks like a good change.  But I wonder why we don't use an approach
> similar to the M-r binding to isearch-toggle-regexp.

Keeping C-w to specify word search in the minibuffer is necessary
for backward compatibility.  When we find a better method to toggle
word search, we could remove the description of the old method
from the manual, and remove its code in later releases.

> Of course, we'd rather not eat yet-another key (e.g. bind M-w to
> isearch-toggle-word), but maybe we could change isearch-toggle-regexp
> into isearch-cycle-regexp-word, such that the command cycles between
> plain/regexp/word searches.

One disadvantage of M-r is that it's not mnemonic to toggle word search.
OTOH, it is convenient to cycle between search types.

We could also add another keybinding to separately toggle only
word search `M-s w' and regexp search `M-s r'.  Their key sequences are
longer than `M-r' but they will allow specifying the exact search type.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Word search

[Stefan Monnier]

>>> It also gets rid of all trickery used to read the first character
>>> typed in the minibuffer (that removes another set of problems;
>>> see related old bug reports).  It adds a new backward-compatible
>>> command `isearch-edit-string-set-word' bound to C-w in the minibuffer
>>> that calls `kill-region' when the mark is active, and otherwise does
>>> word search after exiting `isearch-edit-string' (the mark is not active
>>> when `isearch-edit-string' just created the minibuffer, and without
>>> the mark `kill-region' would fail anyway).
>> 
>>> This preserves the behavior described in the Emacs manual:
>> 
>>> `C-s <RET> C-w WORDS <RET>'
>>> Search for WORDS, ignoring details of punctuation.
>> 
>> This seems unrelated, right?

> This is slightly related, but now I see it can be installed with
> a separate patch.

>> It looks like a good change.  But I wonder why we don't use an approach
>> similar to the M-r binding to isearch-toggle-regexp.

> Keeping C-w to specify word search in the minibuffer is necessary
> for backward compatibility.  When we find a better method to toggle
> word search, we could remove the description of the old method
> from the manual, and remove its code in later releases.

Backward compatibility with old elisp packages is important.
Backward compatibility with old Emacs users is a bit less important.

>> Of course, we'd rather not eat yet-another key (e.g. bind M-w to
>> isearch-toggle-word), but maybe we could change isearch-toggle-regexp
>> into isearch-cycle-regexp-word, such that the command cycles between
>> plain/regexp/word searches.

> One disadvantage of M-r is that it's not mnemonic to toggle word search.
> OTOH, it is convenient to cycle between search types.

> We could also add another keybinding to separately toggle only
> word search `M-s w' and regexp search `M-s r'.  Their key sequences are
> longer than `M-r' but they will allow specifying the exact search type.

Using M-s as a prefix might be a good idea.  What do others think?


        Stefan

Re: Word search

[Juri Linkov]

>> Keeping C-w to specify word search in the minibuffer is necessary
>> for backward compatibility.  When we find a better method to toggle
>> word search, we could remove the description of the old method
>> from the manual, and remove its code in later releases.
>
> Backward compatibility with old elisp packages is important.
> Backward compatibility with old Emacs users is a bit less important.

Then we could use C-w for something more useful like getting the next
word from the buffer and appending it to the search string in the
minibuffer.  This would be very convenient since this is exactly what
C-w does in isearch mode.

This will allow us finally to get rid of isearch-yank-char-in-minibuffer
which does almost the same but in an unpredictable way.

I also noticed a similar command `bookmark-yank-word' in bookmark.el.
But when the mark is active, it doesn't kill the region.  I think
it should check for the active mark, and call `kill-region' in this
case like:

(defun bookmark-yank-word ()
  (interactive)
  ;; get the next word from the buffer and append it to the name of
  ;; the bookmark currently being set.
  (if mark-active
      (kill-region (point) (mark))
    (let ((string (save-excursion
		    (set-buffer bookmark-current-buffer)
		    (goto-char bookmark-yank-point)
		    (buffer-substring-no-properties
		     (point)
		     (progn
		       (forward-word 1)
		       (setq bookmark-yank-point (point)))))))
      (insert string))))

Generally, the logic could be the following: when C-w will fail anyway
due to the absence of the active mark in the minibuffer, do a different
action like pulling the next word from the buffer to the minibuffer.

BTW, in bookmark.el I see:

    ;; This C-u binding might not be very useful any more now that we
    ;; provide access to the default via the standard M-n binding.
    ;; Maybe we should just remove it?  --Stef-08
    (define-key map "\C-u" 'bookmark-insert-current-bookmark)

I agree that this is unnecessary any more, and if no one will object,
maybe we could just remove it?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Word search

[Stefan Monnier]

> BTW, in bookmark.el I see:

>     ;; This C-u binding might not be very useful any more now that we
>     ;; provide access to the default via the standard M-n binding.
>     ;; Maybe we should just remove it?  --Stef-08
>     (define-key map "\C-u" 'bookmark-insert-current-bookmark)

> I agree that this is unnecessary any more, and if no one will object,
> maybe we could just remove it?

Actually, I decided to leave it in, hence the comment.
The reason why I decided to leave it in, is that some users may like to
type something and then hit C-u which will *add* the default, whereas
M-n will repalce what they typed with the default.
Maybe I'm being overly cautious here and we can just throw away this
binding, but I don't know enough how other people may use bookmarks to
feel confident about it.


        Stefan


PS: Oh and for your C-w, I personally think we should have a generic C-w
binding in minibuffer-local-map.

Re: Word search

[Juri Linkov]

> PS: Oh and for your C-w, I personally think we should have a generic
> C-w binding in minibuffer-local-map.

The following patch implements this:

Index: lisp/bindings.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.198
diff -c -r1.198 bindings.el
*** lisp/bindings.el	5 Mar 2008 04:09:24 -0000	1.198
--- lisp/bindings.el	12 Mar 2008 00:32:07 -0000
***************
*** 773,779 ****
    ;; indent-for-tab-command).  The alignment that indent-relative tries to
    ;; do doesn't make much sense here since the prompt messes it up.
    (define-key map "\t"    'self-insert-command)
!   (define-key minibuffer-local-map [C-tab] 'file-cache-minibuffer-complete))
  
  (define-key global-map "\C-u" 'universal-argument)
  (let ((i ?0))
--- 773,780 ----
    ;; indent-for-tab-command).  The alignment that indent-relative tries to
    ;; do doesn't make much sense here since the prompt messes it up.
    (define-key map "\t"    'self-insert-command)
!   (define-key map [C-tab] 'file-cache-minibuffer-complete)
!   (define-key map "\C-w"  'minibuffer-yank-word-or-char))
  
  (define-key global-map "\C-u" 'universal-argument)
  (let ((i ?0))

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.904
diff -c -r1.904 simple.el
*** lisp/simple.el	3 Mar 2008 02:16:00 -0000	1.904
--- lisp/simple.el	12 Mar 2008 00:32:31 -0000
***************
*** 1393,1398 ****
--- 1407,1435 ----
    ;; Return the width of everything before the field at the end of
    ;; the buffer; this should be 0 for normal buffers.
    (1- (minibuffer-prompt-end)))
+ 
+ (defun minibuffer-yank-word-or-char ()
+   "Pull next character or word from buffer into the minibuffer.
+ 
+ If the mark is active in the minibuffer, then kill text between point
+ and mark in the minibuffer using `kill-region'.
+ 
+ Otherwise, get the next word or character from the original buffer
+ and append it to the minibuffer."
+   (interactive)
+   (if mark-active
+       (kill-region (point) (mark))
+     (insert
+      (with-current-buffer (other-buffer (current-buffer) t)
+        (buffer-substring-no-properties
+         (point)
+         (progn
+           (if (or (= (char-syntax (or (char-after) 0)) ?w)
+                   (= (char-syntax (or (char-after (1+ (point))) 0)) ?w))
+               (forward-word 1)
+             (forward-char 1))
+           (point)))))))
+ 
  \f
  ;; isearch minibuffer history
  (add-hook 'minibuffer-setup-hook 'minibuffer-history-isearch-setup)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Word search

[Stefan Monnier]

> +      (with-current-buffer (other-buffer (current-buffer) t)

Are you sure this gives the right buffer in all cases?
Have you tried it after ? displayed the completions, for example?


        Stefan

Re: Word search

[Juri Linkov]

>> +      (with-current-buffer (other-buffer (current-buffer) t)
>
> Are you sure this gives the right buffer in all cases?
> Have you tried it after ? displayed the completions, for example?

Yes, it works after ? displayed the completions, i.e. it still yanks chars
from the original buffer, not from the completions buffer.

But I agree that this is not a reliable method.  Maybe we should record
the original buffer in a special variable before activating the minibuffer?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Word search

[Stefan Monnier]

>>> +      (with-current-buffer (other-buffer (current-buffer) t)
>> 
>> Are you sure this gives the right buffer in all cases?
>> Have you tried it after ? displayed the completions, for example?

> Yes, it works after ? displayed the completions, i.e. it still yanks chars
> from the original buffer, not from the completions buffer.

> But I agree that this is not a reliable method.  Maybe we should record
> the original buffer in a special variable before activating the minibuffer?

What about using `minibuffer-selected-window'?


        Stefan

Re: Word search

[Richard Stallman]

    > PS: Oh and for your C-w, I personally think we should have a generic
    > C-w binding in minibuffer-local-map.

It is a really bad idea to start making editing commands work
differently in the minibuffer.

Re: Word search

[Richard Stallman]

If we are thinking of eliminating the C-w word-search feature,
we should poll the users about it.

Maybe lots of people use it.
Maybe hardly anyone uses it.

Re: Word search

[Juri Linkov]

> If we are thinking of eliminating the C-w word-search feature,
> we should poll the users about it.
>
> Maybe lots of people use it.
> Maybe hardly anyone uses it.

The current method of entering word search is very inconvenient.
So even if lots of people use it and we will find a better method,
they might be even grateful for this.

But I doubt that many people use it because for many years of existence
of word search, very few people tried to find a way to enable incremental
word search (according to mailing list archives) until recently.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Word search

[Richard Stallman]

    But I doubt that many people use it because for many years of existence
    of word search, very few people tried to find a way to enable incremental
    word search (according to mailing list archives) until recently.

Maybe you're right.  But let's ask them.

Re: Word search

[Juri Linkov]

>     But I doubt that many people use it because for many years of existence
>     of word search, very few people tried to find a way to enable incremental
>     word search (according to mailing list archives) until recently.
>
> Maybe you're right.  But let's ask them.

I don't understand what does asking them mean?  Creating a webpage
with a poll?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Word search

[Richard Stallman]

    I don't understand what does asking them mean?  Creating a webpage
    with a poll?

I used to poll the users by sending mail to info-gnu-emacs and
help-gnu-emacs.  Putting the poll in a web page also might be good.

It's up to the maintainers to decide if they want to poll the users.

Re: Word search

[René Kyllingstad]

* Richard Stallman:
>      But I doubt that many people use it because for many years of
>      existence of word search, very few people tried to find a way to
>      enable incremental word search (according to mailing list archives)
>      until recently.
>  
>  Maybe you're right.  But let's ask them.

I never realized it was there.  I remember trying C-y hoping for that, but
it inserts to the end of the line, something I never need.

I would prefer to have bindings similar to normal editing: C-y to yank, but
use M-y to insert the word at point, unless the previous command was yank.
Makes it easier to remember.


-- René

Re: Word search

[Juri Linkov]

>>      But I doubt that many people use it because for many years of
>>      existence of word search, very few people tried to find a way to
>>      enable incremental word search (according to mailing list archives)
>>      until recently.
>>
>>  Maybe you're right.  But let's ask them.
>
> I never realized it was there.  I remember trying C-y hoping for that, but
> it inserts to the end of the line, something I never need.
>
> I would prefer to have bindings similar to normal editing: C-y to yank, but
> use M-y to insert the word at point, unless the previous command was yank.
> Makes it easier to remember.

We currently have:

C-w isearch-yank-word-or-char
C-y isearch-yank-line
M-y isearch-yank-kill

Do you propose this change:

C-w isearch-yank-word-or-char
M-y isearch-yank-word-or-char
C-y isearch-yank-kill

But where do you put `isearch-yank-line'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Word search

[Drew Adams]

1. It might be OK to have C-w do something different when the region is
empty. At least for those people who use transient-mark mode (so that
"active region" means something).

2. That is not limited to the minibuffer, logically. That is, there is
nothing special about the minibuffer in this regard.

3. It is OK to have some minibuffer key yank text from the current buffer -
for example, text at or near point.

4. We have discussed #3 before. I suggested behavior that lets you yank
different kinds of things at point and behavior that lets you yank
successive things at point. Nothing has come of that, so far.

5. HOWEVER: If an approach such as #1 is used, it should not be combined
with #3, and especially not using `C-w'. That is trying to be too clever by
half, and it doesn't help.

That is, there is no reason to combine these features you propose. And doing
so limits design for the future. And the use of C-w then becomes confusing
for users: sometimes cut (kill), sometimes paste (yank). That's not good UI,
IMO.

So if you do #3, please use a different key. And if you do #1, consider
doing so in every buffer, not just the minibuffer.

Re: Word search

[Richard Stallman]

    1. It might be OK to have C-w do something different when the region is
    empty. At least for those people who use transient-mark mode (so that
    "active region" means something).

This is the sort of thing we should poll the users about.

Re: Word search

[Juri Linkov]

> 1. It might be OK to have C-w do something different when the region is
> empty. At least for those people who use transient-mark mode (so that
> "active region" means something).
>
> 2. That is not limited to the minibuffer, logically. That is, there is
> nothing special about the minibuffer in this regard.
>
> 3. It is OK to have some minibuffer key yank text from the current buffer -
> for example, text at or near point.
>
> 4. We have discussed #3 before. I suggested behavior that lets you yank
> different kinds of things at point and behavior that lets you yank
> successive things at point. Nothing has come of that, so far.
>
> 5. HOWEVER: If an approach such as #1 is used, it should not be combined
> with #3, and especially not using `C-w'. That is trying to be too clever by
> half, and it doesn't help.
>
> That is, there is no reason to combine these features you propose. And doing
> so limits design for the future. And the use of C-w then becomes confusing
> for users: sometimes cut (kill), sometimes paste (yank). That's not good UI,
> IMO.
>
> So if you do #3, please use a different key. And if you do #1, consider
> doing so in every buffer, not just the minibuffer.

C-w in the search string editing minibuffer is a natural extension of
C-w in isearch mode (`isearch-yank-word-or-char') because there will be
no difference between `C-s C-w C-w ...' and `C-s M-e C-w C-w ...'.

Since `isearch-edit-string' uses a normal minibuffer, it would be
natural to extend this C-w feature to other minibuffers.

But it is true that such dual nature of C-w might cause troubles
when transient-mark-mode is off.

Maybe, we could accept C-w as a yanking key only at the beginning of
the minibuffer?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Word search

[Richard Stallman]

    C-w in the search string editing minibuffer is a natural extension of
    C-w in isearch mode (`isearch-yank-word-or-char') because there will be
    no difference between `C-s C-w C-w ...' and `C-s M-e C-w C-w ...'.

    Since `isearch-edit-string' uses a normal minibuffer, it would be
    natural to extend this C-w feature to other minibuffers.

This seems like a hair on the tail wagging the dog.