Two patches related to XMonad.Prompt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Two patches related to XMonad.Prompt

Norbert Zeh
Hi folks,

I really got used to using emacs ido mode, which offers a pretty powerful
and intuitive fuzzy matching of completions, so I wanted to port the same
to XMonad.Prompt.  This required two patches, included in the attached
patch bundles:

(1)  Completions should be sortable by how well they match the current
query string.  This turned out to be a very easy addition of a 'sorter'
function to XPConfig, which is parameterized by the current query string.
The default is 'const id', that is, no sorting is done, which is exactly
the old behaviour of XMonad.Prompt.

(2)  A new module XMonad.Prompt.FuzzyMatch that implements the fuzzy
matching.  The exact rules for matching and sorting of matches are
explained in its documentation.

As usual, let me know if anything needs to straightened out before these
patches can be applied.

Cheers,
Norbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20150314/ea4e3fe0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xprompt-fuzzymatch.patch
Type: text/x-patch
Size: 58359 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20150314/ea4e3fe0/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xprompt-sorting.patch
Type: text/x-patch
Size: 54662 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20150314/ea4e3fe0/attachment-0003.bin>

Reply | Threaded
Open this post in threaded view
|

Two patches related to XMonad.Prompt

Peter Jones
Norbert Zeh <nzeh at cs.dal.ca> writes:
> I really got used to using emacs ido mode, which offers a pretty powerful
> and intuitive fuzzy matching of completions, so I wanted to port the same
> to XMonad.Prompt.

I've wanted this for a long time, can't wait to try it out.  Thanks!

--
Peter Jones, Founder, Devalot.com
Defending the honor of good code


Reply | Threaded
Open this post in threaded view
|

Two patches related to XMonad.Prompt

Norbert Zeh
Excellent.  Once you get to try it out, any feedback on how to improve the
sorting, if any, would be appreciated.  It took me some tries to come up
with the current version, which I am pretty happy with as far as matching
my sorting expectations goes, but that doesn't mean that there aren't more
intuitive criteria for sorting.  In the end, of course, it's all heuristic
anyway.

Cheers,
Norbert

On Mon, Mar 16, 2015 at 11:59 AM Peter Jones <mlists at pmade.com> wrote:

> Norbert Zeh <nzeh at cs.dal.ca> writes:
> > I really got used to using emacs ido mode, which offers a pretty powerful
> > and intuitive fuzzy matching of completions, so I wanted to port the same
> > to XMonad.Prompt.
>
> I've wanted this for a long time, can't wait to try it out.  Thanks!
>
> --
> Peter Jones, Founder, Devalot.com
> Defending the honor of good code
>
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20150316/3ce52f01/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Two patches related to XMonad.Prompt

Brent Yorgey
In reply to this post by Norbert Zeh
OK, I've made some progress figuring out what is going on.  In short: the
searchPredicate field is never used in XMonad.Prompt!  The only place the
searchPredicate is used is in XMonad.Prompt.Window, in the definition of
the doPrompt function.  So this will work if you happen to be using a
prompt to pick a window, but not for any other sort of prompt.

This actually seems like a bug in XMonad.Prompt.  At some point someone
added a searchPredicate field to the XPConfig, but forgot to actually use
it to filter completion results.

Norbert, is this something you could look into?  I've looked through
XMonad.Prompt briefly but not sure where the right place is for this to
go.  I'll probably get around to it eventually if no one else does.

-Brent

On Fri, Apr 3, 2015 at 6:08 PM Brent Yorgey <byorgey at gmail.com> wrote:

> Hmm, I tried it out but can't seem to get it to work.  Mysterious.  The
> patches are definitely applied, my xmonad.hs includes definitions for
> sorter and searchPredicate, it compiles cleanly, but when I open a prompt
> it has the same behavior as before.
>
> I'll try to spend some more time tracking down what is going on but just
> wanted to briefly report.
>
> -Brent
>
> On Mon, Mar 23, 2015 at 2:39 PM Brent Yorgey <byorgey at gmail.com> wrote:
>
>>
>>
>> ---------- Forwarded message ---------
>> From: Norbert Zeh <nzeh at cs.dal.ca>
>> Date: 12:59pm, Sat, Mar 14, 2015
>> Subject: [xmonad] Two patches related to XMonad.Prompt
>> To: xmonad at haskell.org <xmonad at haskell.org>
>>
>>
>> Hi folks,
>>
>> I really got used to using emacs ido mode, which offers a pretty powerful
>> and intuitive fuzzy matching of completions, so I wanted to port the same
>> to XMonad.Prompt.  This required two patches, included in the attached
>> patch bundles:
>>
>> (1)  Completions should be sortable by how well they match the current
>> query string.  This turned out to be a very easy addition of a 'sorter'
>> function to XPConfig, which is parameterized by the current query string.
>> The default is 'const id', that is, no sorting is done, which is exactly
>> the old behaviour of XMonad.Prompt.
>>
>> (2)  A new module XMonad.Prompt.FuzzyMatch that implements the fuzzy
>> matching.  The exact rules for matching and sorting of matches are
>> explained in its documentation.
>>
>> As usual, let me know if anything needs to straightened out before these
>> patches can be applied.
>>
>> Cheers,
>> Norbert
>> _______________________________________________
>> xmonad mailing list
>> xmonad at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20150415/93909237/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Two patches related to XMonad.Prompt

