bug#22043: 25.0.50; search-forward and char folding

bug#22043: 25.0.50; search-forward and char folding

[Mike Kupfer]

(Resending because I had some odd mailer behavior when I first tried to
send this.)

The "Lax Search" Info node says

    Searches in Emacs by default perform character folding

But I don't see search-forward or search-backward doing that.  For
example, in the scratch buffer of "emacs -Q" if I do

  ä C-p
  M-x search-forward RET a RET

Emacs complains that the search failed.  (If it matters, the "ä" was
input using the 3-key sequence COMPOSE " a .)

I suspect that this is a bug in the code.  If not, the Info text should
be more precise about what searches perform character folding by
default.

Also, assuming that this is a bug in the code, the doc strings for
search-forward and search-backward should mention
search-default-regexp-mode, just like they mention case-fold-search.


In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2015-11-28
Repository revision: ea087151a901da36dd9ddc0843583906afafc7c5
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.2 (jessie)

Configured using:
 'configure --prefix=/usr/new'

Configured features:
XPM JPEG TIFF GIF PNG SOUND NOTIFY LIBXML2 FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11

Important settings:
  value of $LC_TIME: C
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  delete-selection-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  transient-mark-mode: t

Recent messages:
Loading vc...done
For information about GNU Emacs and the GNU system, type M-H C-a.
Deleting...done
(No files need saving)
Deleting...done
Creating customization items...
Creating customization items ...done
Resetting customization items...done
Creating customization setup...done
Mark saved where search started

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils misearch multi-isearch crm thingatpt
cus-edit cus-start cus-load wid-edit dired-x seq byte-opt gv bytecomp
byte-compile cconv cl-extra help-mode warnings server noutline outline
easy-mmode comint ansi-color ring xcscope easymenu advice ispell delsel
vc cl-loaddefs pcase cl-lib vc-dispatcher dired timeclock mdk-hacks
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote inotify dynamic-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 135420 7234)
 (symbols 48 24675 0)
 (miscs 40 479 429)
 (strings 32 27659 5728)
 (string-bytes 1 732934)
 (vectors 16 14940)
 (vector-slots 8 461430 6321)
 (floats 8 189 22)
 (intervals 56 392 11)
 (buffers 976 16)
 (heap 1024 44618 759))

bug#22043: 25.0.50; search-forward and char folding

[Artur Malabarba]

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

On 28 Nov 2015 10:11 pm, "Mike Kupfer" <m.kupfer@acm.org> wrote:
>
> I suspect that this is a bug in the code.  If not, the Info text should
> be more precise about what searches perform character folding by
> default.

I think it's a bug in the info doc. Something as basic as search-forward
shouldn't do char folding by default. Char folding can be quite slow, and
search-forward must be suitable for programmatic use.

I want to make some of the higher level search commands respect
search-default-regexp-function (such as the searches you start from the
menu bar). But search-forward won't be one of them.

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

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> Date: Sat, 28 Nov 2015 23:57:16 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: 22043@debbugs.gnu.org
> 
> I want to make some of the higher level search commands respect
> search-default-regexp-function (such as the searches you start from
> the menu bar).                              ^^^^^^^^^^^^^^^^^^^^^^^
  ^^^^^^^^^^^^
Can I document this in the manual already? ;-)

IOW, will this be in time for Emacs 25.1?

(When search commands are invoked from the menu bar, we should
probably pop up a search dialog similar to what other applications do,
instead of offering half a dozen different commands from the menus.
But that's definitely not for 25.1.)

TIA

bug#22043: 25.0.50; search-forward and char folding

[Artur Malabarba]

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

On 29 Nov 2015 4:33 pm, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
> > Date: Sat, 28 Nov 2015 23:57:16 +0000
> > From: Artur Malabarba <bruce.connor.am@gmail.com>
> > Cc: 22043@debbugs.gnu.org
> >
> > I want to make some of the higher level search commands respect
> > search-default-regexp-function (such as the searches you start from
> > the menu bar).                              ^^^^^^^^^^^^^^^^^^^^^^^
>   ^^^^^^^^^^^^
> Can I document this in the manual already? ;-)
>
> IOW, will this be in time for Emacs 25.1?

