bug#26274: 26.0.50; completion regression

bug#26274: 26.0.50; completion regression

[Stephen Berman]

Substring completion involving non-ascii characters (with or without
case-folding) does not work in current master as it had till recently
and still does in Emacs 25.2 (my most recent build from master is from
March 15 and it also shows the problem).  To reproduce:

0. In a shell: cd /tmp; touch atest Atest ätest Ätest testä testÄ
1. Let ~/.emacs consist of the following:
--8<---------------cut here---------------start------------->8---
(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(completion-category-overrides
   (quote
    ((buffer
      (styles substring))
     (file
      (styles substring)))))
 '(read-buffer-completion-ignore-case t)
 '(read-file-name-completion-ignore-case t))
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
)
--8<---------------cut here---------------end--------------->8---
2. Start emacs; after typing `C-x C-f test TAB' the *Completions* buffer
   shows all six files from step 0. 
3. With both `C-x C-f atest TAB' and `C-x C-f atest TAB' the
   *Completions* buffer shows both atest and Atest. 
4. With `C-x C-f ätest TAB', `C-x C-f Ätest TAB', `C-x C-f testä TAB',
   or `C-x C-f testÄ TAB', the minibuffer displays "[Sole completion]".
   In 25.2 with the first two, the *Completions* buffer shows both ätest
   and Ätest and with the last two, both testä and testÄ.


In GNU Emacs 26.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.20.10)
 of 2017-03-27 built on rosalinde
Repository revision: bd074d9bab470da24dd79491d8c25b22c2a5bb3d
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	openSUSE Leap 42.2

Configured using:
 'configure --with-xwidgets 'CFLAGS=-Og -g3''

bug#26274: 26.0.50; completion regression

[Stephen Berman]

On Mon, 27 Mar 2017 12:56:19 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> Substring completion involving non-ascii characters (with or without
> case-folding) does not work in current master as it had till recently
> and still does in Emacs 25.2 (my most recent build from master is from
                                    
Oops: s/most recent/oldest/

> March 15 and it also shows the problem).  To reproduce:

Steve Berman

bug#26274: 26.0.50; completion regression

[Stephen Berman]

On Mon, 27 Mar 2017 18:22:29 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Mon, 27 Mar 2017 12:56:19 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> Substring completion involving non-ascii characters (with or without
>> case-folding) does not work in current master as it had till recently
>> and still does in Emacs 25.2 (my most recent build from master is from
>                                     
> Oops: s/most recent/oldest/
>
>> March 15 and it also shows the problem).  To reproduce:

This is commit a3207a383009720bbd89327425e0eb1c9c20c267.  I have now
found an older build from master from February 8, commit
e3b659630843de7e459bce483c278af765c644f7, which does not have this
completion problem.  However, when I run git bisect on these commits and
then make, it fails as follows:

steve@rosalinde:/data/steve/git/emacs-master> make
cd . && ./autogen.sh autoconf
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Checking for automake (need at least version 1.11) ... ok
Your system has the required tools.
Running 'autoreconf -fi -I m4' ...
/usr/bin/m4:aclocal.m4:9: cannot open `m4/count-leading-zeros.m4': No such file or directory
autom4te: /usr/bin/m4 failed with exit status: 1
/usr/bin/m4:aclocal.m4:9: cannot open `m4/count-leading-zeros.m4': No such file or directory
autom4te: /usr/bin/m4 failed with exit status: 1
autoreconf: /usr/bin/autoconf failed with exit status: 1
Makefile:450: recipe for target 'configure' failed
make: *** [configure] Error 1

This continues to happen when I repeatedly call `git bisect skip'.  Is
there anything I can do to proceed with the bisection?

Steve Berman

bug#26274: 26.0.50; completion regression

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Wed, 29 Mar 2017 19:00:30 +0200
> 
> >> March 15 and it also shows the problem).  To reproduce:
> 
> This is commit a3207a383009720bbd89327425e0eb1c9c20c267.  I have now
> found an older build from master from February 8, commit
> e3b659630843de7e459bce483c278af765c644f7, which does not have this
> completion problem.

