[xmonad] Changes to XPrompt

[Carlos López Camey]

2012/5/7 Carlos López Camey <c.lopez at kmels.net>:
> 2012/5/6  <wagnerdm at seas.upenn.edu>:
>> Hello Carlos!
>>
>>
>> Quoting Carlos López Camey <c.lopez at kmels.net>:
>>
>>> The changes would be:
>>>    * Autocomplete based on several modes (there is always a mode set)
>>>          The autocomplete items are generally path to files, mode 1
>>> could use for example `locate %s`, mode 2 `recollq` [0] (searches for
>>> tokens inside files) and mode 3 `locate --regexp %s` to autocomplete.
>>
>>
>> mkXPrompt already seems to allow you to specify an IO action to run to
>> create your list of completions. That IO action can itself do any of the
>> things you name, so I don't think you should need to make any changes to
>> realize this wish.
>>
>>
>>>    * one-column-only list of autocompletions
>>>           For the purpose, they are always paths, so they are quite
>>> large to keep it in different columns. But this be a setting on the
>>> configuration.
>>>
>>>    * Navigating through completion items and changing autocompletion
>>> list on "real time"
>>>             There is always an item highlighted (if items > 0)
>>>             The highlighted item not necesarilly is equal to the
>>> prompt buffer text. I may write "xmonad.hs" but the autocomplete item
>>> shows a full path highlighted. This implies adding an additional field to
>>> XPState, complIndex :: Int, that knows which item to highlight next (not
>>> based on the buffer's text)
>>
>>
>> I'm not an XPrompt user, so I can't comment on whether these are possible or
>> not right now, but if not, they sound like nice things to add.
>>
>>
>>>    * Action is not necesarilly a String -> X a.
>>>
>>>       I'd like to count on a Map Extension (String -> String) in some
>>> config, where type Extension = String. This map would describe what to
>>> do with each file depending on its extension. e.g. an element of the
>>> map could be (".org",\path -> "emacs "++path). So I'm not sure how the
>>> new signature would be: String -> X a? but this String would be the
>>> command sent to spawn, computed using a function that uses the map
>>> described above.
>>
>>
>> You may accomplish this by having your String -> X a function close over the
>> Map you want to query; for example, something like this:
>>
>> fConstantMap :: String -> X a
>> fConstantMap s = case lookup constMap (extension s) of
>>    Nothing -> spawn s
>>    Just modifier -> spawn (modifier s)
>>    where
>>    extension = reverse . take 4 . reverse
>>    constMap = fromList [
>>        (".org", \path -> "emacs " ++ path),
>>        (".doc", \path -> "libreoffice " ++ path)
>>        ]
>>
>> or, if the Map is going to be built dynamically rather than known at compile
>> time, you can have the map be an argument to the function and pass the
>> function partially-applied to mkXPrompt[WithReturn].
>>
>> Good luck, and I hope this helps with half your requests!
>> ~d
>>
>

Greetings again, I forgot to copy the list earlier!

> Hello, thanks for the help! After reading your comments, I think it is
> possible to make the changes to XPrompt. Modifications to XPrompt,
> XPState and XPConfig shouldn't have to break configs (default settings
> would have to be added to defaultXPConfig, as well as default
> definitions for possible new functions on XPrompt).
>
> Back to it then.
> Carlos

I've coded a bit more, and I think that if different modes are to be
added *and* backwards _api compatibility_ is to be kept, it is
necessary to include either Data.Typeable or Data.Proxy according to
[0]. Correct me if I'm wrong but we can't reify *any* function with
Typeable? With Data.Proxy it is possible but xmonad-contrib would need
package `tagged` as a dependency.

There is a way to keep backwards compatibility to xmonad.hs files but
not to modules that use XPrompt. They (XMonad/Prompt/*.hs and
XMonad/Actions/Search.hs) must include an instance of XPMode and
provide it to mkPrompt, instead of both the explicit completion and
action functions, i.e. replace

mkXPrompt t conf compl action

with

mkXPrompt t conf myMode
   where myMode = XPMode {
     complFunction = ..
     action = ..
   }

Would that be ok? I don't think many xmonad.hs use mkXPrompt directly.

Carlos