* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
@ 2013-01-17 20:39 Dani Moncayo
2013-01-17 21:27 ` Juri Linkov
2013-08-03 17:09 ` Dani Moncayo
0 siblings, 2 replies; 23+ messages in thread
From: Dani Moncayo @ 2013-01-17 20:39 UTC (permalink / raw)
To: 13480
Hello,
I have `isearch-lax-whitespace' set to t in my init file, so that I
can search for a sequence of words regardless of whether there is line
breaks or plain spaces between them.
Now, if the text following point is "foo bar" and I do `C-s C-w C-w'
I'll be searching for any sequence of those two words, separated by
any whitespace (well, controlled by `search-whitespace-regexp'). Ok,
as expected.
But I've just noticed that if the text following point is
"foo<newline>bar" and I do the same, I'll be searching exactly for
that fixed sequence of 7 characters, including the <newline>. Not
what I want, obviously.
So I propose that the command `isearch-yank-word-or-char' (C-w in
Isearch) DTRT in this case, i.e., when `search-whitespace-regexp' is
non-nil, translate the <newline> into a simple space when pulling text
from the buffer into the search string.
TIA.
In GNU Emacs 24.3.50.1 (i386-mingw-nt6.2.9200)
of 2013-01-10 on MS-W8-DANI
Bzr revision: 111476 jan.h.d@swipnet.se-20130110174508-0pdaxa5ys9me698g
Windowing system distributor `Microsoft Corp.', version 6.2.9200
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
-Ic:/emacs/libs/libpng-dev_1.4.3-1_win32/include
-Ic:/emacs/libs/zlib-dev_1.2.5-2_win32/include
-Ic:/emacs/libs/giflib-4.1.4-1-lib/include
-Ic:/emacs/libs/jpeg-6b-4-lib/include
-Ic:/emacs/libs/tiff-3.8.2-1-lib/include
-Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
-Ic:/emacs/libs/gnutls-3.1.5-w32/include
-Ic:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-17 20:39 bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces Dani Moncayo
@ 2013-01-17 21:27 ` Juri Linkov
2013-01-17 23:10 ` Dani Moncayo
2013-08-03 17:09 ` Dani Moncayo
1 sibling, 1 reply; 23+ messages in thread
From: Juri Linkov @ 2013-01-17 21:27 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 13480
> So I propose that the command `isearch-yank-word-or-char' (C-w in
> Isearch) DTRT in this case, i.e., when `search-whitespace-regexp' is
> non-nil, translate the <newline> into a simple space when pulling text
> from the buffer into the search string.
It makes sense to translate the <newline> into a simple space
only when `search-whitespace-regexp' contains <newline>
such as e.g. (setq search-whitespace-regexp "\\(\\s-\\|\n\\)+")
Otherwise, the translated space won't match <newline>.
It is possible to do this with the patch below.
But then you might also want to translate the <newline> into a space
in `isearch-yank-line' as well? And maybe also in `isearch-yank-kill'?
=== modified file 'lisp/isearch.el'
--- lisp/isearch.el 2013-01-16 21:45:20 +0000
+++ lisp/isearch.el 2013-01-17 21:27:35 +0000
@@ -1837,7 +1837,14 @@ (defun isearch-yank-internal (jumpform)
(save-excursion
(and (not isearch-forward) isearch-other-end
(goto-char isearch-other-end))
- (buffer-substring-no-properties (point) (funcall jumpform)))))
+ (if (if isearch-regexp
+ isearch-regexp-lax-whitespace
+ isearch-lax-whitespace)
+ (replace-regexp-in-string
+ search-whitespace-regexp
+ " "
+ (buffer-substring-no-properties (point) (funcall jumpform)) nil t)
+ (buffer-substring-no-properties (point) (funcall jumpform))))))
(defun isearch-yank-char-in-minibuffer (&optional arg)
"Pull next character from buffer into end of search string in minibuffer."
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-17 21:27 ` Juri Linkov
@ 2013-01-17 23:10 ` Dani Moncayo
2013-01-17 23:54 ` Dani Moncayo
0 siblings, 1 reply; 23+ messages in thread
From: Dani Moncayo @ 2013-01-17 23:10 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480
>> So I propose that the command `isearch-yank-word-or-char' (C-w in
>> Isearch) DTRT in this case, i.e., when `search-whitespace-regexp' is
>> non-nil, translate the <newline> into a simple space when pulling text
>> from the buffer into the search string.
>
> It makes sense to translate the <newline> into a simple space
> only when `search-whitespace-regexp' contains <newline>
> such as e.g. (setq search-whitespace-regexp "\\(\\s-\\|\n\\)+")
> Otherwise, the translated space won't match <newline>.
> It is possible to do this with the patch below.
Indeed. Any character that matches the current value of
`search-whitespace-regexp' should be translated to a single space.
> But then you might also want to translate the <newline> into a space
> in `isearch-yank-line' as well? And maybe also in `isearch-yank-kill'?
I think so. And also `isearch-yank-char' and `isearch-yank-pop'. In
general, any command that pulls text from somewhere into the search string.
IMO that's what makes sense when `isearch-lax-whitespace' is non-nil.
And BTW, I think that an analogous change should be done to regexp Isearch,
i.e., perform that translations during regexp Isearch when
`isearch-regexp-lax-whitespace' is non-nil.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-17 23:10 ` Dani Moncayo
@ 2013-01-17 23:54 ` Dani Moncayo
2013-01-18 21:59 ` Juri Linkov
0 siblings, 1 reply; 23+ messages in thread
From: Dani Moncayo @ 2013-01-17 23:54 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480
>>> So I propose that the command `isearch-yank-word-or-char' (C-w in
>>> Isearch) DTRT in this case, i.e., when `search-whitespace-regexp' is
>>> non-nil, translate the <newline> into a simple space when pulling text
>>> from the buffer into the search string.
>>
>> It makes sense to translate the <newline> into a simple space
>> only when `search-whitespace-regexp' contains <newline>
>> such as e.g. (setq search-whitespace-regexp "\\(\\s-\\|\n\\)+")
>> Otherwise, the translated space won't match <newline>.
>> It is possible to do this with the patch below.
>
> Indeed. Any character that matches the current value of
> `search-whitespace-regexp' should be translated to a single space.
Wait a moment. On second thought, I think that no translation should
be necessary at all when adding text from somewhere to the search string.
As I see it, the problem (bug) is that when `isearch-lax-whitespace'
is non-nil, a search string like "foo<X>bar" should match every
string like "foo<Y>bar" in the buffer, where X and Y are arbitrary
strings that match `search-whitespace-regexp'.
But the current behavior is different: only plain spaces in the search
string are matched against `search-whitespace-regexp', i.e., "<X>" is
fixed to a plain space.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-17 23:54 ` Dani Moncayo
@ 2013-01-18 21:59 ` Juri Linkov
2013-01-19 8:05 ` Dani Moncayo
0 siblings, 1 reply; 23+ messages in thread
From: Juri Linkov @ 2013-01-18 21:59 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 13480
> Wait a moment. On second thought, I think that no translation should
> be necessary at all when adding text from somewhere to the search string.
Why not? If you save "foo<newline>bar" to the kill-ring and
yank it to the search string with `C-y' (`isearch-yank-kill')
wouldn't you want it to translate the <newline> into a space?
Anyway if you want to try this possibility (maybe it should be optional?),
here is the patch:
=== modified file 'lisp/isearch.el'
--- lisp/isearch.el 2013-01-18 21:36:55 +0000
+++ lisp/isearch.el 2013-01-18 21:57:06 +0000
@@ -1780,6 +1780,13 @@ (defun isearch-yank-string (string)
(if (and isearch-case-fold-search
(eq 'not-yanks search-upper-case))
(setq string (downcase string)))
+ (if (if isearch-regexp
+ isearch-regexp-lax-whitespace
+ isearch-lax-whitespace)
+ (setq string (replace-regexp-in-string
+ search-whitespace-regexp
+ " "
+ string nil t)))
(if isearch-regexp (setq string (regexp-quote string)))
;; Don't move cursor in reverse search.
(setq isearch-yank-flag t)
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-18 21:59 ` Juri Linkov
@ 2013-01-19 8:05 ` Dani Moncayo
2013-01-19 9:56 ` Dani Moncayo
2013-01-19 9:59 ` Juri Linkov
0 siblings, 2 replies; 23+ messages in thread
From: Dani Moncayo @ 2013-01-19 8:05 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480
On Fri, Jan 18, 2013 at 10:59 PM, Juri Linkov <juri@jurta.org> wrote:
>> Wait a moment. On second thought, I think that no translation should
>> be necessary at all when adding text from somewhere to the search string.
>
> Why not? If you save "foo<newline>bar" to the kill-ring and
> yank it to the search string with `C-y' (`isearch-yank-kill')
> wouldn't you want it to translate the <newline> into a space?
No, I wouldn't. I don't like that translation for two reasons:
1. It loses information that may be useful. In the future we could
want to implement a feature whereby the user can toggle the
lax-whitespace-matching behavior during an Isearch session. In fact I
think it would be a good feature (and ISTR that Drew proposed some
time ago). That feature would not be possible if we change the text
that the user supplies to search for.
2. It is less surprising and more clean to me to see in the echo area
exactly the text I'm supplying, without translations of any kind.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 8:05 ` Dani Moncayo
@ 2013-01-19 9:56 ` Dani Moncayo
2013-01-19 10:07 ` Juri Linkov
2013-01-19 15:01 ` Drew Adams
2013-01-19 9:59 ` Juri Linkov
1 sibling, 2 replies; 23+ messages in thread
From: Dani Moncayo @ 2013-01-19 9:56 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480
> 2. It is less surprising and more clean to me to see in the echo area
> exactly the text I'm supplying, without translations of any kind.
Well, OTOH it makes a lot of sense to think of the text displayed in
the echo area (during Isearch) not necessarily as the raw search
string, but as its "canonical form", according to the current matching
behavior (which the user should be able to alter on-the-fly).
Definitely that would be a nice behavior, and not only for the laxity
in whitespace matching, but also in other ones discussed recently like
those related to accented.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 8:05 ` Dani Moncayo
2013-01-19 9:56 ` Dani Moncayo
@ 2013-01-19 9:59 ` Juri Linkov
1 sibling, 0 replies; 23+ messages in thread
From: Juri Linkov @ 2013-01-19 9:59 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 13480
> 1. It loses information that may be useful. In the future we could
> want to implement a feature whereby the user can toggle the
> lax-whitespace-matching behavior during an Isearch session. In fact I
> think it would be a good feature (and ISTR that Drew proposed some
> time ago).
We already have this feature with `M-SPC'.
> That feature would not be possible if we change the text
> that the user supplies to search for.
Yes, there is no way to restore the original text in the search string
and to un-translate a space back to the newline.
> 2. It is less surprising and more clean to me to see in the echo area
> exactly the text I'm supplying, without translations of any kind.
Then this is possible to not translate newlines to a space
in the search string but process it internally with this code:
(defun search-whitespace-regexp (string)
"Return a regexp which ignores whitespace.
Uses the value of the variable `search-whitespace-regexp'."
(if (or (not (stringp search-whitespace-regexp))
(null (if isearch-regexp
isearch-regexp-lax-whitespace
isearch-lax-whitespace)))
string
;; FIXME: this is not strictly correct implementation because it ignores
;; `subregexp-context-p' and replaces spaces inside char set group like
;; in `C-M-s M-s SPC [ ]', it converts it to ["\\(\\s-\\|\n\\)+"] !
(replace-regexp-in-string
search-whitespace-regexp ;; " "
search-whitespace-regexp
string nil t)))
(defun search-forward-lax-whitespace (string &optional bound noerror count)
(re-search-forward (search-whitespace-regexp (regexp-quote string)) bound noerror count))
(defun search-backward-lax-whitespace (string &optional bound noerror count)
(re-search-backward (search-whitespace-regexp (regexp-quote string)) bound noerror count))
(defun re-search-forward-lax-whitespace (regexp &optional bound noerror count)
(re-search-forward (search-whitespace-regexp regexp) bound noerror count))
(defun re-search-backward-lax-whitespace (regexp &optional bound noerror count)
(re-search-backward (search-whitespace-regexp regexp) bound noerror count))
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 9:56 ` Dani Moncayo
@ 2013-01-19 10:07 ` Juri Linkov
2013-01-19 10:40 ` Dani Moncayo
2013-01-19 15:01 ` Drew Adams
1 sibling, 1 reply; 23+ messages in thread
From: Juri Linkov @ 2013-01-19 10:07 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 13480
> Well, OTOH it makes a lot of sense to think of the text displayed in
> the echo area (during Isearch) not necessarily as the raw search
> string, but as its "canonical form", according to the current matching
> behavior (which the user should be able to alter on-the-fly).
>
> Definitely that would be a nice behavior, and not only for the laxity
> in whitespace matching, but also in other ones discussed recently like
> those related to accented letters.
`isearch-yank-string' already downcases the yanked upper case string
to lower case, so it's possible to do the same with lax spaces and
accented letters.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 10:07 ` Juri Linkov
@ 2013-01-19 10:40 ` Dani Moncayo
2013-01-19 10:57 ` Juri Linkov
0 siblings, 1 reply; 23+ messages in thread
From: Dani Moncayo @ 2013-01-19 10:40 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480
>> Well, OTOH it makes a lot of sense to think of the text displayed in
>> the echo area (during Isearch) not necessarily as the raw search
>> string, but as its "canonical form", according to the current matching
>> behavior (which the user should be able to alter on-the-fly).
>>
>> Definitely that would be a nice behavior, and not only for the laxity
>> in whitespace matching, but also in other ones discussed recently like
>> those related to accented letters.
>
> `isearch-yank-string' already downcases the yanked upper case string
> to lower case, so it's possible to do the same with lax spaces and
> accented letters.
Yes, but I see that currently the conversion to lowercase is
destructive, i.e., the original text supplied by the user is lost.
For example, if I have "Hello" in the kill ring and do `C-s C-y M-s
c', obviously I'd like to be searching for "Hello" case-sensitively,
but currently I end up searching (case-sensitively) for "hello".
That's wrong, IMO.
I propose to:
1. Store in one variable the "raw" (untouched) search string, as
supplied by the user.
2. Store in another variable (or define a function to get) the
"canonical" search string, based on the raw search string and the
"laxities" enabled at that moment for the search algorithm (related to
whitespace, case-sensitivity, accents, etc).
3. Display the canonical search string in the echo area and use it
also in the search algorithm.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 10:40 ` Dani Moncayo
@ 2013-01-19 10:57 ` Juri Linkov
2013-01-19 12:11 ` Dani Moncayo
2013-01-19 15:43 ` Drew Adams
0 siblings, 2 replies; 23+ messages in thread
From: Juri Linkov @ 2013-01-19 10:57 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 13480
> 1. Store in one variable the "raw" (untouched) search string, as
> supplied by the user.
Such variable that holds the raw search string already exists.
It is `isearch-string'.
> 2. Store in another variable (or define a function to get) the
> "canonical" search string, based on the raw search string and the
> "laxities" enabled at that moment for the search algorithm (related to
> whitespace, case-sensitivity, accents, etc).
> 3. Display the canonical search string in the echo area and use it
> also in the search algorithm.
Such variable used to display the search string in the echo area already exists.
It is `isearch-message'.
So we could use `isearch-message' to display the translated search string
but not to translate it in `isearch-string'.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 10:57 ` Juri Linkov
@ 2013-01-19 12:11 ` Dani Moncayo
2013-01-19 15:45 ` Drew Adams
2013-01-19 15:43 ` Drew Adams
1 sibling, 1 reply; 23+ messages in thread
From: Dani Moncayo @ 2013-01-19 12:11 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480
>> 1. Store in one variable the "raw" (untouched) search string, as
>> supplied by the user.
>
> Such variable that holds the raw search string already exists.
> It is `isearch-string'.
Currently that's not true. For example, after invoking
`isearch-yank-string', `isearch-string' ends up holding the translated
version of the raw search string, which is not available anymore.
>> 2. Store in another variable (or define a function to get) the
>> "canonical" search string, based on the raw search string and the
>> "laxities" enabled at that moment for the search algorithm (related to
>> whitespace, case-sensitivity, accents, etc).
>> 3. Display the canonical search string in the echo area and use it
>> also in the search algorithm.
>
> Such variable used to display the search string in the echo area already exists.
> It is `isearch-message'.
>
> So we could use `isearch-message' to display the translated search string
> but not to translate it in `isearch-string'.
Not sure what you mean. If you are going to use `isearch-string' to
store the raw search string, obviously that variable should not be
overwritten with the translated version.
So you need another variable for the translated version, but I don't
think `isearch-message' is a good name, because the intent is not
(only) to be a mere message for the user, but to serve as input for
the search algorithm. Therefore I'd look for a name which better
reflects that intent. For example `isearch-string-canonical' or
`isearch-string-normalized' or something like that (see
http://en.wikipedia.org/wiki/Canonicalization for inspiration).
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 9:56 ` Dani Moncayo
2013-01-19 10:07 ` Juri Linkov
@ 2013-01-19 15:01 ` Drew Adams
1 sibling, 0 replies; 23+ messages in thread
From: Drew Adams @ 2013-01-19 15:01 UTC (permalink / raw)
To: 'Dani Moncayo', 'Juri Linkov'; +Cc: 13480
> > 2. It is less surprising and more clean to me to see in the
> > echo area exactly the text I'm supplying, without translations
> > of any kind.
>
> Well, OTOH it makes a lot of sense to think of the text displayed in
> the echo area (during Isearch) not necessarily as the raw search
> string, but as its "canonical form", according to the current matching
> behavior (which the user should be able to alter on-the-fly).
>
> Definitely that would be a nice behavior, and not only for the laxity
> in whitespace matching, but also in other ones discussed recently like
> those related to accented.
Yes, it would be good, if possible, for a user to be able to toggle between a
raw search string that Isearch uses under the covers and its effective or more
visually convenient representation.
This can be useful in regexp searching, of course. And it can be useful if a
user switches from plain search to regexp and wants to retrieve the underlying
regexp and tweak it.
We discussed this a couple of times, IIRC. In connection with letting `.' match
also newlines, letting SPC represent a more complex whitespace regexp, and maybe
in connection with accents etc. E.g., a regexp or other pattern that matches
any char including newlines or any whitespace or the chars in an equivalence
class ignoring diacritics.
Sorry, I don't have references to the discussions.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 10:57 ` Juri Linkov
2013-01-19 12:11 ` Dani Moncayo
@ 2013-01-19 15:43 ` Drew Adams
2013-01-19 17:20 ` Stefan Monnier
1 sibling, 1 reply; 23+ messages in thread
From: Drew Adams @ 2013-01-19 15:43 UTC (permalink / raw)
To: 'Juri Linkov', 'Dani Moncayo'; +Cc: 13480
> > 1. Store in one variable the "raw" (untouched) search string, as
> > supplied by the user.
>
> Such variable that holds the raw search string already exists.
> It is `isearch-string'.
>
> > 2. Store in another variable (or define a function to get) the
> > "canonical" search string, based on the raw search string and the
> > "laxities" enabled at that moment for the search algorithm
> (related to
> > whitespace, case-sensitivity, accents, etc).
> > 3. Display the canonical search string in the echo area and use it
> > also in the search algorithm.
>
> Such variable used to display the search string in the echo
> area already exists.
> It is `isearch-message'.
>
> So we could use `isearch-message' to display the translated
> search string but not to translate it in `isearch-string'.
Yes, +1. But not just display it. Be able to toggle it in place of
`isearch-string'. IOW, be able to retrieve it, and go back and forth.
It might also be useful to be able to just display it, as a check. (But a user
could just hit the toggle key twice for that.)
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 12:11 ` Dani Moncayo
@ 2013-01-19 15:45 ` Drew Adams
0 siblings, 0 replies; 23+ messages in thread
From: Drew Adams @ 2013-01-19 15:45 UTC (permalink / raw)
To: 'Dani Moncayo', 'Juri Linkov'; +Cc: 13480
> Not sure what you mean. If you are going to use `isearch-string' to
> store the raw search string, obviously that variable should not be
> overwritten with the translated version.
>
> So you need another variable for the translated version, but I don't
> think `isearch-message' is a good name, because the intent is not
> (only) to be a mere message for the user, but to serve as input for
> the search algorithm. Therefore I'd look for a name which better
> reflects that intent. For example `isearch-string-canonical' or
> `isearch-string-normalized' or something like that (see
> http://en.wikipedia.org/wiki/Canonicalization for inspiration).
Yes, you need to be able to go back and forth, and each is distiguishable from
the current search string variable, i.e., there are two "backups": raw and
pretty. Possibly we could get by with just one backup, but the behavior should
be that the user can retrieve the last search string of either kind at any
point.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 15:43 ` Drew Adams
@ 2013-01-19 17:20 ` Stefan Monnier
2013-01-19 23:30 ` Juri Linkov
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2013-01-19 17:20 UTC (permalink / raw)
To: Drew Adams; +Cc: 13480
>> So we could use `isearch-message' to display the translated
>> search string but not to translate it in `isearch-string'.
> Yes, +1.
IIRC there's the same problem with case-sensitivity.
Stefan
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 17:20 ` Stefan Monnier
@ 2013-01-19 23:30 ` Juri Linkov
2013-01-20 9:41 ` Dani Moncayo
2022-04-22 12:28 ` Lars Ingebrigtsen
0 siblings, 2 replies; 23+ messages in thread
From: Juri Linkov @ 2013-01-19 23:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13480
>>> So we could use `isearch-message' to display the translated
>>> search string but not to translate it in `isearch-string'.
>> Yes, +1.
>
> IIRC there's the same problem with case-sensitivity.
Not downcasing the yanked string could help to fix bug#10118.
According to the docstring of `search-upper-case',
if its value is `not-yanks', text yanked into the
search string is always downcased.
So maybe a better default value for `search-upper-case'
would be `nil' instead of the current default `not-yanks'.
If a tri-state option with three values t/nil/not-yanks
is a good customization UI then perhaps `isearch-lax-whitespace'
should provide the option `not-yanks' too, specifying whether
newlines should be translated to a single space in text yanked
into the search string.
If the value `not-yanks' is a bad UI then search functions should
take care about translating the characters in the search string internally
depending on a new set of options specifying how search functions should
use the right case and whitespace.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 23:30 ` Juri Linkov
@ 2013-01-20 9:41 ` Dani Moncayo
2013-01-20 12:27 ` Dani Moncayo
2022-04-22 12:28 ` Lars Ingebrigtsen
1 sibling, 1 reply; 23+ messages in thread
From: Dani Moncayo @ 2013-01-20 9:41 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480
>>>> So we could use `isearch-message' to display the translated
>>>> search string but not to translate it in `isearch-string'.
>>> Yes, +1.
>>
>> IIRC there's the same problem with case-sensitivity.
>
> Not downcasing the yanked string could help to fix bug#10118.
Of course, because altering the original text supplied by the user is
definitely a mistake.
> According to the docstring of `search-upper-case',
> if its value is `not-yanks', text yanked into the
> search string is always downcased.
>
> So maybe a better default value for `search-upper-case'
> would be `nil' instead of the current default `not-yanks'.
I've just read the docstring of that variable, and I think its design
is clearly misguided. The text in the search string that came from a
yank should not be treated differently from the rest. I see no point
in that approach.
I would control the behavior of Isearch wrt case-sensitivity with a
variable `isearch-case-sensitive' which the user could set to:
1. `auto' (the default): the search is case-sensitive only when the
search string contains at least one uppercase character.
2. `nil': the search is case-insensitive.
3. (any other value): the search is case-sensitive.
> If a tri-state option with three values t/nil/not-yanks
> is a good customization UI then perhaps `isearch-lax-whitespace'
> should provide the option `not-yanks' too, specifying whether
> newlines should be translated to a single space in text yanked
> into the search string.
>
> If the value `not-yanks' is a bad UI then search functions should
> take care about translating the characters in the search string internally
> depending on a new set of options specifying how search functions should
> use the right case and whitespace.
I don't think this is a question of good or bad UI, but of good or bad design.
In summary, I see two mistake here:
1. Losing information. Example: downcasing the text in `C-s C-y' or
`C-s C-w'. The text supplied by the user to search for should be kept
untouched. Not doing so is asking for trouble.
2. Not interpreting correctly the search string. Example: the
original post in this thread. If `isearch-lax-whitespace' is non-nil,
`C-s fooXbar' should find every string `fooYbar' in the buffer, where
X and Y are arbitrary strings that match `search-whitespace-regexp'.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-20 9:41 ` Dani Moncayo
@ 2013-01-20 12:27 ` Dani Moncayo
0 siblings, 0 replies; 23+ messages in thread
From: Dani Moncayo @ 2013-01-20 12:27 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480
>> So maybe a better default value for `search-upper-case'
>> would be `nil' instead of the current default `not-yanks'.
>
> I've just read the docstring of that variable, and I think its design
> is clearly misguided. The text in the search string that came from a
> yank should not be treated differently from the rest. I see no point
> in that approach.
Well, I see the point of making that distinction: If the user is
Isearching and _types_ an uppercase character, then it is quite
reasonable to assume that she wants the _current_ Isearch session to
be case-sensitive. But that assumption is not reasonable when the
user takes text from somewhere (kill ring or buffer) and adds it to
the search string.
But downcasing the text in the second case is clearly a wrong
approach, because we are losing information that can be necessary
during the Isearch session for doing the right thing.
Instead, store the text in the search string as supplied, without
altering it in any way, and do the search based on it and the current
search "conditions", which can vary during the Isearch session.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-17 20:39 bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces Dani Moncayo
2013-01-17 21:27 ` Juri Linkov
@ 2013-08-03 17:09 ` Dani Moncayo
1 sibling, 0 replies; 23+ messages in thread
From: Dani Moncayo @ 2013-08-03 17:09 UTC (permalink / raw)
To: 13480
On Thu, Jan 17, 2013 at 9:39 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> Hello,
>
> I have `isearch-lax-whitespace' set to t in my init file, so that I
> can search for a sequence of words regardless of whether there is line
> breaks or plain spaces between them.
>
> Now, if the text following point is "foo bar" and I do `C-s C-w C-w'
> I'll be searching for any sequence of those two words, separated by
> any whitespace (well, controlled by `search-whitespace-regexp'). Ok,
> as expected.
>
> But I've just noticed that if the text following point is
> "foo<newline>bar" and I do the same, I'll be searching exactly for
> that fixed sequence of 7 characters, including the <newline>. Not
> what I want, obviously.
There were quite a few post about this problem, but at the end, I
think that the right solution is this one:
When `isearch-lax-whitespace' is non-nil, a sequence of whitespace
chars in the search string (not only a space, as stated now) should
match a sequence of whitespace chars in the buffer.
Analogous reasoning for `isearch-regexp-lax-whitespace' (for regexp
incremental search).
(Remember: we must refrain from modifying the text to search for, as
supplied by the user, because the search conditions (lax whitespace
matching in this case) may vary during the Isearch session)
--
Dani Moncayo
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2013-01-19 23:30 ` Juri Linkov
2013-01-20 9:41 ` Dani Moncayo
@ 2022-04-22 12:28 ` Lars Ingebrigtsen
2022-04-24 15:46 ` Juri Linkov
1 sibling, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-22 12:28 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480, Stefan Monnier, 'Dani Moncayo'
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
Reading this bug report, it seems like everybody agrees that yanking a
text containing newlines in `C-s C-y' should have the match also match
other whitespace (if laxness is enabled). There was disagreement
whether the isearch prompt in these cases should be saying "foo^Jbar" or
"foo bar" -- the former would be difficult to implement, while the
latter isn't displaying exactly what the user yanked.
I think displaying "foo bar" makes the most sense, because we're in a
lax search. And I think one of the patches Juri prepared implemented
this, so I think we should just go ahead and push that change (possibly
behind a user option). Juri?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2022-04-22 12:28 ` Lars Ingebrigtsen
@ 2022-04-24 15:46 ` Juri Linkov
2022-04-25 7:26 ` Lars Ingebrigtsen
0 siblings, 1 reply; 23+ messages in thread
From: Juri Linkov @ 2022-04-24 15:46 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 13480, Stefan Monnier, 'Dani Moncayo'
> Reading this bug report, it seems like everybody agrees that yanking a
> text containing newlines in `C-s C-y' should have the match also match
> other whitespace (if laxness is enabled). There was disagreement
> whether the isearch prompt in these cases should be saying "foo^Jbar" or
> "foo bar" -- the former would be difficult to implement, while the
> latter isn't displaying exactly what the user yanked.
>
> I think displaying "foo bar" makes the most sense, because we're in a
> lax search. And I think one of the patches Juri prepared implemented
> this, so I think we should just go ahead and push that change (possibly
> behind a user option). Juri?
Ah, I already forgot about this problem, because it now works fine
with such customization :)
```
(setq search-whitespace-regexp "\\(?:\\s-\\|\n\\)+")
(setq-default search-default-mode 'char-fold-to-regexp)
(require 'char-fold)
(setq char-fold-symmetric t)
```
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
2022-04-24 15:46 ` Juri Linkov
@ 2022-04-25 7:26 ` Lars Ingebrigtsen
0 siblings, 0 replies; 23+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-25 7:26 UTC (permalink / raw)
To: Juri Linkov; +Cc: 13480, Stefan Monnier, 'Dani Moncayo'
Juri Linkov <juri@jurta.org> writes:
> Ah, I already forgot about this problem, because it now works fine
> with such customization :)
>
> ```
> (setq search-whitespace-regexp "\\(?:\\s-\\|\n\\)+")
> (setq-default search-default-mode 'char-fold-to-regexp)
> (require 'char-fold)
> (setq char-fold-symmetric t)
> ```
Yup, seems to work well, so I guess there's nothing further to do here,
and I'm therefore closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2022-04-25 7:26 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-17 20:39 bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces Dani Moncayo
2013-01-17 21:27 ` Juri Linkov
2013-01-17 23:10 ` Dani Moncayo
2013-01-17 23:54 ` Dani Moncayo
2013-01-18 21:59 ` Juri Linkov
2013-01-19 8:05 ` Dani Moncayo
2013-01-19 9:56 ` Dani Moncayo
2013-01-19 10:07 ` Juri Linkov
2013-01-19 10:40 ` Dani Moncayo
2013-01-19 10:57 ` Juri Linkov
2013-01-19 12:11 ` Dani Moncayo
2013-01-19 15:45 ` Drew Adams
2013-01-19 15:43 ` Drew Adams
2013-01-19 17:20 ` Stefan Monnier
2013-01-19 23:30 ` Juri Linkov
2013-01-20 9:41 ` Dani Moncayo
2013-01-20 12:27 ` Dani Moncayo
2022-04-22 12:28 ` Lars Ingebrigtsen
2022-04-24 15:46 ` Juri Linkov
2022-04-25 7:26 ` Lars Ingebrigtsen
2013-01-19 15:01 ` Drew Adams
2013-01-19 9:59 ` Juri Linkov
2013-08-03 17:09 ` Dani Moncayo
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).