[xmonad] 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

[Peter Jones]

Post by Norbert Zeh
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!

[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

Post by Peter Jones

Post by Norbert Zeh
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Peter Jones]

Post by Norbert Zeh

Post by Peter Jones

Post by Norbert Zeh
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.

[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

Post by Norbert Zeh

Post by Norbert Zeh

Post by Peter Jones

Post by Norbert Zeh
I really got used to using emacs ido mode, which offers a pretty

powerful

Post by Norbert Zeh

Post by Peter Jones

Post by Norbert Zeh
and intuitive fuzzy matching of completions, so I wanted to port the

same

Post by Norbert Zeh

Post by Peter Jones

Post by Norbert Zeh
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

Post by Norbert Zeh
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

Post by Norbert Zeh
intuitive criteria for sorting. In the end, of course, it's all

heuristic

Post by Norbert Zeh
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Brent Yorgey]

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

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

---------- Forwarded message ---------
Date: 12:59pm, Sat, Mar 14, 2015
Subject: [xmonad] Two patches related to XMonad.Prompt
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
(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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[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

Post by Brent Yorgey
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

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

---------- Forwarded message ---------
Date: 12:59pm, Sat, Mar 14, 2015
Subject: [xmonad] Two patches related to XMonad.Prompt
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
(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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

_______________________________________________

xmonad mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[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

Post by 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

Post by Brent Yorgey
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

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

---------- Forwarded message ---------
Date: 12:59pm, Sat, Mar 14, 2015
Subject: [xmonad] Two patches related to XMonad.Prompt
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
(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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

_______________________________________________

xmonad mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

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