Re: Re: [dev] [st][patch] more work on the XEmbed embedder

On Sun, Feb 04, 2024 at 06:29:40PM +0100, Страхиња Радић wrote: > > That is how it usually works. Users submit patches, which are provided on > > https://st.suckless.org/patches/ > > and (depending on context) might get merged into the upstream. This > particular > patch doesn't look

Re: [dev] [st][patch] more work on the XEmbed embedder

On 24/02/04 03:22PM, Robin Haberkorn wrote: > Thirdly, I doubt that the maintainers would want to merge this into mainline. The essence of the suckless philosophy goes hand in hand with the Unix philosophy - programs that do one thing well and cooperate with other programs. st is and should

Re: [dev] [st][patch] more work on the XEmbed embedder

04.02.24 12:52, Hiltjo Posthuma пишет: > Hi, > > If you want to contribute to upstream you need to rebase the patches on the > master version of st. > > Then you send the patches (git-format-patch) to the mailinglist. > Okay. But first of all, there are remaining problems. I would like to

Re: [dev] [st][patch] more work on the XEmbed embedder

On Sun, Feb 04, 2024 at 08:38:46AM +0300, Robin Haberkorn wrote: > Hello! > > I picked up the patch from Jochen Sprickerhof > that was posted on hack...@suckless.org a few years ago, allowing you to > embed applications into st via Xembed. So this is the _host_ side of > Xembed, very similar to

[dev] [st][patch] more work on the XEmbed embedder

Hello! I picked up the patch from Jochen Sprickerhof that was posted on hack...@suckless.org a few years ago, allowing you to embed applications into st via Xembed. So this is the _host_ side of Xembed, very similar to what tabbed does. The thing is, you do not always want to open apps in new

Re: [dev] [st] Patch/feature request - redraw terminal on resize

On Sat, Oct 24, 2020 at 07:44:43PM +0100, Daniel Littlewood wrote: > Hi all, > > I have noticed a feature from tmux that I would like to have in vanilla st. > The behaviour is that when the screen resizes, the window is redrawn > to fit the new size. > In vanilla st, if I make the window smaller

[dev] [st] Patch/feature request - redraw terminal on resize

Hi all, I have noticed a feature from tmux that I would like to have in vanilla st. The behaviour is that when the screen resizes, the window is redrawn to fit the new size. In vanilla st, if I make the window smaller then output that was previously drawn there is blank. If I'm running a program

Re: [dev] [ dev ] [ st ] [ PATCH ] concurrency window size bug

On Fri, Jun 05, 2020 at 03:05:49PM -0400, Kyryl Melekhin wrote: > This bug is very exceptional and will only affect users who run other > terminal programs with st. > For example running > " st -e vim . " > " st -e lynx " > etc ... > Hi Kyryl, Thanks for the report. > The bug happens randomly,

[dev] [ dev ] [ st ] [ PATCH ] concurrency window size bug

This bug is very exceptional and will only affect users who run other terminal programs with st. For example running " st -e vim . " " st -e lynx " etc ... The bug happens randomly, and on some systems may not even exist, very hard to reproduce and predict. On my system with clean st build

Re: [dev] [st][patch] apply hints before initial mapping (ICCCM)

On Fri, Oct 25, 2019 at 10:11:13PM +0200, Ingo Lohmar wrote: > A few months ago, I sent the patch below to hack...@suckless.org, I am > still not sure if this was the right procedure.. In any case, since > there was no reaction to it, I am posting it here as well, looking for > comments. > > The

[dev] [st][patch] apply hints before initial mapping (ICCCM)

A few months ago, I sent the patch below to hack...@suckless.org, I am still not sure if this was the right procedure.. In any case, since there was no reaction to it, I am posting it here as well, looking for comments. The message and patch should explain themselves. If there is something

Re: [dev] [st][PATCH] better plumbing on linux: find child shell cwd without shell gymnastics

On 01/11/2018 09:33, Quentin Rameau wrote: > > Is that a Linux‐only patch? > Hi Quentin, It isn't anymore. Regs, John

Re: [dev] [st][PATCH] better plumbing on linux: find child shell cwd without shell gymnastics

