Elv13 prompt hook v2 #483
Elv13 prompt hook v2 #483
Conversation
|
Fine by me |
|
+1 So, I guess you want to rebase this one first? |
blueyed
force-pushed
the
Elv13-prompt_hook_v2
branch
from
ff5d9fa
to
78c00b6
Compare
|
Rebased. Let's see if it still passes.. ;) |
|
@Elv13 mentioned that this would be (would have a potential for) a nice addition to the default config, but that could be done in a new PR. |
|
Rebased and seems to be fine - but #489 should go in first. |
|
While I think about it, another PR should also add an API to add new default hooks for the prompt. This could be used to implement VI style prompt shortcuts by adding escape. For this, layered keygrabbers would also need to be properly supported, but this is just an example (EMACS mode could be implemented (well, extended given /me also wonder is generic hooks for modified text could be added to implement syntax highlight, but this is just dreaming and would required substantial changes to decouple the prompt text and the displayed one |
|
@Elv13 I'm currently doing a big library, which will have (with a lot of other features) layered grabbers and dynamic keymap, for every possible use, from tag management to prompt editText with vim style keybinds.. This is in WIP, and doesn't work ATM, but it will ;) Maybe when finished (in a long time..) I will make a separate library with only key* stuff. For those who doesn't want the full lib. |
|
@Bew78LesellB Well, I guess the issues with layered grabbers should be treated as bugs in Awesome and fixed internally rather than adding an abstraction layer on top the the current API (the internal one should handle it) |
|
@Elv13 yeah this is another way to think the issue, but I still didn't progress in the study of Awesome's C code, so I'm currently making what I'm good at.. (love lua now!) |
|
@Bew78LesellB I think it would be a great opportunity for you to address this where it's meant to be fixed. Whenever you work around something, just consider fixing it in the core.. :) |
|
@blueyed Oh I never thought of that ! The thing is that I added some concept in my lib, on top of the lua api (well, in fact, on top of the capi, I'm rewriting a lua api..), and I think everything with theses concepts.. As they are kind of specific to me, I'm not sure it's a good idea to add them in the core of awesome.. |
blueyed
force-pushed
the
Elv13-prompt_hook_v2
branch
from
78c00b6
to
58f40d6
Compare
|
Rebased on master (fixing a conflict), added some doc, moving to "next" milestone. |
|
I've also made the hook's return value handling a bit smarter in blueyed@7925e6a. Does that make sense? |
|
Uhm. Your latest commit looks fine to me (thanks!) and the rest was already decided to be good before, right? So I guess everything is good (sorry, I don't really want to look too deeply into the prompt code.) |
|
blueyed@7925e6a is also new. |
|
I trust you on that one. :-) |
|
+1 |
Example:
awful.prompt.run({ prompt = "Run: ", hooks = {
{{ },"Return",function(command)
local result = awful.util.spawn(command)
mypromptbox[mouse.screen].widget:set_text(type(result) == "string" and result or "")
return true
end},
{{"Mod1" },"Return",function(command)
local result = awful.util.spawn(command,{sticky=true})
mypromptbox[mouse.screen].widget:set_text(type(result) == "string" and result or "")
return true
end},
{{"Shift" },"Return",function(command)
local result = awful.util.spawn(command,{ontop=true,floating=true})
mypromptbox[mouse.screen].widget:set_text(type(result) == "string" and result or "")
return true
end}
}
},...)
This is meant to avoid boilerplate code when creating prompt hooks.
blueyed
force-pushed
the
Elv13-prompt_hook_v2
branch
from
4ecf204
to
ba0d8e3
Compare
Continuation of #52, assumes #34 to be merged.
/cc @Elv13