* [rfc + bad patch] Allow to get the current cursor command from zle, for doing a nicer run-help.
@ 2008-10-05 13:40 Mikael Magnusson
2008-10-05 19:08 ` Bart Schaefer
0 siblings, 1 reply; 3+ messages in thread
From: Mikael Magnusson @ 2008-10-05 13:40 UTC (permalink / raw)
To: zsh-workers
(the patch will be badly linebroken likely, but it's just for illustration).
Let's say you have the command line
git add -u; git commit - # hmm, was it -m or -M for message? *press alt-h*
Now, also assume you have the run-help-git stuff set up, but it will still
show you the manpage for git-add instead of git-commit. Since the run-help
widget does a push-line, we can't use $CURSOR to find out which is the actual
command, this is how i solved it.
function _runhelp() {
local lookup
if [[ "$CURSORCOMMAND" = git ]]; then
# tiny bug here, want CURSOR+1 so you get the right result when on the
# first letter, but then it breaks when at the end of the line which is
# the far more common case.
lookup=git-${${(z)BUFFER[(b:CURSOR:R)$CURSORCOMMAND,-1]}[2]}
else
lookup=$CURSORCOMMAND
fi
_runcmdhidden man $lookup
}
function _runcmdhidden() {
"$@" >& /dev/null < /dev/null &|
}
function man () { urxvt +sb +ip -e pinfo -m "$@" &|: }
(this can of course be made to do a push-line manually and open in man in
the same terminal as usual, but I like the new window.)
diff --git a/Src/Zle/zle_params.c b/Src/Zle/zle_params.c
index efa6286..ae5271a 100644
--- a/Src/Zle/zle_params.c
+++ b/Src/Zle/zle_params.c
@@ -48,6 +48,8 @@ static const struct gsu_scalar buffer_gsu =
{ get_buffer, set_buffer, zleunsetfn };
static const struct gsu_scalar context_gsu =
{ get_context, nullstrsetfn, zleunsetfn };
+static const struct gsu_scalar cursor_command_gsu =
+{ getcurcmd, nullstrsetfn, zleunsetfn };
static const struct gsu_scalar cutbuffer_gsu =
{ get_cutbuffer, set_cutbuffer, unset_cutbuffer };
static const struct gsu_scalar keymap_gsu =
@@ -106,6 +108,7 @@ static struct zleparam {
{ "BUFFER", PM_SCALAR, GSU(buffer_gsu), NULL },
{ "BUFFERLINES", PM_INTEGER | PM_READONLY, GSU(bufferlines_gsu),
NULL },
+ { "CURSORCOMMAND", PM_SCALAR | PM_READONLY,
GSU(cursor_command_gsu), NULL },
{ "CONTEXT", PM_SCALAR | PM_READONLY, GSU(context_gsu),
NULL },
{ "CURSOR", PM_INTEGER, GSU(cursor_gsu),
diff --git a/Src/Zle/zle_tricky.c b/Src/Zle/zle_tricky.c
index bc01524..6c57842 100644
--- a/Src/Zle/zle_tricky.c
+++ b/Src/Zle/zle_tricky.c
@@ -2757,7 +2757,7 @@ expandhistory(UNUSED(char **args))
static int cmdwb, cmdwe;
/**/
-static char *
+char *
getcurcmd(void)
{
int curlincmd;
--
Mikael Magnusson
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [rfc + bad patch] Allow to get the current cursor command from zle, for doing a nicer run-help.
2008-10-05 13:40 [rfc + bad patch] Allow to get the current cursor command from zle, for doing a nicer run-help Mikael Magnusson
@ 2008-10-05 19:08 ` Bart Schaefer
2008-10-05 20:38 ` Mikael Magnusson
0 siblings, 1 reply; 3+ messages in thread
From: Bart Schaefer @ 2008-10-05 19:08 UTC (permalink / raw)
To: zsh-workers
On Oct 5, 3:40pm, Mikael Magnusson wrote:
}
} Let's say you have the command line
} git add -u; git commit - # hmm, was it -m or -M for message? *press alt-h*
} Now, also assume you have the run-help-git stuff set up, but it will still
} show you the manpage for git-add instead of git-commit.
This points out a more generalized bug in Functions/Misc/run-help as it
currently is implemented. If you have, for example
zsh% run-help-less() { print $* }
zsh% print this is not less but the next is; less /etc/termcap
If you now hit ESC-h to invoke run-help, you get:
but the next is
and then the command "less /etc/termcap" is *executed*. The "eval" in
Functions/Misc/run-help needs a (q) parameter expansion flag added, at
the very least.
} Since the run-help widget does a push-line, we can't use $CURSOR to
} find out which is the actual command, this is how i solved it.
It should be possible to solve this without resorting to hacking the C
source. All you need is a user-defined ZLE widget that runs as a wrapper
around the run-help widget to save the value of CURSOR. E.g.:
run_help_cursor () {
typeset -g HELPCURSOR=$CURSOR
zle .run-help "$@"
}
zle -N run-help run_help_cursor
Except that you're using CURSOR in your _runhelp function, so it must
already be a widget? You didn't show a usage example.
It might be nice if the .run-help widget saved the cursor position itself,
or behaved more like a completion widget and passed an array containing
only the command words "around" the cursor, stripping from separators on
either side. *That* would require C hacking.
In any case I think your function will still do the wrong thing for
something like "git commit git", though that's admittedly not a very
likely scenario.
--- run-help 13 Mar 2008 15:46:07 -0000 1.4
+++ run-help 5 Oct 2008 18:05:54 -0000
@@ -100,7 +100,7 @@
do
shift cmd_args
done
- eval "run-help-$1:t ${(@)cmd_args[2,-1]}"
+ eval "run-help-$1:t ${(q@)cmd_args[2,-1]}"
else
man $@:t
fi
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [rfc + bad patch] Allow to get the current cursor command from zle, for doing a nicer run-help.
2008-10-05 19:08 ` Bart Schaefer
@ 2008-10-05 20:38 ` Mikael Magnusson
0 siblings, 0 replies; 3+ messages in thread
From: Mikael Magnusson @ 2008-10-05 20:38 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
2008/10/5 Bart Schaefer <schaefer@brasslantern.com>:
> On Oct 5, 3:40pm, Mikael Magnusson wrote:
> }
> } Let's say you have the command line
> } git add -u; git commit - # hmm, was it -m or -M for message? *press alt-h*
> } Now, also assume you have the run-help-git stuff set up, but it will still
> } show you the manpage for git-add instead of git-commit.
>
> This points out a more generalized bug in Functions/Misc/run-help as it
> currently is implemented. If you have, for example
>
> zsh% run-help-less() { print $* }
> zsh% print this is not less but the next is; less /etc/termcap
>
> If you now hit ESC-h to invoke run-help, you get:
>
> but the next is
>
> and then the command "less /etc/termcap" is *executed*. The "eval" in
> Functions/Misc/run-help needs a (q) parameter expansion flag added, at
> the very least.
>
> } Since the run-help widget does a push-line, we can't use $CURSOR to
> } find out which is the actual command, this is how i solved it.
>
> It should be possible to solve this without resorting to hacking the C
> source. All you need is a user-defined ZLE widget that runs as a wrapper
> around the run-help widget to save the value of CURSOR. E.g.:
>
> run_help_cursor () {
> typeset -g HELPCURSOR=$CURSOR
> zle .run-help "$@"
> }
> zle -N run-help run_help_cursor
>
> Except that you're using CURSOR in your _runhelp function, so it must
> already be a widget? You didn't show a usage example.
Yeah it's a widget to use instead of run-help.
> It might be nice if the .run-help widget saved the cursor position itself,
> or behaved more like a completion widget and passed an array containing
> only the command words "around" the cursor, stripping from separators on
> either side. *That* would require C hacking.
>
> In any case I think your function will still do the wrong thing for
> something like "git commit git", though that's admittedly not a very
> likely scenario.
Hm yeah, the only way to really solve it would be if the C code also gave
us the index into $BUFFER where the word is, I think?
--
Mikael Magnusson
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-10-05 20:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-05 13:40 [rfc + bad patch] Allow to get the current cursor command from zle, for doing a nicer run-help Mikael Magnusson
2008-10-05 19:08 ` Bart Schaefer
2008-10-05 20:38 ` Mikael Magnusson
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).