On 01/11/2018 17:54, Markus Wichmann wrote: > On Thu, Nov 01, 2018 at 04:12:40PM +0100, John Soros wrote: >> Yes! This is much, much better! Thanks. Pity that it still doesn't work >> on OpenBSD. > > If the info I gathered over the course of the last hour is correct, then > the way to query CWD

Re: [dev] [st][PATCH] better plumbing on linux: find child shell cwd without shell gymnastics

> So, which option sucks least? TLDR: OSC7 from the shell, IMO. Given that I use st/zsh on OpenBSD more than Linux and wanted to add some 9term/rc mouse features to its glory, I tried quite a few tricks to get the current shell cwd. I decided on using the OSC7 approach, ie push from the shell to

Re: [dev] [st][PATCH] better plumbing on linux: find child shell cwd without shell gymnastics

On Thu, Nov 01, 2018 at 04:12:40PM +0100, John Soros wrote: > Yes! This is much, much better! Thanks. Pity that it still doesn't work > on OpenBSD. If the info I gathered over the course of the last hour is correct, then the way to query CWD in OpenBSD is #include char cwd[PATH_MAX];

Re: [dev] [st][PATCH] better plumbing on linux: find child shell cwd without shell gymnastics

On 01/11/2018 15:04, John Soros wrote: > On 01/11/2018 13:43, Markus Wichmann wrote: >> On Thu, Nov 01, 2018 at 08:46:06AM +0100, John Soros wrote: >>> config.def.h | 6 + >>> x.c | 76 >>> 2 files changed, 82 insertions(+) >>>

Re: [dev] [st][PATCH] better plumbing on linux: find child shell cwd without shell gymnastics

On 01/11/2018 13:43, Markus Wichmann wrote: > On Thu, Nov 01, 2018 at 08:46:06AM +0100, John Soros wrote: >> config.def.h | 6 + >> x.c | 76 >> 2 files changed, 82 insertions(+) >> >> diff --git a/config.def.h b/config.def.h >>

Re: [dev] [st][PATCH] better plumbing on linux: find child shell cwd without shell gymnastics

On Thu, Nov 01, 2018 at 09:33:37AM +0100, Quentin Rameau wrote: > Hello John, > > > + DIR* srcdir = opendir("/proc/self/task"); > > Is that a Linux‐only patch? > The subject line would indicate thus. Funnily enough, *that* dependency could be removed. What can't be removed is the dependency

Re: [dev] [st][PATCH] better plumbing on linux: find child shell cwd without shell gymnastics

On Thu, Nov 01, 2018 at 08:46:06AM +0100, John Soros wrote: > config.def.h | 6 + > x.c | 76 > 2 files changed, 82 insertions(+) > > diff --git a/config.def.h b/config.def.h > index 87ebdbb..265a4ff 100644 > --- a/config.def.h >

Re: [dev] [st][PATCH] better plumbing on linux: find child shell cwd without shell gymnastics

Hello John, > + DIR* srcdir = opendir("/proc/self/task"); Is that a Linux‐only patch?

Re: [dev] [st][PATCH] Fix iso14755 on OpenBSD

On Tue, 11 Sep 2018 02:52:02 + st1...@cumallover.me wrote: > Hello, Hello st1cky, > `iso14755` is broken on OpenBSD since the introduction of pledge > patch. This happens because key presses are handled in the > "master" side of st, which doesn't includes "exec" in it's > promise. Below you

[dev] [st][PATCH] Fix iso14755 on OpenBSD

Hello, `iso14755` is broken on OpenBSD since the introduction of pledge patch. This happens because key presses are handled in the "master" side of st, which doesn't includes "exec" in it's promise. Below you can find a patch to fix that. You can reproduce this by trying to invoke such

Re: [dev] [st] [patch] If no Glyph Found, Do Not Keep a Font Loaded

On Wed, Mar 21, 2018 at 05:42:07PM -0400, Gary Allen Vollink wrote: > Any request for a glyph that isn't present will load the LastResort > font, effectively killing all future fallback searches. > > I have NO idea how to fix this without opening the vacuum of space > (wow, a lot of suck). I will

Re: [dev] [st] [patch] If no Glyph Found, Do Not Keep a Font Loaded

Notes to add to what I said above. 1) If X no longer cares if a font remains open, perhaps frc[] can be changed to a non-array. This would allow frc to continue to be used for the one-off glyph loads, without the extra maintenance of keeping track of fonts already opened. This moves the issue