Norbert Zeh
I also noticed that some prompts don't use the searchPredicate.  In my
setup, I'm using the fuzzy matching for matching windows, Thunar bookmarks,
and xrandr settings.  The first of course already uses searchPredicate and
the latter two are custom prompts in my xmonad.hs that I wrote to use
searchPredicate.

X.P.Shell is a particular example that does not use searchPredicate, if I
recall correctly.  All specific instantiations of X.Prompt essentially
decide individually how to define the completion function passed to
mkXPrompt.  I think most existing prompts can be rewritten to use
searchPredicate, but this of course doesn't prevent anybody from writing
new prompt instances that don't use it.  One (bad) possibility to prevent
this would be to change mkXPrompt so that the "completion function" it
accepts is not actually a completion function that depends on the search
string but simply a function that generates all candidates to be filtered
using searchPredicate.  That's a bad idea, though, because (a) it breaks
the current API and thus any setup that includes custom prompts like mine
and (b) it is possible that there are cases where generating all possible
candidates and then filtering matches is impossible or prohibitively
expensive while generating candidate completions based on the current query
string is possible and efficient (e.g., a prompt to list the top 10 matches
of a Google search).

Cheers,
Norbert

On Wed, Apr 15, 2015 at 10:18 AM Brent Yorgey <byorgey at gmail.com> wrote:

> OK, I've made some progress figuring out what is going on.  In short: the
> searchPredicate field is never used in XMonad.Prompt!  The only place the
> searchPredicate is used is in XMonad.Prompt.Window, in the definition of
> the doPrompt function.  So this will work if you happen to be using a
> prompt to pick a window, but not for any other sort of prompt.
>
> This actually seems like a bug in XMonad.Prompt.  At some point someone
> added a searchPredicate field to the XPConfig, but forgot to actually use
> it to filter completion results.
>
> Norbert, is this something you could look into?  I've looked through
> XMonad.Prompt briefly but not sure where the right place is for this to
> go.  I'll probably get around to it eventually if no one else does.
>
> -Brent
>
> On Fri, Apr 3, 2015 at 6:08 PM Brent Yorgey <byorgey at gmail.com> wrote:
>
>> Hmm, I tried it out but can't seem to get it to work.  Mysterious.  The
>> patches are definitely applied, my xmonad.hs includes definitions for
>> sorter and searchPredicate, it compiles cleanly, but when I open a prompt
>> it has the same behavior as before.
>>
>> I'll try to spend some more time tracking down what is going on but just
>> wanted to briefly report.
>>
>> -Brent
>>
>> On Mon, Mar 23, 2015 at 2:39 PM Brent Yorgey <byorgey at gmail.com> wrote:
>>
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: Norbert Zeh <nzeh at cs.dal.ca>
>>> Date: 12:59pm, Sat, Mar 14, 2015
>>> Subject: [xmonad] Two patches related to XMonad.Prompt
>>> To: xmonad at haskell.org <xmonad at haskell.org>
>>>
>>>
>>> Hi folks,
>>>
>>> I really got used to using emacs ido mode, which offers a pretty
>>> powerful and intuitive fuzzy matching of completions, so I wanted to port
>>> the same to XMonad.Prompt.  This required two patches, included in the
>>> attached patch bundles:
>>>
>>> (1)  Completions should be sortable by how well they match the current
>>> query string.  This turned out to be a very easy addition of a 'sorter'
>>> function to XPConfig, which is parameterized by the current query string.
>>> The default is 'const id', that is, no sorting is done, which is exactly
>>> the old behaviour of XMonad.Prompt.
>>>
>>> (2)  A new module XMonad.Prompt.FuzzyMatch that implements the fuzzy
>>> matching.  The exact rules for matching and sorting of matches are
>>> explained in its documentation.
>>>
>>> As usual, let me know if anything needs to straightened out before these
>>> patches can be applied.
>>>
>>> Cheers,
>>> Norbert
>>>
>> _______________________________________________
>>> xmonad mailing list
>>> xmonad at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>>>
>> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20150415/3c4915f6/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Two patches related to XMonad.Prompt

