zsh-users
 help / color / mirror / code / Atom feed
From: Wayne Davison <wayned@users.sourceforge.net>
To: Simon Friedberger <simon+zsh@a-oben.org>
Cc: zsh-users@zsh.org
Subject: Re: Assorted questions
Date: Mon, 7 Jun 2010 16:23:38 -0700	[thread overview]
Message-ID: <AANLkTikZUYfGgyW6FlgpkjlPdvYGzHBXdUeD6FEMThip@mail.gmail.com> (raw)
In-Reply-To: <20100605192316.GB26738@a-oben.org>

[-- Attachment #1: Type: text/plain, Size: 3719 bytes --]

On Sat, Jun 5, 2010 at 12:23 PM, Simon Friedberger
<simon+zsh@a-oben.org<simon%2Bzsh@a-oben.org>
> wrote:

> Hello everybody,
>
> I'll just make a list with my questions. :)
>
> 1.      Can I give background color to empty spaces.
>        I've adapted the example in the wiki at
>        http://zshwiki.org/home/examples/zlewidgets#vi_keys_-_show_mode
>        to show a different background color when in vi command mode.
>        You can see what I did here
>        https://simon.a-oben.org/blog/?p=233
>        Just in case that the details matter.
>
>        This approach has two problems.
>        a) The empty background isn't colored. This isn't really a
>        problem but it would be nice if it was. Is it possible?
>        b) I have a little smily in my prompt for return status 0 and
>        the return status for anything else. This is reset when I change
>        mode but it shouldn't. Any fixes?
>
> 2.      I'm a fan of keeping things simple so I'm a bit irritaded by
>        some of the options. Maybe you can explain a good use-case to me.
>        a)      accept-and-hold seems to be the same as <ENTER>^p
>        b)      history-search-back(for)ward and
>                history-beginning-search-back(for)ward
>                seem to be the same as ^r
>                I know that there is a subtle difference but I don't see
>                how it matters in practice.
>
> 3.      The zle section of the guide suggests a binding with
>        bindkey -rpM viins '\e['
>        to make <ESC> unambiguous but I tried with $KEYTIMEOUT set to
>        something high and it doesn't seem to make a difference if I
>        have that binding or not. Can anybody suggest an experiment
>        where the difference shows?
>
> 4.      I would like to have some history magic. It would be nice if
>        ^p/^n (or up/down) just switched through the local history but
>        ^r/^s searched through all history entries.


Since I'm a touch typist, I almost alway use Ctrl-P and Ctrl-N to browse the
history list, so I have them set to only visit local history.  I then leave
up-arrow and down-arrow set to browse the whole list (as does searching).
 Here's how I do it:

bindkey '^p' up-line-or-local-history
bindkey '^n' down-line-or-local-history

up-line-or-local-history() {
    zle set-local-history 1
    zle up-line-or-history
    zle set-local-history 0
}
zle -N up-line-or-local-history
down-line-or-local-history() {
    zle set-local-history 1
    zle down-line-or-history
    zle set-local-history 0
}
zle -N down-line-or-local-history

Keep in mind that those fuctions assume that it is OK to set-local-history
back to 0 -- if you don't normally toggle local history manually, then it
should be fine.

Someone who likes to use Up-arrow and Ctrl-P interchangeably could either
bind those functions to the arrow keys, or you could set local history on by
default and turn it off for the search functions.  But keep in mind that you
may want full-list searching for things like Esc-P
(history-beginning-search-backward) too.

For manually toggling shared history browsing:

bindkey '^[/' set-local-history

I used to have shared history set but it irks me that when a long
> command finished I cannot just press up and change a paramter and run
> it again.
>

That should not be the case.  When you enter a command, zsh always imports
all the shared lines first, and then appends your just-entered command last.
 That way any prior-line visitation is always to the command you just ran.
 If you entered no command, then it just slurps in new history lines, and
thus the prior command could indeed be a non-local line (since there was no
local line to follow the new ones).

..wayne..

  parent reply	other threads:[~2010-06-07 23:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-05 19:23 Simon Friedberger
2010-06-07 16:44 ` Richard Hartmann
2010-06-07 16:50   ` Simon Friedberger
2010-06-07 17:11 ` Mikael Magnusson
2010-06-07 23:23 ` Wayne Davison [this message]
2010-06-08  9:12   ` Simon Friedberger
2010-06-09 19:50     ` Wayne Davison
     [not found]       ` <AANLkTimeIv_xV6qHnFUpHqjD3LmVJqY_r5IQJQGtaKjo@mail.gmail.com>
2010-06-10  6:41         ` Bart Schaefer
2010-06-09 11:40   ` zle set-local-history binding Was: " Simon Friedberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTikZUYfGgyW6FlgpkjlPdvYGzHBXdUeD6FEMThip@mail.gmail.com \
    --to=wayned@users.sourceforge.net \
    --cc=simon+zsh@a-oben.org \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).