vile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vile] Minibuffer bindings


From: Thomas Dickey
Subject: Re: [vile] Minibuffer bindings
Date: Tue, 29 Jul 2008 17:09:29 -0400
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, Jul 29, 2008 at 01:34:31PM -0400, Decklin Foster wrote:
> How can I bind something in the minibuffer? I *think* I want this:
> 
>   ; don't use these in normal editing, so make them switch windows
>   bind-key next-window ^N
>   bind-key previous-window ^P
> 
>   ; *do* want these to be emacs-like in the minibuffer
>   bind-cmdmode-key next-line ^N
>   bind-cmdmode-key previous-line ^P
>   bind-cmdmode-key left-arrow ^B
>   bind-cmdmode-key right-arrow ^F
> 
> Normally ^N/^P DTRT in the minibuffer, but rebinding them in the regular
> map breaks that. But maybe I don't want cmdmode? I see this in input.c:

It's supposed-to make bindings in any of the non-default maps override
the default map.  (If not, it's a bug).

>         cfp = ((miniedit)
>                ? CommandKeyBinding(c)
>                : InsertKeyBinding(c));
>  
> I rarely (okay, never) use mini-edit; so I guess I just want insmode.

But insmode only applies to regular buffers.

The default editing of the command-line is essentially hardcoded (aside from
the characters you can see with show-terminal-chars).  Likewise the history
mechanism.  That's partly because they're very specialized editing modules
that do things like name-completion.

> If I turn on insert-exec, I can get ^N/^P/^B/^F working in regular insert
> mode, but still nothing in the minibuffer.

With your example, mini-edit seems to respond to the ^B/^F characters.
However, mini-edit doesn't interact with the command-history.

I guess it should be smart enough to translate the ^N/^P into
the codes that scroll within the history buffer - hadn't thought of
scrolling _in_ mini-edit mode, since it's explicitly a single-line
editor.
 
> ^B/^F actually didn't work in the minibuffer to begin with. Trying to
> figure out why, I found this in history.c:
> 
>         if ((p = DefaultKeyBinding(c)) != 0) {
>             if (CMD_U_FUNC(p) == backline)
>                 h_direction = -1;
>             else if (CMD_U_FUNC(p) == forwline)
>                 h_direction = 1;
>         }
> 
> So that explains ^N/^P. But shouldn't it be checking CommandKeyBinding
> here? Or am I totally on the wrong track as to what bind-cmdmode-key is
> for?

I think that would be done up in input.c - though making the seams between
input.c and history.c not visible does take work.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]