unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@jurta.org>
To: Dani Moncayo <dmoncayo@gmail.com>
Cc: 10885@debbugs.gnu.org
Subject: bug#10885: Replace expressions: enhance functionality when searching in filled paragraphs
Date: Thu, 06 Sep 2012 19:50:58 +0300	[thread overview]
Message-ID: <871uif3xjh.fsf@mail.jurta.org> (raw)
In-Reply-To: <CAH8Pv0in1_aeO+n4QkPuceczChAKhJbsBkr4uPoGGmDGAoN9kQ@mail.gmail.com> (Dani Moncayo's message of "Thu, 6 Sep 2012 17:54:30 +0200")

> 1.  You've defined two separate variables (`isearch-lax-whitespace'
> and `isearch-regexp-lax-whitespace') to enable/disable the lax
> whitespace matching in search commands: one for basic search commands
> and the other for regexp search commands.  But there is only one
> similar variable (replace-lax-whitespace) which controls both basic
> and regexp replace commands.  Why this inconsistency?  I.e. why not
> define also a `replace-regexp-lax-whitespace' variable?

`isearch-regexp-lax-whitespace' was necessary to provide
backward-compatibility for old functionality.  Very likely
it will be declared obsolete.  But of course, it would be better
to have `replace-regexp-lax-whitespace' for consistency until
they both will be declared obsolete simultaneously.

> 2.  While in an incremental search commands, it is possible to toggle
> the value of the corresponding variable with `M-s SPC'.  Why not
> having the same possibility in incremental replace commands?

Isearch has different implementation than query-replace.
query-replace uses the normal minibuffer to read a string to replace.
Implementing `M-s SPC' for it means more trouble:
`query-replace-read-from' should set the arg `keymap' of
`read-from-minibuffer' to a new keymap with the `M-s SPC' keybinding
bound to a function to toggle the value of the defcustom option.

> 3.  Many users will want a consistent behavior wrt whitespace-matching
> between (regexp) search and (regexp) replace commands.  So, why not
> allowing to "connect" the corresponding variables?  I.e. why not
> defining some special value for `replace-lax-whitespace' and
> `replace-regexp-lax-whitespace' which means "get the value from the
> corresponding search variable" ?

When it will be decided that isearch and query-replace should have
the same default values, then `replace-lax-whitespace' could inherit
its default value from `isearch-lax-whitespace'.





  reply	other threads:[~2012-09-06 16:50 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-26  1:02 bug#10885: Replace expressions: enhance functionality when searching in filled paragraphs linuxfever
2012-02-26  1:57 ` Glenn Morris
2012-02-26  7:16   ` Kevin Rodgers
2012-02-28 10:04     ` Dani Moncayo
2012-02-28 10:09       ` Dani Moncayo
2012-02-28 10:42       ` Juri Linkov
2012-02-29  0:12         ` Glenn Morris
2012-02-29  0:41           ` Juri Linkov
2012-03-11  8:59             ` Dani Moncayo
2012-03-11 10:48               ` Juri Linkov
2012-09-02  9:45                 ` Juri Linkov
2012-09-02 11:32                   ` Juri Linkov
2012-09-05  8:38                     ` Juri Linkov
2012-09-05 14:38                       ` Stefan Monnier
2012-09-06  8:54                         ` Juri Linkov
2012-09-06 15:54                           ` Dani Moncayo
2012-09-06 16:50                             ` Juri Linkov [this message]
2012-09-06 17:39                               ` Dani Moncayo
2012-09-06 19:11                                 ` Juri Linkov
2012-09-06 19:15                                   ` Juri Linkov
2012-09-06 19:45                                   ` Dani Moncayo
2012-09-06 20:21                                     ` Dani Moncayo
2012-09-06 21:25                               ` Stefan Monnier
2012-09-07  8:33                                 ` Dani Moncayo
2012-09-07  9:28                                   ` Juri Linkov
2012-09-09 22:15                                     ` Juri Linkov
2012-09-05 14:39                       ` Stefan Monnier
2012-02-26 10:10   ` linuxfever
2012-02-26 21:22     ` Stefan Monnier
2012-02-26 10:17 ` Dani Moncayo
2012-02-27 10:58   ` Juri Linkov
2012-02-27 13:27     ` 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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=871uif3xjh.fsf@mail.jurta.org \
    --to=juri@jurta.org \
    --cc=10885@debbugs.gnu.org \
    --cc=dmoncayo@gmail.com \
    /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 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).