Yes. Just don't let me forget. ☺

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

bug#22043: 25.0.50; search-forward and char folding

[Artur Malabarba]

2015-11-29 16:33 GMT+00:00 Eli Zaretskii <eliz@gnu.org>:
> IOW, will this be in time for Emacs 25.1?

Done.

> (When search commands are invoked from the menu bar, we should
> probably pop up a search dialog similar to what other applications do,
> instead of offering half a dozen different commands from the menus.
> But that's definitely not for 25.1.)

Indeed.

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> Date: Sun, 29 Nov 2015 21:29:47 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Mike Kupfer <m.kupfer@acm.org>, 22043@debbugs.gnu.org
> 
> 2015-11-29 16:33 GMT+00:00 Eli Zaretskii <eliz@gnu.org>:
> > IOW, will this be in time for Emacs 25.1?
> 
> Done.

Thanks!

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> Date: Sat, 28 Nov 2015 14:11:42 -0800
> 
> The "Lax Search" Info node says
> 
>     Searches in Emacs by default perform character folding
> 
> But I don't see search-forward or search-backward doing that.  For
> example, in the scratch buffer of "emacs -Q" if I do
> 
>   ä C-p
>   M-x search-forward RET a RET
> 
> Emacs complains that the search failed.

I did test it before I wrote that text.  Try this recipe instead:

   ä C-p
   C-s RET a RET

The Emacs manual doesn't advertise search-forward and search-backward,
it advertises "C-s RET" and "C-r RET" instead, which do (by default)
perform character folding (and also obey the rest of the features
described in that node).

So yes, it's an inaccuracy in the manual, but not in that sentence.
The inaccuracy is where the manual says (or was saying):

     When you type ‘C-s <RET>’, the ‘C-s’ invokes incremental search as
  usual.  That command is specially programmed to invoke the command for
  nonincremental search, ‘search-forward’, if the string you specify is
  empty.  (Such an empty argument would otherwise be useless.)  ‘C-r
  <RET>’ does likewise, invoking the command ‘search-backward’.

"C-s RET" doesn't invoke search-forward, at least not by default,
haven't been doing that for quite some time.  I fixed that inaccuracy
now, thanks for pointing it out.

bug#22043: 25.0.50; search-forward and char folding

[Mike Kupfer]

Eli Zaretskii wrote:

> > From: Mike Kupfer <m.kupfer@acm.org>

> > The "Lax Search" Info node says
> > 
> >     Searches in Emacs by default perform character folding
> > 
> > But I don't see search-forward or search-backward doing that.
[...]
> The Emacs manual doesn't advertise search-forward and search-backward,
[...]
> "C-s RET" doesn't invoke search-forward, at least not by default,
> haven't been doing that for quite some time.  I fixed that inaccuracy
> now, thanks for pointing it out.

I took a look at your changes, and I agree that they make things
clearer.  Thanks.

The text in "Lax Search" now says

  Search commands in Emacs by default perform character folding

But search-forward can be found using M-x apropos, and it is listed as
being a command.  So I think the text in the "Lax Search" node still
needs work.

Would something like the following be acceptable?

  The search commands that are described in "Incremental Search" and
  "Nonincremental Search" perform character folding by default, thus
  matching equivalent character sequences.

If that's no good, an alternative might be to say that "Some search
commands ... perform character folding", and to add a note along the
lines of

  To determine whether character folding applies to a particular search
  command, see the Help text for that command.

regards,
mike

bug#22043: 25.0.50; search-forward and char folding

[Drew Adams]

> Would something like the following be acceptable?
> 
>   The search commands that are described in "Incremental Search" and
>   "Nonincremental Search" perform character folding by default, thus
>   matching equivalent character sequences.
> 
> If that's no good, an alternative might be to say that "Some search
> commands ... perform character folding", and to add a note along the
> lines of
> 
>   To determine whether character folding applies to a particular search
>   command, see the Help text for that command.

Isn't it correct and sufficient to say that non-regexp
incrementalsearch uses character folding by default?

IOW, isn't this default behavior true for all incremental
search commands except regexp search, and only for those
commands (no non-incremental search commands)?

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> Date: Sun, 29 Nov 2015 11:08:41 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22043@debbugs.gnu.org
> 
> Isn't it correct and sufficient to say that non-regexp
> incrementalsearch uses character folding by default?

No, because "C-s RET" actually invokes a regexp search behind the
user's back when character folding or lax-whitespace are in effect,
and the user has no way of knowing whether it invoked a regexp or
non-regexp search.

> IOW, isn't this default behavior true for all incremental
> search commands except regexp search, and only for those
> commands (no non-incremental search commands)?

No.  Nonincremental vs incremental is not the issue.  The issue is
whether the search function that the command employs uses regexps or
not.  It is a limitation of how these features are implemented that
they absolutely require regexp search.

bug#22043: 25.0.50; search-forward and char folding

[Artur Malabarba]

2015-11-29 19:08 GMT+00:00 Drew Adams <drew.adams@oracle.com>:
> IOW, isn't this default behavior true for all incremental
> search commands except regexp search, and only for those
> commands (no non-incremental search commands)?


No. There are ways to do non-incremental search that do char-folding too.

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> cc: 22043@debbugs.gnu.org
> Date: Sun, 29 Nov 2015 11:03:32 -0800
> 
> The text in "Lax Search" now says
> 
>   Search commands in Emacs by default perform character folding
> 
> But search-forward can be found using M-x apropos, and it is listed as
> being a command.  So I think the text in the "Lax Search" node still
> needs work.
> 
> Would something like the following be acceptable?
> 
>   The search commands that are described in "Incremental Search" and
>   "Nonincremental Search" perform character folding by default, thus
>   matching equivalent character sequences.
> 
> If that's no good, an alternative might be to say that "Some search
> commands ... perform character folding", and to add a note along the
> lines of
> 
>   To determine whether character folding applies to a particular search
>   command, see the Help text for that command.

I don't think such degree of precision is needed in a section whose
purpose is to describe an option that controls character folding.
With the commands that don't support character folding clearly
identified in the manual where those commands are described (and they
are only mentioned for completeness anyway, as they are not the
recommended ways of performing search), I think the manual strikes the
correct balance between being correct and still easily readable.

Thanks.

bug#22043: 25.0.50; search-forward and char folding

[Drew Adams]

> > Isn't it correct and sufficient to say that non-regexp
> > incrementalsearch uses character folding by default?
> 
> No, because "C-s RET" actually invokes a regexp search behind the
> user's back when character folding or lax-whitespace are in effect,
> and the user has no way of knowing whether it invoked a regexp or
> non-regexp search.
> 
> > IOW, isn't this default behavior true for all incremental
> > search commands except regexp search, and only for those
> > commands (no non-incremental search commands)?
> 
> No.  Nonincremental vs incremental is not the issue.  The issue is
> whether the search function that the command employs uses regexps or
> not.  It is a limitation of how these features are implemented that
> they absolutely require regexp search.

OK, but from a user point of view, is this not the case:

1. S?he invokes search using `C-M-s' or `C-s', which are
advertised as regexp and plain (non regexp) search.  IOW,
regardless of what might go on under the covers (and a
lot already does, for lax whitespace searching), s?he
thinks of `C-s' as performing a non-regexp search.

2. There is no character folding with the "regexp" commands
(`C-M-s'), because char folding substitutes its own regexp
for the user input, and char folding does not currently
parse regexp-pattern user input.

Perhaps, to be more precise, the difference is search that
does or does not accept general regexp patterns as _input_.
Those that do have "regexp" (or "-re-"?) in their name;
those that do not do not have it.  The former do not
support char folding; the latter do.  Is that correct (and
complete)?

I guess I was mistaken in thinking that non-incremental
search commands, such as `nonincremental-search-forward',
do not support char folding (regardless of whether they
include "-re" in their name).  Which ones support it, and
under what circumstances?

bug#22043: 25.0.50; search-forward and char folding

[Mike Kupfer]

Drew Adams wrote:

> Perhaps, to be more precise, the difference is search that
> does or does not accept general regexp patterns as _input_.
> Those that do have "regexp" (or "-re-"?) in their name;
> those that do not do not have it.  The former do not
> support char folding; the latter do.  Is that correct (and
> complete)?

I'm afraid it's more complicated than that.  If nothing else, there's
the "word" family of search functions, which don't do character folding.

regards,
mike

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 22043@debbugs.gnu.org
> Date: Sun, 29 Nov 2015 20:53:02 -0800
> 
> > Perhaps, to be more precise, the difference is search that
> > does or does not accept general regexp patterns as _input_.
> > Those that do have "regexp" (or "-re-"?) in their name;
> > those that do not do not have it.  The former do not
> > support char folding; the latter do.  Is that correct (and
> > complete)?
> 
> I'm afraid it's more complicated than that.  If nothing else, there's
> the "word" family of search functions, which don't do character folding.

Yes, exactly.  And also symbol search, etc.

I've just realized that the effect of the toggles on the search mode
is not documented in the doc strings of the toggles or in the manual,
so I added that.

bug#22043: 25.0.50; search-forward and char folding

[Artur Malabarba]

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

On 29 Nov 2015 8:41 pm, "Drew Adams" <drew.adams@oracle.com> wrote:
> Perhaps, to be more precise, the difference is search that
> does or does not accept general regexp patterns as _input_.
> Those that do have "regexp" (or "-re-"?) in their name;
> those that do not do not have it.  The former do not
> support char folding; the latter do.  Is that correct (and
> complete)?
>
> I guess I was mistaken in thinking that non-incremental
> search commands, such as `nonincremental-search-forward',
> do not support char folding (regardless of whether they
> include "-re" in their name).  Which ones support it, and
> under what circumstances?

All of the nonincremental-*search-* support folding (except those that use
regexp).

In general, you're correct that most non-regexp searches do char folding.
But that's most, not all. A plain `search-forward' doesn't do folding (by
choice). So we can't just document that "all non regexp searches do
folding".

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

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> Date: Sun, 29 Nov 2015 12:41:16 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: m.kupfer@acm.org, 22043@debbugs.gnu.org
> 
> > > IOW, isn't this default behavior true for all incremental
> > > search commands except regexp search, and only for those
> > > commands (no non-incremental search commands)?
> > 
> > No.  Nonincremental vs incremental is not the issue.  The issue is
> > whether the search function that the command employs uses regexps or
> > not.  It is a limitation of how these features are implemented that
> > they absolutely require regexp search.
> 
> OK, but from a user point of view, is this not the case:
> 
> 1. S?he invokes search using `C-M-s' or `C-s', which are
> advertised as regexp and plain (non regexp) search.  IOW,
> regardless of what might go on under the covers (and a
> lot already does, for lax whitespace searching), s?he
> thinks of `C-s' as performing a non-regexp search.

Perhaps so, but (a) I see that you've dropped the incremental vs
nonincremental distinction, which agrees with what I say above; and
(b) we cannot really say in the manual something like "commands
invoked by `C-s' do character folding", because the reader might not
yet know/remember enough for such a distinction to be useful for her.