Re: [dev] [st] [patch] If no Glyph Found, Do Not Keep a Font Loaded

Okay, you seem to be right. Before I upgraded my Ubuntu at the end of last year I did have this issue there, too. I can assure you that this /was/ a crash on Linux, and perhaps you've just had a more recent version of the relevant X libraries since I started on this list. I know - for certain -

Re: [dev] [st] [patch] If no Glyph Found, Do Not Keep a Font Loaded

On Wed, Mar 21, 2018 at 02:18:53PM -0400, Gary Allen Vollink wrote: > This patch is over my previous simplification patch > (https://lists.suckless.org/dev/1803/32601.html), though it could be > reworked to go in without it. > > Problem: When working with text from many languages, it does not

[dev] [st] [patch] If no Glyph Found, Do Not Keep a Font Loaded

This patch is over my previous simplification patch (https://lists.suckless.org/dev/1803/32601.html), though it could be reworked to go in without it. Problem: When working with text from many languages, it does not take long to run out of font slots for Runes that do not exist within any

[dev] [st] [patch] Move font/rune negotiation

The following patch is simplification only.  It puts rune lookup directly into the function that does font loading. I have a forthcoming patch that sits on top of this that fixes a rare crash situation.  This one stands alone, and because it overall removes code I feel it should be considered

Re: [dev] [st] [PATCH] Remove expose() to prevent unresponsiveness

On Thu, 22 Jun 2017 19:36:03 -0400 "S. Gilles" wrote: Hey S., > The first thing I tried was to delete expose() from x.c, which has > been working perfectly for the past hour or so: st is responsive > and I haven't seen any visual issues. > > Since it seems to work for my

[dev] [st] [PATCH] Remove expose() to prevent unresponsiveness

--- Doc, it hurts when I do this: - have a huge st (say, 100 x 200 rows x cols?) - take a floating window and gently wave it over st for a second or two, generating lots of Expose events - switch to st and try to type - wait for 20+ seconds for all the damn redraw()s to finish - see

[dev] [st] [PATCH v2] Implement OSC 12 (change text cursor color)

This escape sequence comes from xterm and derivatives and allows terminal to change cursor color. In xterm it supported only #RRGGBB color format, but starting with rxvt it allows to change the color using indexes from the color table. We support only color indexes. Use: echo -ne

Re: [dev] [st] [PATCH] Implement OSC 12 (change text cursor color)

On Sun, Jun 04, 2017 at 06:15:10PM +0200, Hiltjo Posthuma wrote: > On Sun, Jun 04, 2017 at 05:25:36PM +0200, Arkadiusz Hiler wrote: > > This escape sequence comes from xterm and derivatives and allows > > terminal to change cursor color. > > > > In xterm it supported only #RRGGBB color format,

Re: [dev] [st] [PATCH] Implement OSC 12 (change text cursor color)

On Sun, Jun 04, 2017 at 05:25:36PM +0200, Arkadiusz Hiler wrote: > This escape sequence comes from xterm and derivatives and allows > terminal to change cursor color. > > In xterm it supported only #RRGGBB color format, but starting with rxvt > it allows to change the color using indexes from

[dev] [st] [PATCH] Implement OSC 12 (change text cursor color)

This escape sequence comes from xterm and derivatives and allows terminal to change cursor color. In xterm it supported only #RRGGBB color format, but starting with rxvt it allows to change the color using indexes from the color table. We support only color indexes. Use: echo -ne

Re: [dev] [st] patch for bold, italic, underline colors

On Sun, 23 Apr 2017 12:09:43 -0700 "Suraj N. Kurapati" wrote: Hey Suraj, > I was unable to push the attached patch to the st wiki: > > $ git push > Counting objects: 7, done. > Delta compression using up to 2 threads. > Compressing objects: 100% (7/7), done.

Re: [dev] [st] patch for bold, italic, underline colors

On Sun, 23 Apr 2017 21:35:33 +0200, Jochen Sprickerhof wrote: > I think we don't need it, as you can do it using environment > variables: > > https://unix.stackexchange.com/questions/119/colors-in-man-pages Thanks for the tip! Perhaps this patch may still be useful for cases where less(1) is

Re: [dev] [st] patch for bold, italic, underline colors

On Sun, 23 Apr 2017 22:23:56 -0300, Lucas Gabriel Vuotto wrote: > usually, git protocol is read-only. Have you tried pushing with > the remote set to http://git.suckless.org/sites ? Yes I tried that, but a similar failure occurred: $ git remote set-url origin http://git.suckless.org/sites

Re: [dev] [st] patch for bold, italic, underline colors

Hi Suraj, usually, git protocol is read-only. Have you tried pushing with the remote set to http://git.suckless.org/sites ? Cheers. On 23/04/17 16:09, Suraj N. Kurapati wrote: Hello, I was unable to push the attached patch to the st wiki: $ git push Counting objects: 7, done.

Re: [dev] [st] patch for bold, italic, underline colors

Hi Suraj, * Suraj N. Kurapati [2017-04-23 12:09]: > Please review and apply the attached patch on my behalf. I think we don't need it, as you can do it using environment variables: https://unix.stackexchange.com/questions/119/colors-in-man-pages Cheers Jochen

[dev] [st] patch for bold, italic, underline colors

Hello, I was unable to push the attached patch to the st wiki: $ git push Counting objects: 7, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 8.82 KiB | 0 bytes/s, done. Total 7 (delta 3), reused 0 (delta

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 1/2] Fix commented out code

On Wed, Mar 29, 2017 at 10:09:15AM +0200, Ivan Delalande wrote: > On Sat, Mar 25, 2017 at 11:02:42PM +0300, Alexander Krotov wrote: > > --- a/st.c > > +++ b/st.c > > @@ -2537,7 +2537,7 @@ tresize(int col, int row) > > } > > > > /* allocate any new rows */ > > - for (/* i == minrow */;

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

> this is a very good point! Even if this was approached with an external > tool you probably just start implementing st again with all the bells > and whistles, let alone the fact that you need a separate program to > make st work as desired in a normal setup within a window manager. No, you

Re: [dev] [st] [PATCH 1/2] Fix commented out code

> I don't think that's a typo, just a short form for "hey, watch out, > remember we still have `i == minrow` from the last loop here!". ;) Uh, you are right. Sadly I read your comment after pushing it. Best regards,

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

> I can live without scrollback, but what I dislike about st now is > that it loses lines when I just shuffle my terminals around with > dwm. When I have 3 windows (1 master, 2 stack) and move terminal As I have said in the previous mail, I can help you to write the tool to solve this problem.

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 1/2] Fix commented out code