Brent Yorgey
Ah, I see.  In that case I am not sure what a good solution is.  It is not
just that "some prompts don't use the searchPredicate". In fact,
XMonad.Prompt.Window is the *only* prompt that uses it!  (based on grepping
the entire source tree of xmonad-contrib.)

I do understand your points about not running searchPredicate on the output
of the completion function.  So I wonder if we should add searchPredicate
to some of the other existing prompts in xmonad-contrib.  For example, it
seems strange that XMonad.Prompt.Window uses it but XMonad.Prompt.Workspace
does not.  But no matter what this seems like an unfortunate situation; it
seems to me there is no way to prevent users from being surprised when they
set their searchPredicate and some prompts are affected but others are
not.  At the very least we would want to add some prominent warnings to the
documentation of searchPredicate and XMonad.Prompt.FuzzyMatch.

-Brent

On Wed, Apr 15, 2015 at 9:46 AM Norbert Zeh <nzeh at cs.dal.ca> wrote:

> I also noticed that some prompts don't use the searchPredicate.  In my
> setup, I'm using the fuzzy matching for matching windows, Thunar bookmarks,
> and xrandr settings.  The first of course already uses searchPredicate and
> the latter two are custom prompts in my xmonad.hs that I wrote to use
> searchPredicate.
>
> X.P.Shell is a particular example that does not use searchPredicate, if I
> recall correctly.  All specific instantiations of X.Prompt essentially
> decide individually how to define the completion function passed to
> mkXPrompt.  I think most existing prompts can be rewritten to use
> searchPredicate, but this of course doesn't prevent anybody from writing
> new prompt instances that don't use it.  One (bad) possibility to prevent
> this would be to change mkXPrompt so that the "completion function" it
> accepts is not actually a completion function that depends on the search
> string but simply a function that generates all candidates to be filtered
> using searchPredicate.  That's a bad idea, though, because (a) it breaks
> the current API and thus any setup that includes custom prompts like mine
> and (b) it is possible that there are cases where generating all possible
> candidates and then filtering matches is impossible or prohibitively
> expensive while generating candidate completions based on the current query
> string is possible and efficient (e.g., a prompt to list the top 10 matches
> of a Google search).
>
> Cheers,
> Norbert
>
>
> On Wed, Apr 15, 2015 at 10:18 AM Brent Yorgey <byorgey at gmail.com> wrote:
>
>> OK, I've made some progress figuring out what is going on.  In short: the
>> searchPredicate field is never used in XMonad.Prompt!  The only place the
>> searchPredicate is used is in XMonad.Prompt.Window, in the definition of
>> the doPrompt function.  So this will work if you happen to be using a
>> prompt to pick a window, but not for any other sort of prompt.
>>
>> This actually seems like a bug in XMonad.Prompt.  At some point someone
>> added a searchPredicate field to the XPConfig, but forgot to actually use
>> it to filter completion results.
>>
>> Norbert, is this something you could look into?  I've looked through
>> XMonad.Prompt briefly but not sure where the right place is for this to
>> go.  I'll probably get around to it eventually if no one else does.
>>
>> -Brent
>>
>> On Fri, Apr 3, 2015 at 6:08 PM Brent Yorgey <byorgey at gmail.com> wrote:
>>
>>> Hmm, I tried it out but can't seem to get it to work.  Mysterious.  The
>>> patches are definitely applied, my xmonad.hs includes definitions for
>>> sorter and searchPredicate, it compiles cleanly, but when I open a prompt
>>> it has the same behavior as before.
>>>
>>> I'll try to spend some more time tracking down what is going on but just
>>> wanted to briefly report.
>>>
>>> -Brent
>>>
>>> On Mon, Mar 23, 2015 at 2:39 PM Brent Yorgey <byorgey at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: Norbert Zeh <nzeh at cs.dal.ca>
>>>> Date: 12:59pm, Sat, Mar 14, 2015
>>>> Subject: [xmonad] Two patches related to XMonad.Prompt
>>>> To: xmonad at haskell.org <xmonad at haskell.org>
>>>>
>>>>
>>>> Hi folks,
>>>>
>>>> I really got used to using emacs ido mode, which offers a pretty
>>>> powerful and intuitive fuzzy matching of completions, so I wanted to port
>>>> the same to XMonad.Prompt.  This required two patches, included in the
>>>> attached patch bundles:
>>>>
>>>> (1)  Completions should be sortable by how well they match the current
>>>> query string.  This turned out to be a very easy addition of a 'sorter'
>>>> function to XPConfig, which is parameterized by the current query string.
>>>> The default is 'const id', that is, no sorting is done, which is exactly
>>>> the old behaviour of XMonad.Prompt.
>>>>
>>>> (2)  A new module XMonad.Prompt.FuzzyMatch that implements the fuzzy
>>>> matching.  The exact rules for matching and sorting of matches are
>>>> explained in its documentation.
>>>>
>>>> As usual, let me know if anything needs to straightened out before
>>>> these patches can be applied.
>>>>
>>>> Cheers,
>>>> Norbert
>>>>
>>> _______________________________________________
>>>> xmonad mailing list
>>>> xmonad at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>>>>
>>> _______________________________________________
>> xmonad mailing list
>> xmonad at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>>
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20150415/9df85217/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Re: Two patches related to XMonad.Prompt