> 2. There is no character folding with the "regexp" commands
> (`C-M-s'), because char folding substitutes its own regexp
> for the user input, and char folding does not currently
> parse regexp-pattern user input.

That's implementation.  From the user POV, typing "C-M-s M-s '"
magically does support character folding, but it also switches the
search to a non-regexp one!  So is it a regexp search or isn't it?

> Perhaps, to be more precise, the difference is search that
> does or does not accept general regexp patterns as _input_.
> Those that do have "regexp" (or "-re-"?) in their name;
> those that do not do not have it.  The former do not
> support char folding; the latter do.  Is that correct (and
> complete)?

I think neither, because of the subtle behind-the-scenes effect of the
"M-s C" toggles (where C is a character like ' or _ or w).

> I guess I was mistaken in thinking that non-incremental
> search commands, such as `nonincremental-search-forward',
> do not support char folding (regardless of whether they
> include "-re" in their name).  Which ones support it, and
> under what circumstances?

Each command should tell in its doc string whether it does or doesn't,
and the manual should also document that where it describes the
command itself.  AFAICS, this is currently (as of today ;-) so.  I
don't think we can do any better.  The real criterion is "where it's
easy to provide given the limitations of the implementation we have",
but that's not useful for user documentation.

Anyway, if I return to the original issue, the section with the
offending "Search commands in Emacs by default perform character
folding" sentence has its main focus on explaining what is character
folding and how to enable/disable it; it does not focus on the
specific commands.  So it uses some vague definitions of the default
behavior, which is later described more accurately for each particular
command.  This is standard practice in user-level documentation, when
describing complex issues: you first provide an overview that might
not be 100% accurate, but should give the reader a clear and simple
enough idea of the subject, leaving the more accurate details for
later in-depth coverage.  I don't see how we can do significantly
better; all of the proposals till now make the description much more
complicated and thus confusing, especially upon first reading.

If people think that saying something more vague like

  Some search commands by default perform character folding (whether
  it does or doesn't is documented for each specific command)

will do a better job, maybe we could use that.  To me, this sounds
worse, because it immediately raises the question: which commands do
and which don't.  That question will interfere with the reader's
attention to the issue at hand, which isn't the particular commands,
but the folding in general and how to toggle/disable it.

bug#22043: 25.0.50; search-forward and char folding

[Mike Kupfer]

Eli Zaretskii wrote:

> Anyway, if I return to the original issue, the section with the
> offending "Search commands in Emacs by default perform character
> folding" sentence has its main focus on explaining what is character
> folding and how to enable/disable it; it does not focus on the
> specific commands.

Well, the explanation of what character folding is actually happens in
the previous paragraph.  The one that starts with "Search commands in
Emacs by default perform character folding" is just about enabling or
disabling character folding.

I agree with your point about flow and not distracting the reader by
throwing multiple issues together.  And I think that for most users,
information about enabling/disabling char folding is more important than
knowing which functions do folding, so I think that paragraph should (as
it does) come next after the description of what char folding is.

> This is standard practice in user-level documentation, when
> describing complex issues: you first provide an overview that might
> not be 100% accurate, but should give the reader a clear and simple
> enough idea of the subject, leaving the more accurate details for
> later in-depth coverage.

Yes, but when I'm reading documentation, if I see what looks like a
definite statement and then I find something else that appears to
contradict the first statement, my first reaction is to start doubting
the documentation as a whole.  The way I usually handle this when I'm
writing is to insert a "weasel word".  What do you think about changing
the first phrase to

  Search commands in Emacs generally perform character folding by
  default

(or maybe "commonly" instead of "generally").  As a reader, this tells
me that there are exceptions but I shouldn't worry about them at this
point in the text.

As an alternative: sometimes in documentation I'll see a definite
statement, followed later by an explicit acknowledgement that the
statement was a simplification.  I'd be okay with that approach, too.
As a reader, it tells me that the first statement was deliberately
chosen, not an oversight.

regards,
mike

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> cc: Drew Adams <drew.adams@oracle.com>, 22043@debbugs.gnu.org
> Date: Mon, 30 Nov 2015 12:31:43 -0800
> 
>   Search commands in Emacs generally perform character folding by
>   default
> 
> (or maybe "commonly" instead of "generally").

I'm okay with that, if it makes the difference.

bug#22043: 25.0.50; search-forward and char folding

[Andreas Röhler]

Am 30.11.2015 um 21:51 schrieb Eli Zaretskii:
>> From: Mike Kupfer <m.kupfer@acm.org>
>> cc: Drew Adams <drew.adams@oracle.com>, 22043@debbugs.gnu.org
>> Date: Mon, 30 Nov 2015 12:31:43 -0800
>>
>>    Search commands in Emacs generally perform character folding by
>>    default
>>
>> (or maybe "commonly" instead of "generally").
> I'm okay with that, if it makes the difference.
>
>
>

AFAIU it should go out there completely, being moved into a later 
section, where the refining stuff resides.
Understand char-folding as a special form of regexp-search.

IMO it isn't worth to give it a such prominent focus and distracting 
from more important stuff.
And it should be off by default.

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, Mike Kupfer <m.kupfer@acm.org>,
>  Drew Adams <drew.adams@oracle.com>
> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> Date: Tue, 1 Dec 2015 08:37:18 +0100
> 
> AFAIU it should go out there completely, being moved into a later section, where the refining stuff resides.

It is explained in a section dedicated to "lax search", where other
kinds of non-literal matching are described.  I think that bringing
this stuff together in a single section makes it easier to describe,
as the features are similar with similar toggles.

> Understand char-folding as a special form of regexp-search.

This is the current implementation.  But a user manual should not be
driven by implementation, it should be driven by user-level POV, where
features can be similar even though their implementations are very
different.

> IMO it isn't worth to give it a such prominent focus and distracting from more important stuff.

It doesn't get any prominent focus.  Please take a look at the manual:
this is described only _after_ we've covered incremental and
non-incremental search, word search, symbol search, and regexp
search.  It's actually quite close to the end of the chapter, just
before we describe replace commands.

> And it should be off by default.

This is not really relevant to documentation, which is the subject of
this bug report.

bug#22043: 25.0.50; search-forward and char folding

[Mike Kupfer]

Huh, for some reason I'm not getting Eli's emails.  But at least I can
seem them in the web site.

> Am 30.11.2015 um 21:51 schrieb Eli Zaretskii:
> >> From: Mike Kupfer <m.kupfer@acm.org>
> >> cc: Drew Adams <drew.adams@oracle.com>, 22043@debbugs.gnu.org
> >> Date: Mon, 30 Nov 2015 12:31:43 -0800
> >>
> >>    Search commands in Emacs generally perform character folding by
> >>    default
> >>
> >> (or maybe "commonly" instead of "generally").
> > I'm okay with that, if it makes the difference.

Yes please, I think it's helpful.  Thanks.

I agree 100% with Eli's message today (#65).

regards,
mike

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> cc: bug-gnu-emacs@gnu.org, Drew Adams <drew.adams@oracle.com>,
>         Andreas Röhler <andreas.roehler@easy-emacs.de>
> Date: Tue, 01 Dec 2015 12:30:46 -0800
> 
> > >>    Search commands in Emacs generally perform character folding by
> > >>    default
> > >>
> > >> (or maybe "commonly" instead of "generally").
> > > I'm okay with that, if it makes the difference.
> 
> Yes please, I think it's helpful.  Thanks.

Done.

bug#22043: 25.0.50; search-forward and char folding

[Artur Malabarba]

>> Yes please, I think it's helpful.  Thanks.
>
> Done.

I think we can close this, then?

bug#22043: 25.0.50; search-forward and char folding

[Mike Kupfer]

Artur Malabarba wrote:

> I think we can close this, then?

Yes, that's fine with me.  Thanks again, Eli.

mike

bug#22043: 25.0.50; search-forward and char folding

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 22043@debbugs.gnu.org
> Date: Tue, 08 Dec 2015 07:08:47 -0800
> 
> Artur Malabarba wrote:
> 
> > I think we can close this, then?
> 
> Yes, that's fine with me.  Thanks again, Eli.

You are welcome.

Closing.