On Sat, Mar 25, 2017 at 11:02:42PM +0300, Alexander Krotov wrote: > --- a/st.c > +++ b/st.c > @@ -2537,7 +2537,7 @@ tresize(int col, int row) > } > > /* allocate any new rows */ > - for (/* i == minrow */; i < row; i++) { > + for (/* i = minrow */; i < row; i++) { >

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

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

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

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

--- 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)

[dev] [st] [PATCH 1/2] Fix commented out code

--- st.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/st.c b/st.c index d7bd32a..ae93ade 100644 --- a/st.c +++ b/st.c @@ -2537,7 +2537,7 @@ tresize(int col, int row) } /* allocate any new rows */ - for (/* i == minrow */; i < row; i++) { + for

[dev] [st] [PATCH] Make missing attribute fallback color optional

I wasted an hour trying to figure out why st on different hosts using the exact same terminfo configuration and statically compiled tmux was displaying some text in yellow. The hosts where this produced yellow text were using an Ubuntu-based Linux distro while the hosts where st continued to work

Re: [dev] [st] [PATCH] Converted "font" string to "fonts" array

On Mon, Aug 15, 2016 at 03:59:40AM +0300, Amer wrote: > I don't understand at all how you can apply this embedded-into-body > patch with all tabs replaced by spaces and lines wrapped on 80. > What magic I need for this? It was unintentional. Normally, I send patches to the list as attachments,

Re: [dev] [st] [PATCH] Converted "font" string to "fonts" array

I don't understand at all how you can apply this embedded-into-body patch with all tabs replaced by spaces and lines wrapped on 80. What magic I need for this? Anyway, reformatted patch cleanly applying to 0.7 in the attachment. diff --git a/config.def.h b/config.def.h index b41747f..638c3c5

[dev] [st] [PATCH] multiplexer (tmux integration)

I suppose this patch isn't mature enough, so you are welcome. Content * added -m/-M command line options to demand/ignore multiplexer (using only -m option to toggle defaults isn't robust enough) * config options to specify exec wrapper and finalizing commands * sessions are named after