If so, then please see if the problematic commits are one or more of
these:

  commit 9f9863e50298a3506165cc1f056ab3238f37cb9f
  Author:     Michal Nazarewicz <mina86@mina86.com>
  AuthorDate: Fri Feb 17 16:36:44 2017 +0100

      Fix build failure caused by `Generate upcase and downcase tables from Unicod

  commit 6220faeb4e9be16b9dec728e72ea8dff2cfe35ba
  Author:     Michal Nazarewicz <mina86@mina86.com>
  AuthorDate: Wed Sep 7 21:00:57 2016 +0200

      casing: don't assume letters are *either* upper- or lower-case  (bug#24603)

  commit 5ec3a58462e99533ea5200de356302181d634d0b
  Author:     Michal Nazarewicz <mina86@mina86.com>
  AuthorDate: Mon Sep 19 00:23:40 2016 +0200

      Generate upcase and downcase tables from Unicode data  (bug#24603)

bug#26274: 26.0.50; completion regression

[Noam Postavsky]

On Wed, Mar 29, 2017 at 1:00 PM, Stephen Berman <stephen.berman@gmx.net> wrote:
>
> This is commit a3207a383009720bbd89327425e0eb1c9c20c267.  I have now
> found an older build from master from February 8, commit
> e3b659630843de7e459bce483c278af765c644f7, which does not have this
> completion problem.  However, when I run git bisect on these commits and
> then make, it fails as follows:
>
> steve@rosalinde:/data/steve/git/emacs-master> make
> cd . && ./autogen.sh autoconf
> Checking whether you have the necessary tools...
> (Read INSTALL.REPO for more details on building Emacs)
> Checking for autoconf (need at least version 2.65) ... ok
> Checking for automake (need at least version 1.11) ... ok
> Your system has the required tools.
> Running 'autoreconf -fi -I m4' ...
> /usr/bin/m4:aclocal.m4:9: cannot open `m4/count-leading-zeros.m4': No such file or directory
> autom4te: /usr/bin/m4 failed with exit status: 1

m4/count-leading-zeros.m4 is added by [1: 74f87fd], maybe try deleting
aclocal.m4 to stop autoconf from trying to find it when building older
commits? (although I would have thought autoreconf with the '-f' flag
would be doing that already)

1: 2017-03-03 09:19:08 -0800 74f87fd111904e5156727c72590d6fc4f67e8366
  logb now works correctly on large integers

bug#26274: 26.0.50; completion regression

[Stephen Berman]

On Wed, 29 Mar 2017 13:28:18 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> On Wed, Mar 29, 2017 at 1:00 PM, Stephen Berman <stephen.berman@gmx.net> wrote:
>>
>> This is commit a3207a383009720bbd89327425e0eb1c9c20c267.  I have now
>> found an older build from master from February 8, commit
>> e3b659630843de7e459bce483c278af765c644f7, which does not have this
>> completion problem.  However, when I run git bisect on these commits and
>> then make, it fails as follows:
>> [...]
>
> m4/count-leading-zeros.m4 is added by [1: 74f87fd], maybe try deleting
> aclocal.m4 to stop autoconf from trying to find it when building older
> commits? (although I would have thought autoreconf with the '-f' flag
> would be doing that already)

Thanks, removing that file allowed configure to complete, but now I get
this:

checking that generated files are newer than configure... done
configure: creating ./config.status
make: *** No rule to make target 'lib/gnulib.mk.in', needed by 'Makefile'.  Stop.

git bisect skip doesn't eliminate this failure.

