[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25482: 26.0.50; Allow setting `query-replace-from-to-separator` to n

From: Eli Zaretskii
Subject: bug#25482: 26.0.50; Allow setting `query-replace-from-to-separator` to nil
Date: Thu, 19 Jan 2017 18:01:12 +0200

> From: Thierry Volpiatto <address@hidden>
> Date: Thu, 19 Jan 2017 09:18:07 +0100
> Actually it is not possible to customize easily
> `query-replace-from-to-separator` and it is impossible to set it to nil.
> If I use `setq`, `custom-reevaluate-setting` reevaluate the original
> sexp from `query-replace-from-to-separator` and if I use customize I can
> add a string or a sexp, nothing else.
> But the code in `query-replace-read-from` is checking if
> `query-replace-from-to-separator` is non-nil, which is impossible
> actually.
> Thus it adds difficulties to load such sexp when dumping emacs.
> I would expect setting `query-replace-from-to-separator` to nil to
> retrieve same behavior as emacs-24.5 and not have unicode strings in my
> minibuffer-history.

Sorry, I don't think I follow: you should be able to set this variable
to " -> ", a string, to get the old behavior and avoid non-ASCII
strings in your minibuffer-history.  So why did you need the value of

> +    (when (stringp query-replace-from-to-separator)
> +      (setq query-replace-from-to-separator
> +            (propertize (if (char-displayable-p
> +                             (string-to-char 
> query-replace-from-to-separator))

This doesn't look right: string-to-char will return the blank
character, which is the first character of " → ", and I don't think
you meant that.

In any case, this looks more complex than it has to be, because you
for some reason want to have the nil value.  Please elaborate on the
need for that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]