Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On 3/29/17, Martin Kühne wrote: > Whatever way we go now, I'm in favor of instead trying to remove code > in that regard. I agree, k0ga should just delete st.

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

> scrollback buffer built into st itself. Instead of mandating the use > of tmux et al, I would rather put a helper tool into the st repo, that > works as a basic shell wrapper process (no detaching). It would It can be a separated tool integrated with st, in the same way than utmp. I am going to

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

> scrollback buffer built into st itself. Instead of mandating the use > of tmux et al, I would rather put a helper tool into the st repo, that > works as a basic shell wrapper process (no detaching). It would It can be a separated tool integrated with st, in the same way than utmp. I am going to

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

> scrollback buffer built into st itself. Instead of mandating the use > of tmux et al, I would rather put a helper tool into the st repo, that > works as a basic shell wrapper process (no detaching). It would It can be a separated tool integrated with st, in the same way than utmp. I am going to

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

> I'd love to see scrollback also. I've played around a tiny bit with dumping If you want to work in the backscroll tool I can help you [1]. Regards, [1] http://ix.io/1vQQ

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

> Totally inconsistent crap. Basically you have to stop using stupid > programs that care about terminal width. It's the only real solution. > > I'm not even gonna talk about this curses bullshit. I don't care about > integrating such useless programs into scrollback. Indeed. Programs that look

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

Hi, Thank you for your contribution, but after thinking about it I think I am going to reject this patch. There are important reasons why st hasn't a scrollback buffer, and the same reasons apply to this patch. There are so many cases and so many interactions that is better to keep this logic out

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Wed, 29 Mar 2017, hiro <23h...@gmail.com> wrote: > give it up. it's all hopeless. urxvt does it the right way and it still sucks. This. Every single terminal in the world has broken resize handling, except for urxvt. Just copy what urxvt does, and let's focus on more exciting problems. <3,K.

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

That is the most sensible summary on the subject I have yet come across, chapeau. For anything that was hard or ambiguous to explain, this is what irks everyone about TUI, if that is even a thing, and the argument is very much why it shouldn't be. Whatever way we go now, I'm in favor of instead

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

give it up. it's all hopeless. urxvt does it the right way and it still sucks. for example: 1) run busybox ps in a big terminal, then resize it so stuff would get cut off in st -> it gets reflowed, which sucks a little cause it breaks the layout, but at least your stuff is still there, somewhat

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Sun, Mar 26, 2017 at 08:20:39PM +0300, Alexander Krotov wrote: > On Sun, Mar 26, 2017 at 06:10:37PM +0200, Laslo Hunhold wrote: >> On Sun, 26 Mar 2017 06:41:46 +0300 >> Alexander Krotov wrote: >>> Updated patch to clear up to maxcol in some cases and avoid glitches >>> when

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

* Jochen Sprickerhof 2017-03-29 08:35 > I still ponder to write an experimental shell where input and output is > separated and where the last line is input and the rest is scrollable > output. Scrolling through the input history would give you the > corresponding output and all output would be

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

* Greg Reagle [2017-03-27 21:37]: > > [1] http://st.suckless.org/patches/scrollback > > As listed above in [1], there is already a scrollback patch. Does it > have some deficiencies? Is it not a ring buffer? (Author here) It's a ring buffer. I wrote it after evaluating

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

> On Mon, Mar 27, 2017 at 11:11:05PM +0200, Quentin Rameau wrote: > > > nevertheless I do think that all this still doesn't justify a > > > scrollback buffer built into st itself. Instead of mandating the > > > use of tmux et al, I would rather put a helper tool into the st > > > repo, that works

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On 27 March 2017 at 23:52, Alexander Krotov wrote: > On Mon, Mar 27, 2017 at 10:00:43PM +0200, Anselm R Garbe wrote: >> nevertheless I do think that all this still doesn't justify a >> scrollback buffer built into st itself. Instead of mandating the use >> of tmux et al, I

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Mon, Mar 27, 2017, at 18:40, Alexander Krotov wrote: > Scrollback patch [1] adds 98 lines and removes 25 according to diffstat. > If implementing it separately takes significantly more effort than that, > it is probably not worth it. > > [1] http://st.suckless.org/patches/scrollback As listed

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

> Only recording raw output from commands, logging it to a text file > like the script(1) command and calling a pager on this file while > asking for scrollback. man.openbsd.org/script: > BUGS > > script places everything in the log file, including linefeeds and > backspaces. This is not what

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

