[xmonad] Changes to XPrompt

[Carlos López Camey]

2012/5/8 Carlos López Camey <c.lopez at kmels.net>:
> 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

Sorry, the reference
[0] http://stackoverflow.com/questions/10497967/given-its-body-functions-create-an-instance-of-a-type-class-or-workaround#comment13570333_10497967