Re: [dev] [st] [PATCH] Converted "font" string to "fonts" array

Greetings. Thanks for your patch. On Tue, 02 Aug 2016 19:39:23 +0200 Eric Pruitt wrote: > Modifies st to support user-defined fallback fonts specified in an > array. This change also resolves an issue where fallback fonts were used > in place of default fonts in an

[dev] [st] [PATCH] Converted "font" string to "fonts" array

Modifies st to support user-defined fallback fonts specified in an array. This change also resolves an issue where fallback fonts were used in place of default fonts in an inconsistent manner which caused identical sets of text to sometimes use different fonts. --- config.def.h | 15 +---

[dev] [st] [PATCH] Converted "font" string to "fonts" array

Modifies st to support user-defined fallback fonts specified in an array. This change also resolves an issue where fallback fonts were used in place of default fonts in an inconsistent manner which caused identical sets of text to sometimes use different fonts. --- config.def.h | 15 +---

Re: [dev] [st][PATCH] Use XftFontMatch in place of FcFontMatch.

On Wed, 20 Jul 2016 13:37:01 +0200 Christoph Lohmann <2...@r-36.net> wrote: > Sorry for the late answer, I had to save the world. Care to elaborate? -- FRIGN

Re: [dev] [st][PATCH] Consistent Alt+BackSpace behavior

Greetings. On Tue, 12 Jul 2016 15:26:20 +0200 Alive 4ever wrote: > The default config specifies BackSpace as "\177". The default behavior > should persist across modifier keys, commonly Mod1 (Alt or Meta) which > is widely used to delete a word on readline and text editors,

[dev] [st][PATCH] Consistent Alt+BackSpace behavior

The default config specifies BackSpace as "\177". The default behavior should persist across modifier keys, commonly Mod1 (Alt or Meta) which is widely used to delete a word on readline and text editors, notably Emacs. This will make Alt+BackSpace behaves as expected, i.e. sends "\033\177"

Re: [dev] [st][PATCH] Use XftFontMatch in place of FcFontMatch.

Seems like I was able to narrow down the bug with fonts fallback. (Requisites: multiple fallback fonts for 'monospace'.) Running on HiDPI with 'pixelsize' -- all works as expected: st -f monospace:pixelsize=35 Using relative font size, only first font treats 'size' as relative. But all

Re: [dev] [st][PATCH] Use XftFontMatch in place of FcFontMatch.

Greetings, Christoph I tried many ways to fix my fontconfig, but fallback isn't working for me with XftFontMatch patch at all. There isn't much difference in my configuration, comparing with Gentoo or Arch wiki. Therefore I finally ask you to share your working fontconfig, where fallback

Re: [dev] [st][PATCH] Use XftFontMatch in place of FcFontMatch.

Greetings. On Fri, 03 Jun 2016 15:06:23 +0200 Amer wrote: > Hi Mark, > > After applying your patch, fontconfig fallbacks don't work for me > anymore. Only first/main font is scaled, and all consequent aren't. > > st/config.def.h > static char font[] = "monospace-9.6"; >

Re: [dev] [st][PATCH] Use XftFontMatch in place of FcFontMatch.

Greetings. On Fri, 03 Jun 2016 15:03:44 +0200 Mark Edgar wrote: > This change allows st to correctly render fonts given in point sizes, > bringing its behavior in line with other software: dwm, dmenu, tabbed, > etc: > > FC_DEBUG=1 st -f Terminus:size=10 > > -Mark

Re: [dev] [st] [patch] clipboard properties burn after reading

Greetings. On Fri, 03 Jun 2016 14:55:47 +0200 v4hn wrote: > Hey everyone, > > I use synergy (for input device sharing) on a daily basis > and experienced this rather annoying bug in combination with st: > > Whenever I paste something from another machine to st, > pasting

Re: [dev] [st][PATCH] Use XftFontMatch in place of FcFontMatch.

Hi Mark, After applying your patch, fontconfig fallbacks don't work for me anymore. Only first/main font is scaled, and all consequent aren't. st/config.def.h static char font[] = "monospace-9.6"; ~/.config/fontconfig/fonts.conf ... monospace Source

  1   2   3   4   5   6   7   8   9   10   >