[xmonad] Two patches related to XMonad.Prompt

Wed Apr 15 16:57:05 UTC 2015

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>