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.
> 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
> 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
> 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
> 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
> 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 t
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
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.
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 tr
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
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 using ncurses progra
* 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 pre
* 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 the option to implement
> 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 a
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 would rather put a helpe
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
> 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 th
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
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
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, you have to implement a whole VT i
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 events down and keep
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 component given I use terminals
> > wit
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 (possi
> 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 time. I don't need a terminal multiple
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
> works as a basic
> 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 comb
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"
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 terminal multiplexer when
> dwm multiple
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 the shell inside, s
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
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 lit
Laslo Hunhold wrote:
> I don't want to start a tmux debate here of course.
Neither do I. Thanks for the answer.
--
caóc
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 multiplexes my terminals for
Laslo Hunhold wrote:
> I hate using tmux and the like
I am genuinely interested why.
--
caóc
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 "troublesome" for pr
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 about it, ncurses
appl
Updated patch to clear up to maxcol in some cases and avoid glitches
when using ncurses programs.
-- >8 --
Subject: [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal
---
st.c | 50 ++
st.h | 1 +
2 files changed, 27 insertions(+),
---
st.c | 32 +---
st.h | 1 +
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/st.c b/st.c
index ae93ade..2eab32a 100644
--- a/st.c
+++ b/st.c
@@ -1238,8 +1238,8 @@ tclearregion(int x1, int y1, int x2, int y2)
if (y1 > y2)
temp
38 matches
Mail list logo