all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dani Moncayo <dmoncayo@gmail.com>
To: Juri Linkov <juri@jurta.org>
Cc: 13480@debbugs.gnu.org
Subject: bug#13480: 24.3.50; `C-w' from Isearch should translate newlines to spaces
Date: Sun, 20 Jan 2013 10:41:56 +0100	[thread overview]
Message-ID: <CAH8Pv0hhNOh7hW_ChxAgJkHhksE9b7AX6O2RO+k3FPZLx5YXUg@mail.gmail.com> (raw)
In-Reply-To: <878v7okavd.fsf@mail.jurta.org>

>>>> 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





  reply	other threads:[~2013-01-20  9:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH8Pv0hhNOh7hW_ChxAgJkHhksE9b7AX6O2RO+k3FPZLx5YXUg@mail.gmail.com \
    --to=dmoncayo@gmail.com \
    --cc=13480@debbugs.gnu.org \
    --cc=juri@jurta.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.