Of course some tool like acme would solve the problem, but it is a different approach. For acme, the editor is a plain-text-only multiplexer (much easier to implement), and replaces every ncurses interfaces, so it is skipping the problem. For sam, the editor '!' command, pipes the output to a

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Mon, Mar 27, 2017 at 11:11:05PM +0200, Quentin Rameau wrote: > > nevertheless I do think that all this still doesn't justify a > > scrollback buffer built into st itself. Instead of mandating the use > > of tmux et al, I would rather put a helper tool into the st repo, that > > works as a basic

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Mon, Mar 27, 2017 at 2:00 PM, Laslo Hunhold wrote: > On Tue, 28 Mar 2017 00:52:03 +0300 > Alexander Krotov wrote: > > Hey Alexander, > >> As Laslo Hunhold suggests down the thread, this solution is likely to >> be more complex. >> >> To implement it properly,

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Tue, 28 Mar 2017 00:52:03 +0300 Alexander Krotov wrote: Hey Alexander, > As Laslo Hunhold suggests down the thread, this solution is likely to > be more complex. > > To implement it properly, you have to implement a whole VT inside > of stsb, because it has to pass mouse

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Mon, Mar 27, 2017 at 10:00:43PM +0200, Anselm R Garbe wrote: > Hi there, > > On 27 March 2017 at 12:11, Laslo Hunhold wrote: > > On Sun, 26 Mar 2017 20:06:57 + > > Cág wrote: > >> I am genuinely interested why. > > in my opinion, it's an unnecessary

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Mon, Mar 27, 2017 at 09:30:20PM +0100, Amadeusz Żołnowski wrote: > > I would rather put a helper tool into the st repo, that works as a > > basic shell wrapper process (no detaching). It would implement the > > scrollback buffer only and allow to define its size in a more flexible > > way

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

> Hi there, Hi, > On 27 March 2017 at 12:11, Laslo Hunhold wrote: > > On Sun, 26 Mar 2017 20:06:57 + > > Cág wrote: > >> I am genuinely interested why. > > in my opinion, it's an unnecessary component given I use terminals > > within dwm 99% of the

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Mon, 27 Mar 2017 22:00:43 +0200 Anselm R Garbe wrote: Hey Anselm, > nevertheless I do think that all this still doesn't justify a > scrollback buffer built into st itself. Instead of mandating the use > of tmux et al, I would rather put a helper tool into the st repo, that

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

> I would rather put a helper tool into the st repo, that works as a > basic shell wrapper process (no detaching). It would implement the > scrollback buffer only and allow to define its size in a more flexible > way (possibly via a command line argument) and also the control > sequences / key

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

In-between tmux and nothing, there is abduco(1): only attach/detach features. One could set some $ABDUCO to the session name, and if not set, attach to latest abduco session. Here is what I currently use [2]: if [ "$ABDUCO" ]; then printf 'session already active: %s\n' "$ABDUCO"

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

Hi there, On 27 March 2017 at 12:11, Laslo Hunhold wrote: > On Sun, 26 Mar 2017 20:06:57 + > Cág wrote: >> I am genuinely interested why. > in my opinion, it's an unnecessary component given I use terminals > within dwm 99% of the time. I don't need a

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

i don't want to attach to the same session over and over again at the same time. On 3/27/17, ilf wrote: > hiro: >> If I run ssh from that environment it shouldn't just start the >> configured shell in the server that I login to. It should instead run >> dtach on the server and

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

hiro: If I run ssh from that environment it shouldn't just start the configured shell in the server that I login to. It should instead run dtach on the server and the shell inside, so that when I resume my laptop and regain network connectivity that same script that wraps ssh will start a new

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

I want to start a tmux debate: I could imagine a shell environment where when I open a terminal it automatically starts a dtach'ed shell inside instead of just a shell. I should be able to close the shell and thus dtach and thus the terminal by running ctrl-d in the shell. If I just press the

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

Laslo Hunhold wrote: > I don't want to start a tmux debate here of course. Neither do I. Thanks for the answer. -- caóc

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Sun, 26 Mar 2017 20:06:57 + Cág wrote: Hey Cág, > > I hate using tmux and the like > > I am genuinely interested why. in my opinion, it's an unnecessary component given I use terminals within dwm 99% of the time. I don't need a terminal multiplexer when dwm

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

Laslo Hunhold wrote: > I hate using tmux and the like I am genuinely interested why. -- caóc

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Sun, Mar 26, 2017 at 06:10:37PM +0200, Laslo Hunhold wrote: > On Sun, 26 Mar 2017 06:41:46 +0300 > Alexander Krotov wrote: > > > Updated patch to clear up to maxcol in some cases and avoid glitches > > when using ncurses programs. > > I support this proposition. It may be

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

On Sun, 26 Mar 2017 06:41:46 +0300 Alexander Krotov wrote: > Updated patch to clear up to maxcol in some cases and avoid glitches > when using ncurses programs. I support this proposition. It may be "troublesome" for programs which depend on terminal size, but if you think