Peter Jones
In reply to this post by Norbert Zeh
Norbert Zeh <[hidden email]> writes:

> On Mon, Mar 16, 2015 at 11:59 AM Peter Jones wrote:
>
>> Norbert Zeh <[hidden email]> writes:
>> > I really got used to using emacs ido mode, which offers a pretty powerful
>> > and intuitive fuzzy matching of completions, so I wanted to port the same
>> > to XMonad.Prompt.
>>
>> I've wanted this for a long time, can't wait to try it out.  Thanks!
> Excellent.  Once you get to try it out, any feedback on how to improve the
> sorting, if any, would be appreciated.  It took me some tries to come up
> with the current version, which I am pretty happy with as far as matching
> my sorting expectations goes, but that doesn't mean that there aren't more
> intuitive criteria for sorting.  In the end, of course, it's all heuristic
> anyway.

I've been playing with your fuzzy matching for about a week now.  I
really, really like it.

The only issue I have is that I can't seem to get tab completion to
work.  For simple prompts I can just press enter once the item I want is
selected.  But for more complicated menus, such as the shell menu, I
want to be able to press tab and have the current item expanded so I can
start entering arguments.  This doesn't seem to work.

I've also noticed that if I have fuzzy matching turned on in the shell
prompt and start to complete a file path it crashes the prompt and I
have to restart xmonad to remove the X window that the prompt created.

--
Peter Jones, Founder, Devalot.com
Defending the honor of good code

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Two patches related to XMonad.Prompt

Norbert Zeh
Hi Peter,

Sorry for not replying in a timely manner.  My summer has been insanely busy.  Unfortunately, I cannot offer any particularly helpful comment at this point either.  The problems you describe are proof that proper testing would go a long way - my bad.  I'll try to find the time to look at this in the coming weeks to see what can be done to fix this.  Having said this, I personally don't use FuzzyMatch in the Shell prompt; for commands, standard prefix filtering seems to be more effective.  Still, you should of course be able to use it if you want it.

Cheers,
Norbert

On Tue, Jul 14, 2015 at 1:09 PM, Peter Jones <[hidden email]> wrote:
Norbert Zeh <[hidden email]> writes:
> On Mon, Mar 16, 2015 at 11:59 AM Peter Jones wrote:
>
>> Norbert Zeh <[hidden email]> writes:
>> > I really got used to using emacs ido mode, which offers a pretty powerful
>> > and intuitive fuzzy matching of completions, so I wanted to port the same
>> > to XMonad.Prompt.
>>
>> I've wanted this for a long time, can't wait to try it out.  Thanks!
> Excellent.  Once you get to try it out, any feedback on how to improve the
> sorting, if any, would be appreciated.  It took me some tries to come up
> with the current version, which I am pretty happy with as far as matching
> my sorting expectations goes, but that doesn't mean that there aren't more
> intuitive criteria for sorting.  In the end, of course, it's all heuristic
> anyway.

I've been playing with your fuzzy matching for about a week now.  I
really, really like it.

The only issue I have is that I can't seem to get tab completion to
work.  For simple prompts I can just press enter once the item I want is
selected.  But for more complicated menus, such as the shell menu, I
want to be able to press tab and have the current item expanded so I can
start entering arguments.  This doesn't seem to work.

I've also noticed that if I have fuzzy matching turned on in the shell
prompt and start to complete a file path it crashes the prompt and I
have to restart xmonad to remove the X window that the prompt created.

--
Peter Jones, Founder, Devalot.com
Defending the honor of good code

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad


_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad