Re: [dev] [st] alternate screen switching

From: Bert Münnich <ber.t_AT_gmx.com>
Date: Thu, 9 Jun 2011 12:37:32 +0200

On 08.06.11, Aurélien Aptel wrote:
> On Wed, Jun 1, 2011 at 9:59 AM, Bert Münnich <ber.t_AT_gmx.com> wrote:
> > I would also like to look into the scrollback buffer goal. How do
> > you
> > want to achieve an unlimited scrollback buffer? Writing every line to a
> > file and printing its content instead of the current buffer when
> > scrolling back? What are the cons to just having a fixed amount of lines
> > (simply a bigger Line *line), memmoving them when input arrives and
> > normally displaying only the row-1 last ones?
>
> It could be done that way, yes.
> Personally, I don't need the scollback buffer but from what I've
> gathered there are more people who want it than people who don't.
> It's even written here http://st.suckless.org/goals
> It would be great if st could "export" an interface to it so things
> like URL selecting/launching in browser could be done via scripts.
> Something like a plan9 file hierarchy. I would like to hear someone
> else thoughts about that.

I'm not sure about the "exporting" thing. If there's one thing I've
learned from writing url-select [1], it's that a lot of URLs get line
wrapped inside curses-based applications (e.g. mcabber, irssi, weechat,
vim, newsbeuter, mutt) and there's nothing you can do about getting them
right at the terminal level. I handle all URLs using a simple dmenu-
based script [2] from within the applications, because they see the
actual text and not the curses-representation of it.
People get often enoyed by long multi-line URLs they can't select/open
easily. And the simpler one-line ones could be easily selected inside
rxvt-unicode by simply double-clicking them. IMO a decent double- and
triple-click text selection handling is much more important than URL
matching.

1: https://github.com/muennich/urxvt-perls
2: https://raw.github.com/muennich/dotfiles/master/bin/durlview
Received on Thu Jun 09 2011 - 12:37:32 CEST

This archive was generated by hypermail 2.2.0 : Thu Jun 09 2011 - 12:48:02 CEST