On Wed, 29 Mar 2017 20:27:03 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Wed, 29 Mar 2017 19:00:30 +0200
>> 
>> >> March 15 and it also shows the problem).  To reproduce:
>> 
>> This is commit a3207a383009720bbd89327425e0eb1c9c20c267.  I have now
>> found an older build from master from February 8, commit
>> e3b659630843de7e459bce483c278af765c644f7, which does not have this
>> completion problem.
>
> If so, then please see if the problematic commits are one or more of
> these:
>
>   commit 9f9863e50298a3506165cc1f056ab3238f37cb9f
>   Author:     Michal Nazarewicz <mina86@mina86.com>
>   AuthorDate: Fri Feb 17 16:36:44 2017 +0100
>
>       Fix build failure caused by `Generate upcase and downcase tables from Unicod
>
>   commit 6220faeb4e9be16b9dec728e72ea8dff2cfe35ba
>   Author:     Michal Nazarewicz <mina86@mina86.com>
>   AuthorDate: Wed Sep 7 21:00:57 2016 +0200
>
>       casing: don't assume letters are *either* upper- or lower-case  (bug#24603)
>
>   commit 5ec3a58462e99533ea5200de356302181d634d0b
>   Author:     Michal Nazarewicz <mina86@mina86.com>
>   AuthorDate: Mon Sep 19 00:23:40 2016 +0200
>
>       Generate upcase and downcase tables from Unicode data  (bug#24603)

My guess is the first of these, since it's between the bad and good
builds; the other two commits are much earlier.  But given the above
make failure, I don't know how to build that commit (or the one before
it).

Steve Berman

bug#26274: 26.0.50; completion regression

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 26274@debbugs.gnu.org, Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 29 Mar 2017 20:27:57 +0200
> 
> My guess is the first of these, since it's between the bad and good
> builds; the other two commits are much earlier.  But given the above
> make failure, I don't know how to build that commit (or the one before
> it).

You could clone the repository anew, checkout that commit, and then
build.

bug#26274: 26.0.50; completion regression

[Stephen Berman]

On Wed, 29 Mar 2017 21:33:57 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 26274@debbugs.gnu.org, Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Wed, 29 Mar 2017 20:27:57 +0200
>> 
>> My guess is the first of these, since it's between the bad and good
>> builds; the other two commits are much earlier.  But given the above
>> make failure, I don't know how to build that commit (or the one before
>> it).
>
> You could clone the repository anew, checkout that commit, and then
> build.

On my hardware this is unfortunately very time-consuming.  Is there no
other way?

Steve Berman

bug#26274: 26.0.50; completion regression

[Noam Postavsky]

On Wed, Mar 29, 2017 at 2:27 PM, Stephen Berman <stephen.berman@gmx.net> wrote:

> Thanks, removing that file allowed configure to complete, but now I get
> this:
>
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> make: *** No rule to make target 'lib/gnulib.mk.in', needed by 'Makefile'.  Stop.

Starting from a fresh checkout like Eli suggested is the safest way,
but I guess you should be able to get around this error by deleting
'Makefile', and regenerating it by running ./configure again.

bug#26274: 26.0.50; completion regression

[Stephen Berman]

On Wed, 29 Mar 2017 14:49:42 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> On Wed, Mar 29, 2017 at 2:27 PM, Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> Thanks, removing that file allowed configure to complete, but now I get
>> this:
>>
>> checking that generated files are newer than configure... done
>> configure: creating ./config.status
>> make: *** No rule to make target 'lib/gnulib.mk.in', needed by 'Makefile'.  Stop.
>
> Starting from a fresh checkout like Eli suggested is the safest way,
> but I guess you should be able to get around this error by deleting
> 'Makefile', and regenerating it by running ./configure again.

Thanks, I went this route, and it worked (and still took almost an hour
to go through eight iterations).  Git bisect in fact pinpointed this
commit:

5ec3a58462e99533ea5200de356302181d634d0b is the first bad commit
commit 5ec3a58462e99533ea5200de356302181d634d0b
Author: Michal Nazarewicz <mina86@mina86.com>
Date:   Mon Sep 19 00:23:40 2016 +0200

    Generate upcase and downcase tables from Unicode data  (bug#24603)
    
    Use Unicode data to generate case tables instead of mostly repeating
    them in lisp code.  Do that in a way which maps ‘Dz’ (and similar)
    digraph to ‘dz’ when down- and ‘DZ’ when upcasing.
    
    https://debbugs.gnu.org/cgi/bugreport.cgi?msg=89;bug=24603 lists all
    changes to syntax table and case tables introduced by this commit.
    
    * lisp/international/characters.el: Remove case-pairs defined with
    explicit Lisp code and instead use Unicode character properties.
    
    * test/src/casefiddle-tests.el (casefiddle-tests--characters,
    casefiddle-tests-casing): Update test cases which are now working
    as they should.

(When Eli listed this as a candidate, I doubted it because of the date,
since my build from February 8 of this year does not have the problem.
I guess that date is not the commit date.  Confusing when looking at the
commit log.)

Steve Berman

bug#26274: 26.0.50; completion regression

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  26274@debbugs.gnu.org
> Date: Wed, 29 Mar 2017 22:00:27 +0200
> 
> > Starting from a fresh checkout like Eli suggested is the safest way,
> > but I guess you should be able to get around this error by deleting
> > 'Makefile', and regenerating it by running ./configure again.
> 
> Thanks, I went this route, and it worked (and still took almost an hour
> to go through eight iterations).  Git bisect in fact pinpointed this
> commit:
> 
> 5ec3a58462e99533ea5200de356302181d634d0b is the first bad commit
> commit 5ec3a58462e99533ea5200de356302181d634d0b
> Author: Michal Nazarewicz <mina86@mina86.com>
> Date:   Mon Sep 19 00:23:40 2016 +0200
> 
>     Generate upcase and downcase tables from Unicode data  (bug#24603)
>     
>     Use Unicode data to generate case tables instead of mostly repeating
>     them in lisp code.  Do that in a way which maps ‘Dz’ (and similar)
>     digraph to ‘dz’ when down- and ‘DZ’ when upcasing.
>     
>     https://debbugs.gnu.org/cgi/bugreport.cgi?msg=89;bug=24603 lists all
>     changes to syntax table and case tables introduced by this commit.
>     
>     * lisp/international/characters.el: Remove case-pairs defined with
>     explicit Lisp code and instead use Unicode character properties.
>     
>     * test/src/casefiddle-tests.el (casefiddle-tests--characters,
>     casefiddle-tests-casing): Update test cases which are now working
>     as they should.
> 
> (When Eli listed this as a candidate, I doubted it because of the date,
> since my build from February 8 of this year does not have the problem.
> I guess that date is not the commit date.  Confusing when looking at the
> commit log.)

The commit date is Feb 15.  This commit came from a feature branch, so
the date you see in the log I show is the original commit date on that
branch.

Michal, could you please take a look at this?

bug#26274: 26.0.50; completion regression

[Michal Nazarewicz]

On Thu, Mar 30 2017, Eli Zaretskii wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  26274@debbugs.gnu.org
>> Date: Wed, 29 Mar 2017 22:00:27 +0200
>> 
>> > Starting from a fresh checkout like Eli suggested is the safest way,
>> > but I guess you should be able to get around this error by deleting
>> > 'Makefile', and regenerating it by running ./configure again.
>> 
>> Thanks, I went this route, and it worked (and still took almost an hour
>> to go through eight iterations).  Git bisect in fact pinpointed this
>> commit:
>> 
>> 5ec3a58462e99533ea5200de356302181d634d0b is the first bad commit
>> commit 5ec3a58462e99533ea5200de356302181d634d0b
>> Author: Michal Nazarewicz <mina86@mina86.com>
>> Date:   Mon Sep 19 00:23:40 2016 +0200
>> 
>>     Generate upcase and downcase tables from Unicode data  (bug#24603)
>>     
>>     Use Unicode data to generate case tables instead of mostly repeating
>>     them in lisp code.  Do that in a way which maps ‘Dz’ (and similar)
>>     digraph to ‘dz’ when down- and ‘DZ’ when upcasing.
>>     
>>     https://debbugs.gnu.org/cgi/bugreport.cgi?msg=89;bug=24603 lists all
>>     changes to syntax table and case tables introduced by this commit.
>>     
>>     * lisp/international/characters.el: Remove case-pairs defined with
>>     explicit Lisp code and instead use Unicode character properties.
>>     
>>     * test/src/casefiddle-tests.el (casefiddle-tests--characters,
>>     casefiddle-tests-casing): Update test cases which are now working
>>     as they should.
>> 
>> (When Eli listed this as a candidate, I doubted it because of the date,
>> since my build from February 8 of this year does not have the problem.
>> I guess that date is not the commit date.  Confusing when looking at the
>> commit log.)

You can do ‘git show --format=fuller 5ec3a58462e99533ea520’ to see
commit date but even that can be rather misleading.

> The commit date is Feb 15.  This commit came from a feature branch, so
> the date you see in the log I show is the original commit date on that
> branch.
>
> Michal, could you please take a look at this?

Strangely I cannot reproduce it.  I’ve run ‘emacs -Q’, executed

    (custom-set-variables
     '(completion-category-overrides
       (quote ((buffer (styles substring))
               (file (styles substring)))))
     '(read-buffer-completion-ignore-case t)
     '(read-file-name-completion-ignore-case t))

and with atest, Atest, ätest, Ätest, testä and testÄ files in the
directory I get the following completions:

    | Typed | Completions                         |
    |-------+-------------------------------------|
    | test  | atest Atest ätest Ätest testä testÄ |
    |-------+-------------------------------------|
    | atest | atest Atest                         |
    | Atest | atest Atest                         |
    | ätest | ätest Ätest                         |
    | Ätest | ätest Ätest                         |
    |-------+-------------------------------------|
    | testa | NOTHING                             |
    | testA | NOTHING                             |
    | testä | testä testÄ                         |
    | testÄ | testä testÄ                         |

which is what is expected.

GNU Emacs 26.0.50 (build 3, x86_64-pc-linux-gnu) of 2017-03-21 build
from ffbb4684999 (I think) + patchset (I think).  I’ll rebase and try
again with fresher version.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#26274: 26.0.50; completion regression

[Michal Nazarewicz]

On Thu, Mar 30 2017, Michal Nazarewicz wrote:
> Strangely I cannot reproduce it.  I’ve run ‘emacs -Q’, executed
>
>     (custom-set-variables
>      '(completion-category-overrides
>        (quote ((buffer (styles substring))
>                (file (styles substring)))))
>      '(read-buffer-completion-ignore-case t)
>      '(read-file-name-completion-ignore-case t))
>
> and with atest, Atest, ätest, Ätest, testä and testÄ files in the
> directory I get the following completions:
>
>     | Typed | Completions                         |
>     |-------+-------------------------------------|
>     | test  | atest Atest ätest Ätest testä testÄ |
>     |-------+-------------------------------------|
>     | atest | atest Atest                         |
>     | Atest | atest Atest                         |
>     | ätest | ätest Ätest                         |
>     | Ätest | ätest Ätest                         |
>     |-------+-------------------------------------|
>     | testa | NOTHING                             |
>     | testA | NOTHING                             |
>     | testä | testä testÄ                         |
>     | testÄ | testä testÄ                         |
>
> which is what is expected.
>
> GNU Emacs 26.0.50 (build 3, x86_64-pc-linux-gnu) of 2017-03-21 build
> from ffbb4684999 (I think) + patchset (I think).  I’ll rebase and try
> again with fresher version.

I still cannot reproduce it at HEAD+my patchset.

./configure --with-x-toolkit=no --without-toolkit-scroll-bars \
	--without-dbus --without-gconf --without-gsettings \
	--without-selinux --with-x --enable-link-time-optimization

Configured for 'x86_64-pc-linux-gnu'.

  Where should the build process find the source code?    .
  What compiler should emacs be built with?               gcc -std=gnu11 -g3 -O2 -flto=4 -ffat-lto-objects
  Should Emacs use the GNU version of malloc?             yes
      (Using Doug Lea's new malloc from the GNU C Library.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          none
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use a png library?                           yes -L/usr/lib/x86_64-linux-gnu -lpng12
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use cairo?                                   no
  Does Emacs use imagemagick?                             no
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  no
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               no
  Does Emacs use a file notification library?             yes -lglibc (inotify)
  Does Emacs use access control lists?                    no
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use -lm17n-flt?                              yes
  Does Emacs use -lotf?                                   yes
  Does Emacs use -lxft?                                   yes
  Does Emacs use -lsystemd?                               no
  Does Emacs directly use zlib?                           yes
  Does Emacs have dynamic modules support?                no
  Does Emacs use toolkit scroll bars?                     no
  Does Emacs support Xwidgets (requires gtk3)?            no
  Does Emacs have threading support in lisp?              yes

$ git log --oneline -n19
ff5db06065b (HEAD -> master, o/master) Fix case-fold-search character class matching  (bug#24603)
99f6478cff4 Optimise character class matching in regexes  (bug#24603)
6a91a1f8930 Refactor character class checking; optimise ASCII case  (bug#24603)
551c97b3d08 Base lower- and upper-case tests on Unicode properties  (bug#24603)
d84bab38efc Add regex character class matching benchmark  (bug#24603)
a237539c476 Factor out character category lookup to separate function  (bug#24603)
ca436b71f48 Add some tricky Unicode characters to regex test  (bug#24603)
febef068263 Implement Irish casing rules  (bug#24603)
d83a7387e10 Implement casing rules for Lithuanian  (bug#24603)
8ef5ccdc9b9 Implement Turkic dotless and dotted i casing rules  (bug#24603)
019c1a9727f Implement rules for title-casing Dutch ij ‘letter’  (bug#24603)
9750553fae6 Introduce ‘buffer-language’ buffer-local variable
e6acac1d8f8 Implement special sigma casing rule  (bug#24603)
ac7004999db Support casing characters which map into multiple code points  (bug#24603)
ee7a528ac66 Split up casify_region function  (bug#24603)
1f396eb3030 Add support for title-casing letters  (bug#24603)
70eb7142196 Introduce case_character function
792daa7c36b Split casify_object into multiple functions
080a425db51 (up/master) Fix assoc_no_quit so that it does not quit

I’ll try without my patches, i.e. at 080a425db51, but I don’t think
this will change anything.

By the way, if you’re wondering, ff5db06065b can be fetched from
   git fetch https://notabug.org/mina86/emacs.git master

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#26274: 26.0.50; completion regression

[Michal Nazarewicz]

On Thu, Mar 30 2017, Michal Nazarewicz wrote:
> On Thu, Mar 30 2017, Michal Nazarewicz wrote:
> I’ll try without my patches, i.e. at 080a425db51, but I don’t think
> this will change anything.

Scratch that.  I can reproduce the behaviour at HEAD upstream but turns
out it works correctly with my full patchset.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#26274: 26.0.50; completion regression

[Michal Nazarewicz]

Stephen, could you test Emacs at 

	git fetch https://notabug.org/mina86/emacs.git ac7004999db96c7d

Completion behaves correctly at this commit.  Since it’s scheduled to be
pushed soon, I think just rolling forward is the way to go.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#26274: 26.0.50; completion regression

[Stephen Berman]

On Thu, 30 Mar 2017 18:18:42 +0200 Michal Nazarewicz <mina86@mina86.com> wrote:

> Stephen, could you test Emacs at 
>
> 	git fetch https://notabug.org/mina86/emacs.git ac7004999db96c7d
>
> Completion behaves correctly at this commit.  Since it’s scheduled to be
> pushed soon, I think just rolling forward is the way to go.

I invoked the above command on my local master branch, but git said:

fatal: Couldn't find remote ref ac7004999db96c7d

Did I do something wrong?  Do you have a patch I could apply to master?

Steve Berman

bug#26274: 26.0.50; completion regression

[Eli Zaretskii]

> From: Michal Nazarewicz <mina86@mina86.com>
> Cc: npostavs@users.sourceforge.net, 26274@debbugs.gnu.org
> Date: Thu, 30 Mar 2017 18:18:42 +0200
> 
> Stephen, could you test Emacs at 
> 
> 	git fetch https://notabug.org/mina86/emacs.git ac7004999db96c7d
> 
> Completion behaves correctly at this commit.  Since it’s scheduled to be
> pushed soon, I think just rolling forward is the way to go.

That could be so, but if you understand how your previous patches
caused this, it might be important to have the explanation recorded in
this bug report.  It might be that by understanding the problem, we
discover some issues worth being aware of.

Thanks.

bug#26274: 26.0.50; completion regression

[Michal Nazarewicz]

> On Thu, 30 Mar 2017 18:18:42 +0200 Michal Nazarewicz <mina86@mina86.com> wrote:
>> Stephen, could you test Emacs at 
>>
>> 	git fetch https://notabug.org/mina86/emacs.git ac7004999db96c7d
>>
>> Completion behaves correctly at this commit.  Since it’s scheduled to be
>> pushed soon, I think just rolling forward is the way to go.

On Thu, Mar 30 2017, Stephen Berman wrote:
> I invoked the above command on my local master branch, but git said:
>
> fatal: Couldn't find remote ref ac7004999db96c7d

Perhaps it’s not possible to fetch a commit after all.  Try:

	git fetch https://notabug.org/mina86/emacs.git master
        git checkout ac7004999db96c7d

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#26274: 26.0.50; completion regression

[Stephen Berman]

On Thu, 30 Mar 2017 21:11:37 +0200 Michal Nazarewicz <mina86@mina86.com> wrote:

>> On Thu, 30 Mar 2017 18:18:42 +0200 Michal Nazarewicz <mina86@mina86.com> wrote:
>>> Stephen, could you test Emacs at 
>>>
>>> 	git fetch https://notabug.org/mina86/emacs.git ac7004999db96c7d
>>>
>>> Completion behaves correctly at this commit.  Since it’s scheduled to be
>>> pushed soon, I think just rolling forward is the way to go.
>
> On Thu, Mar 30 2017, Stephen Berman wrote:
>> I invoked the above command on my local master branch, but git said:
>>
>> fatal: Couldn't find remote ref ac7004999db96c7d
>
> Perhaps it’s not possible to fetch a commit after all.  Try:
>
> 	git fetch https://notabug.org/mina86/emacs.git master
>         git checkout ac7004999db96c7d

I couldn't tell whether the first command would change my local master
branch, so I decided to make a new branch first:

git fetch https://notabug.org/mina86/emacs.git master:bug26274
git checkout bug26274
git checkout ac7004999db96c7d
make

If I did this right and built the version with your patch, then I can
confirm that with it substring completion with case-folding again works
as expected.

Thanks.

Steve Berman

bug#26274: 26.0.50; completion regression

[Michal Nazarewicz]

I’ve pushed the changes so this should be fixed now.

On Thu, Mar 30 2017, Eli Zaretskii wrote:
>> From: Michal Nazarewicz <mina86@mina86.com>
>> Cc: npostavs@users.sourceforge.net, 26274@debbugs.gnu.org
>> Date: Thu, 30 Mar 2017 18:18:42 +0200
>> 
>> Stephen, could you test Emacs at 
>> 
>> 	git fetch https://notabug.org/mina86/emacs.git ac7004999db96c7d
>> 
>> Completion behaves correctly at this commit.  Since it’s scheduled to be
>> pushed soon, I think just rolling forward is the way to go.
>
> That could be so, but if you understand how your previous patches
> caused this, it might be important to have the explanation recorded in
> this bug report.  It might be that by understanding the problem, we
> discover some issues worth being aware of.

Agreed, and I would love to add tests for this behaviour, but as I was
looking at minibuffer.el, I quickly got lost in all the dynamic
variables.  I’ll try to look at it some more over the weekend, but for
now at least HEAD is working correctly even if we’re not sure why.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

bug#26274: 26.0.50; completion regression

[Stephen Berman]

On Thu, 06 Apr 2017 20:58:57 +0200 Michal Nazarewicz <mina86@mina86.com> wrote:

> I’ve pushed the changes so this should be fixed now.

I just pulled and built from latest master and confirm the completion
problem I reported is gone; thanks!

Steve Berman