GNU bug report logs - #42149
Substring and flex completion ignore implicit trailing ‘any’

Previous Next

Package: emacs;

Reported by: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>

Date: Wed, 1 Jul 2020 10:41:01 UTC

Severity: normal

Tags: fixed, patch

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 42149 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#42149: Substring and flex completion ignore implicit trailing ‘any’
Date: Wed, 14 Oct 2020 11:01:51 +0200
Hi João,

> Sorry for the delay in handling this.

No problem; it’s not a very critical bug after all, just an annoying
one.

> 1. Question: if I compile and/or evaluate the changes to the
> test/lisp/minibuffer-tests.el file but _don't_ compile the changes
> to the lisp/minibuffer.el file, will they expose this bug and this
> bug only?  In other words, will I get exactly the same failures
> that you describe originally in this issue and will that fact be
> apparent in the failure message(s)?

Yes.  As for how apparent they’ll be, well, I guess that’s up to ERT.
You will get something along the lines of

    (ert-test-failed
     ((should
       (eql
	(get-text-property 0 'completion-score
			   (car ...))
	1.0))
      :form
      (eql 0.0 1.0)
      :value nil))

Which says that the ‘completion-score’ was 0 but should have been 1, as
indicated in the bug report.  Of course, some of the tests are more
general tests for the sake of catching regressions.

> 2. Question: are the changes to completion-pcm--optimize-pattern
> an optimization or does the fix above depend on them?  If the
> former, could you make it a separate commit?

Unfortunately, the fix loosely depends on them.  Without them, having
multiple consecutive “*” would mess up the PCM scoring.

> 3. Nitpick: the commit message is broadly according to the
> format, but I find it hard to parse its intentions. Though
> conventions vary, I usually like to format the commit message
> like in this example which separates the what, the why and
> the how.

Thanks for both the remark and the useful example.  I will fix it and
come back with a new patch.

Best regards,
Dario

-- 
dario.gjorgjevski <at> gmail.com :: +49 1525 8666837
%   gpg --keyserver 'hkps://hkps.pool.sks-keyservers.net' \
\`>     --recv-keys '744A4F0B4F1C9371'




This bug report was last modified 4 years and 7 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.