Changes to XPrompt
Hello xmonaders, I started to code something upon XPrompt, but I noticed that what I would like the code to do, needs some changes in XPrompt, which I'm not sure should go into XPrompt, or into a new type of Prompt (not related to XPrompt). This question sometimes makes me doubt when changing XPrompt.hs, so I thought I would ask and decide where to do it. 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. * 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) * 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. I know this is a long list of features, but I hope it to be materialized eventually. My questions would be then, is it right to do a new XPrompt? it's hard not to think on changes braking current xmonad.hs configurations. In case a new Prompt is needed, name it LauncherPrompt, does it belong to xmonad-contrib? Creating a new Prompt would imply having different config types (XPConfig and LauncherPromptConfig), and very similar actions on both each prompt module.. for example killBefore :: XP() and killBefore :: LauncherP (). That's not acceptable IMHO. I appreciate your comments, [0] http://www.lesbonscomptes.com/recoll/
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
participants (2)
-
Carlos López Camey -
wagnerdm＠seas.upenn.edu