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] [slock] 1.4 no longer working on freebsd with ldap/kerberos

Andrew Cobaugh wrote: > Trying one more time to bisect this, I ended up at > 04143fd68dbc656905714eff5c208fadb3464e25 as the commit that introduced > the "slock: getpwuid: cannot retrieve shadow entry (make sure to suid > or sgid slock)" error for my environment. This was with replacing >

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] [slock] 1.4 no longer working on freebsd with ldap/kerberos

Trying one more time to bisect this, I ended up at 04143fd68dbc656905714eff5c208fadb3464e25 as the commit that introduced the "slock: getpwuid: cannot retrieve shadow entry (make sure to suid or sgid slock)" error for my environment. This was with replacing HAVE_SHADOW with HAVE_PAM. I tried the

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] oasis: small linux system inspired by stali

Hi Michael, Overall I like your package selection, but I also have a few questions: * Did you consider using netbsd-curses[1] instead of ncurses? This probably won't work as is, because libtermkey as required by vis depends on the ncurses terminfo library. It might be worth

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] [slock] 1.4 no longer working on freebsd with ldap/kerberos

Andrew Cobaugh wrote: > I'm actually having a hard time bisecting, because even vanilla 1.3 fails to > work correctly. The screen locks, but then it doesn't accept my password. > > There is this patch in the ports tree which is necessary to make 1.3 work for > me, but it doesn't seem to apply

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] [slock] 1.4 no longer working on freebsd with ldap/kerberos

On Tue, Mar 21, 2017 at 7:10 PM, Markus Teich wrote: > Heyho Andrew, > > Andrew Cobaugh wrote: >> I believe this is related to this change: >> >> >> http://git.suckless.org/slock/commit/?id=04143fd68dbc656905714eff5c208fadb3464e25 > > Can you confirm this commit is

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