Re: [xmonad] Changes to XPrompt

8 May 2012

      2012/5/7 Carlos López Camey :
...
2012/5/6  :
...
Hello Carlos!
Quoting Carlos López Camey :
...
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