zsh-users
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-users@sunsite.dk
Subject: Re: Redirection Symbol After Completion
Date: Sat, 08 Jul 2006 10:56:11 -0700	[thread overview]
Message-ID: <060708105612.ZM8718@torch.brasslantern.com> (raw)
In-Reply-To: <200607081145.k68BiwEY023823@pwslaptop.csr.com>

On Jul 8, 12:44pm, Peter Stephenson wrote:
} Subject: Re: Redirection Symbol After Completion
}
} Chris Johnson wrote:
} > I personally find commands easier to parse with my eye when the space
} > remains before the redirection symbol:
} > 
} >    cat file.txt |
} > 
} > Is there any way to force this space to persist even if I type a
} > redirection operator?
} 
} It's a perfectly reasonable thing to want to configure, but
} unfortunately I don't think it's possible to do this without some
} tweaking of the completion system.

Skipping ahead a bit ...

}   echo testdir/
} 
} and now type "|".  The slash isn't removed, as it usually would be.
} That's because the same mechanism controls the characters removed when
} you have a suffix, including an automatically added /, and when you
} don't, i.e. you get the space in your original question.

Presumably he wants the slash replaced by a space in that instance.  I
think you're going about this the wrong way -- rather than revamping
how autoremoval occurs in the general case, adjust the way redirection
ops are inserted.

    self-insert-redir() {
        integer l=$#LBUFFER
	zle self-insert
	(( $l >= $#LBUFFER )) && LBUFFER[-1]=" $LBUFFER[-1]"
    }
    zle -N self-insert-redir
    for op in \| \< \> \&
    do bindkey "$op" self-insert-redir
    done

I like that so much I might even keep it.

It'd be nice if it were possible to test whether a suffix removal is
pending rather than checking the length of LBUFFER before and after
the self-insert, but I think this suffices (no pun intended).

One could go so far as to actually replace self-insert and also check
with a style for what constitutes a redirection operator, but that
gets a bit uglier.  I believe there was a discussion several months
ago about the problems caused by not being able to instruct zsh when
to use the ZLE_KEEPSUFFIX internal flag on a user-defined widget.
(Hmm, maybe that problem doesn't apply here anyway.)

-- 


  reply	other threads:[~2006-07-08 17:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-07 17:32 Chris Johnson
2006-07-08 11:44 ` Peter Stephenson
2006-07-08 17:56   ` Bart Schaefer [this message]
2006-07-08 21:44     ` Bart Schaefer
2006-07-10 14:12     ` Chris Johnson
2006-07-10 23:30       ` Scott Anderson
2006-07-10 23:43         ` Bart Schaefer
2006-07-10 23:53           ` Scott Anderson

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=060708105612.ZM8718@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-users@sunsite.dk \
    /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).