Re: [elpa] master 9f21e1d 06/18: Add a matching optimization

Re: [elpa] master 9f21e1d 06/18: Add a matching optimization

[Stefan Monnier]

>     * ivy.el (ivy-completions): When the new regex `re' is a contains the
>       old regex `ivy--old-re', it must be true that all candidates that
>       match `re' are contained inside all candidates that match

IIUC ivy-mode treats the minibuffer's content as a regexp, so the user
can write any fancy regexp she wants.  In that case, the above is
actually not guaranteed.  E.g.  "foo" matches fewer candidates than
"foo?".

> +                      ((and ivy--old-re (eq 0 (cl-search ivy--old-re re)))

Why not use string-prefix-p?


        Stefan

Re: [elpa] master 9f21e1d 06/18: Add a matching optimization

[Oleh Krehel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     * ivy.el (ivy-completions): When the new regex `re' is a contains the
>>       old regex `ivy--old-re', it must be true that all candidates that
>>       match `re' are contained inside all candidates that match
>
> IIUC ivy-mode treats the minibuffer's content as a regexp, so the user
> can write any fancy regexp she wants.  In that case, the above is
> actually not guaranteed.  E.g.  "foo" matches fewer candidates than
> "foo?".

True, it's an optimization for the most basic use of space separated
words. But I was playing around with filtering the 3000000 lines git
grep in the emacs repo, and I wanted to see if it would be faster with
the optimization.

I'll either add a custom var to turn this optimization on/off or try to
check if the input is just space-separated words.

>> +                      ((and ivy--old-re (eq 0 (cl-search ivy--old-re re)))
>
> Why not use string-prefix-p?

Because I didn't know about it. I'll switch.

Oleh

Re: [elpa] master 9f21e1d 06/18: Add a matching optimization

[Artur Malabarba]

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

> >> +                      ((and ivy--old-re (eq 0 (cl-search ivy--old-re
re)))
> >
> > Why not use string-prefix-p?
>
> Because I didn't know about it. I'll switch.

Is it on 24.1? (can't check right now)

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

Re: [elpa] master 9f21e1d 06/18: Add a matching optimization

[Oleh Krehel]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> >> + ((and ivy--old-re (eq 0 (cl-search ivy--old-re re)))
>> >
>> > Why not use string-prefix-p?
>>
>> Because I didn't know about it. I'll switch.
>
> Is it on 24.1? (can't check right now)

Thanks to the new and improved `counsel-git-grep' I found this in the Changelog:

> ** New function `string-prefix-p'.
> (This was actually added in Emacs 23.2 but was not advertised at the time.)

Could someone help me with this issue: when I combine `while-no-input'
and `shell-command-to-string` I get annoying "Waiting for process to
die...done" messages interrupting by minibuffer?

Oleh

Re: [elpa] master a94ca83 01/18: swiper.el: Add a work-around for window-start not being current

[Stefan Monnier]

>     An alternative would be to use `redisplay' to update `window-start' and
>     `window-end', but that causes excessive blinking.

Yes, this sucks.  Currently, I think the best mechanism in Emacs to
perform such highlighting is fontification-functions, but that is used
by jit-lock.  So you could use jit-lock-register, but it would cause
re-font-locking the (visible part of) the buffer, which also sucks.

jit-lock should ideally be extended to better deal with "multiple
clients" so that it is able to understand that some parts of the buffer
have already been handled by some clients (currently, it's all or
nothing: either jit-lock thinks that a part of the buffer has been
handled by all clients, or it thinks that it's been handled by none).


        Stefan

Re: [elpa] master a94ca83 01/18: swiper.el: Add a work-around for window-start not being current

[Oleh Krehel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     An alternative would be to use `redisplay' to update `window-start' and
>>     `window-end', but that causes excessive blinking.
>
> Yes, this sucks.  Currently, I think the best mechanism in Emacs to
> perform such highlighting is fontification-functions, but that is used
> by jit-lock.  So you could use jit-lock-register, but it would cause
> re-font-locking the (visible part of) the buffer, which also sucks.
>
> jit-lock should ideally be extended to better deal with "multiple
> clients" so that it is able to understand that some parts of the buffer
> have already been handled by some clients (currently, it's all or
> nothing: either jit-lock thinks that a part of the buffer has been
> handled by all clients, or it thinks that it's been handled by none).

It's not a big deal for swiper: in this case, just double the window
height gets overlays, instead of single window height.
The advantage is that I don't have to deal with callbacks and sequencing.

Oleh

Re: [elpa] master a94ca83 01/18: swiper.el: Add a work-around for window-start not being current

[Stefan Monnier]

> It's not a big deal for swiper: in this case, just double the window
> height gets overlays, instead of single window height.

That assumes that the displayed text lines have indeed the
expected height.  If you play with images, change the size of some
fonts, play with text-scale-adjust, or with invisible text, you may bump
into corner cases where you code will get it wrong.  Or if the scroll
goes much further for some reason.


        Stefan