Re: [dev] neatroff
On 10 August 2016 at 08:47, Eli Cohen wrote: > What's the plan for stali? I was under the impression it would be a > "suckless distro" with dwm, surf, st... will X11 stuff be in a > different repository? The stali plan has changed for me a bit during the last year. A couple of months ago I tried to get stali self-bootstrappable based on just src/. I have now given up on this idea for various reasons: - I don't think it is really the point of stali to become a general purpose system anymore. - I can't stand the hideousness of gcc and llvm which seem to be a requirement to get it done - I wasn't able to create a statically linked cross target gcc setup that is easy to port among different hosts/targest (host=target works, but it sucks). If one wants a general purpose system, there are plenty to pick from. Granted, there are 0 statically linked ones. And that's the point. A statically linked system *should not* be general purpose, it ought to be special purpose instead. The special purpose I think stali now will become is this: it will be a multi-target static distro (pick your root fs flavour as you like) without aiming to be self-bootstrappable. The target will most likely be fully compiler- and build-chain less. This makes the target system execution-only oriented and more compact. My next goal is to target the arm64 (pi3) platform now. In terms of "package management" this has also the implication, that one can thing of extra/ add-on overlays that keep src/ sane. And such ending up in the particular rootfs flavour. Whenever someone wants to part a certain package to stali, just create a setup that relies on the fact that $STALI_ROOT/src and $STALI_ROOT/toolchain- exists and good is. We will need general purpose (Debian, Gentoo, Arch, whatever) build environments though. (I will present some ideas at slcon3 about actual projects I'm working on right now in terms of observing my bee hives with pi zeros that will become stali based.) Some days ago I branched src's master into a x86_64 branch, this will aim for a very basic suckless target system featuring an X + dwm/dmenu/st on top of the base system, Potentially with the addition of a webkitgtk + surf static build. My current arm64 branch will aim for a X-less target of course with only the absolutely necessary stuff. I will create some extra repos on top of that for some observation tools using different pi gadgets, such as temp+humidity sensors and a IR camera. > I tried to do something similar on my lan when I first heard of stali, > with a bunch of overlaid rsync repositories. I guess I'm mostly > curious about how i can help :) Any help is welcome under the new premises above. I think it is kind of a hygene factor to not aim for a self-bootstrappable environment. The beauty is that target platform, not the src/. The src/ is hideous in most parts anyways, if you consider what stali relies on. BR, Anselm
Re: [dev] [sxiv] Discussion
On Tue, Aug 9, 2016 at 10:39 PM, Bert Münnich wrote: > There's already lel[0] that does just this. But sxiv is not only an > image viewer. I heavily use it to organize my image library, e.g. > visually selecting files to import from a huge collection of freshly > taken photos or performing simple editing tasks like rotating--lossless > in case of JPEG--and tagging images with the external key-handler. > Using temporary farbfeld files as input would not make this easier. First of all, thanks Bert for developing `sxiv`! Of all the "lightweight" image viewers out there it's almost the "perfect" combination of simplicity (thus lightness), but with a few useful features like the thumbnail view, marking pictures, navigating among them, refreshing on image update, and stdin/stdout consumption and outputing of images, etc. In fact, like you, I have also integrated `sxiv` into my "photography" workflow, for both selecting potential images, and "analysing" them with a few tools I've wrote myself. Thus if I were to "vote", I would say `sxiv` fits quite well into the "suckless" tools collection. Thanks again Bert! Ciprian. P.S.: Regarding the "suckless" philosophy of reducing "dependencies": we are all aware that these "lightweight" tools run (I would bet in most cases) on modern Linux distributions (thus most likely with systemd), under Xserver (or whatever it is called today), and are compiled with GCC, right? :) Thus if one counts the OS kernel (plus its systemd counterpart), and the OS utilities needed to boot it up, and the needed X environment, and the compiler as dependencies (because they are, or without them the tool wouldn't actually work), then a handful of libraries pale in comparison... :) And not to mention the "code quality" (or "beauty") mantra... Wouldn't want to start that topic, as I know I've written countless lines of sh***y code myself... Who hasn't? :) In the end, if the tool works, great! Glory to its author! :)
Re: [dev] neatroff
On Thu, 11 Aug 2016 09:44:45 +0200 Anselm R Garbe wrote: Hey Anselm, > The stali plan has changed for me a bit during the last year. A couple > of months ago I tried to get stali self-bootstrappable based on just > src/. I have now given up on this idea for various reasons: > [...] > Any help is welcome under the new premises above. I think it is kind > of a hygene factor to not aim for a self-bootstrappable environment. > The beauty is that target platform, not the src/. The src/ is hideous > in most parts anyways, if you consider what stali relies on. I've been wondering for a while what you think the problem is with OpenBSD. Wouldn't it make more sense to somehow start an initative in OpenBSD to promote static linking there? Cheers FRIGN -- FRIGN
Re: [dev] [sxiv] Discussion
On Tue, 9 Aug 2016 18:09:44 +0200 Bert Münnich wrote: Hey Bert, > I was asked for sxiv becoming an official suckless project. I had > nothing against that move. And I have nothing against reversing it. I think there was a misunderstanding on my part. Does main development happen on GitHub or at suckless.org? In the latter case, I would favor keeping it on suckless.org having given it more thought. Cheers FRIGN -- FRIGN
Re: [dev] neatroff
On 11 August 2016 at 10:10, FRIGN wrote: > On Thu, 11 Aug 2016 09:44:45 +0200 > Anselm R Garbe wrote: >> The stali plan has changed for me a bit during the last year. A couple >> of months ago I tried to get stali self-bootstrappable based on just >> src/. I have now given up on this idea for various reasons: >> [...] >> Any help is welcome under the new premises above. I think it is kind >> of a hygene factor to not aim for a self-bootstrappable environment. >> The beauty is that target platform, not the src/. The src/ is hideous >> in most parts anyways, if you consider what stali relies on. > > I've been wondering for a while what you think the problem is with > OpenBSD. Wouldn't it make more sense to somehow start an initative in > OpenBSD to promote static linking there? I have no problem with OpenBSD per se, but I do think that its scope is general (server) purpose and that the hardware support in the embedded non-network space doesn't sound too great to me. linux kernel + some dedicated userland is far more flexible imho. Cheers, Anselm
[stali] scope (was: Re: [dev] neatroff)
On Thu, 11 Aug 2016 11:03:13 +0200 Anselm R Garbe wrote: Hey Anselm, > I have no problem with OpenBSD per se, but I do think that its scope > is general (server) purpose and that the hardware support in the > embedded non-network space doesn't sound too great to me. linux kernel > + some dedicated userland is far more flexible imho. hardware support is not as good as we see with Linux, but consider how much money flows into Linux compared to OpenBSD and how many companies push changes into the Linux kernel. And things are improving and there are numerous laptops and desktops running very well with it. Given how dedicated the suckless fellows are anyway (the only possible userbase for stali tbh in the short term), I'm sure they'd even invest into a laptop or desktop with the special interest of it supporting OpenBSD. Another thing is: Look at the OpenBSD drivers, they are designed like space-ships. Compared to this, Linux kernel code often looks like a racing kart held together with duct tape. I'd rather use a system offering less hardware support but genuinely better security and stability than some clamped on solution. My thoughts are this: We could either go ahead and create yet another Linux distribution with, even if it was successful, yet another fragmented community. Package maintenance is not an easy task, and as we discussed at the last slcon, you intend to rewrite all the build systems for the different projects to make them suckless, which is ambitious but also too ambitious for a project with such little manpower. We need to save our energy for projects that matter. The OpenBSD ports system is solid and well-maintained; we have strong arguments on our side to justifiy why static linking is in many ways more secure, stable and lightweight than dynamic linking. OpenBSD has some old cruft of course, but with Linux we are just scratching the surface. The entire userland is a toxic environment. The OpenBSD developers are sane guys and have complete control over the userspace; they discuss with reason and are not frightened to cut big chunks out of the OS if they see fit. The static approach of course would not apply to all packages, but I wouldn't even be surprised if they accepted such changes for certain things. As an example: Just look how easy it is to setup Wifi on OpenBSD, or a RAID, and many other things. This is years ahead of Linux. I am sure suckless.org has a lot of street-cred in the OSS-scene. We could use this leverage to have a positive influence on a big distribution people actually use. In the long term, making OpenBSD better will benefit those who are scared of making the switch. We all know that OpenBSD is much further on the convergence line towards an ideal operating system for server and desktop applications than Linux and its messy userland. Cheers FRIGN -- FRIGN
Re: [dev] [sxiv] Discussion
> In fact, like you, I have also integrated `sxiv` into my "photography" > workflow, for both selecting potential images, and "analysing" them > with a few tools I've wrote myself. Would you mind sharing them? Sicerely, S. R. Gal
Re: [stali] scope (was: Re: [dev] neatroff)
On 11 August 2016 at 11:21, FRIGN wrote: [..] > I am sure suckless.org has a lot of street-cred in the OSS-scene. We > could use this leverage to have a positive influence on a big > distribution people actually use. In the long term, making OpenBSD > better will benefit those who are scared of making the switch. We all > know that OpenBSD is much further on the convergence line towards an > ideal operating system for server and desktop applications than Linux > and its messy userland. I don't think that having a very compact linux based stali src is more complex to maintain than trying to change little things in OpenBSD. The purpose of OpenBSD nowadays has barely changed than its purpose 10 years ago. It is primarily used at the border of networks I guess. The purpose of stali could be a nice IoT platform, with a completely different embedded scope. The purpose of the next leet linux distro could be the work environment for the senior hacker. It could also well be OpenBSD or FreeBSD, I don't mind. But I also don't think that monoculturalism in terms of distros or OSes is a good thing. Every little effort has its pros and cons. OpenBSD is quite a decent OS overall, but for most it might be rather limiting in scope. Unfortunately I also see the BSDs on the dying path. You could also suggest 9front or another Plan 9 bastardisation. It will work in a specific scope, but won't give you much flexibility outside the beauty of its world. With stali I'm pretty much compact-userland-only oriented and benefit from the kernel stuff others do. In BSD/P9 lands one is more beauty-system oriented, but a loser when forced to use some kind of commercial or semi-commercial software. If the suckless community favours an own distro approach, I would definitely start on the Linux path as well. There is no big reason trying to change the BSDs for the better hardware support. That race was lost already 15 years ago. But I can understand your enthusiam for the BSD world. I have been there 15 years ago as well. Cheers, Anselm
[dev] [st] Release planned?
Dear suckless folks, st 0.6 was released in June 2015, that means over a year ago. Since then, there were another 76 commits included into the master branch. ``` $ git describe --tags origin/master 0.6-76-g308bfbf ``` Are there plans to get release 0.7(?) out, so that users, not building from repository, but from release source archives, can profit from them? Best regards, Paul
Re: [dev] [st] Release planned?
Greetings. On Thu, 11 Aug 2016 16:17:30 +0200 Paul Menzel wrote: > Dear suckless folks, > > > st 0.6 was released in June 2015, that means over a year ago. > > Since then, there were another 76 commits included into the master branch. > > ``` > $ git describe --tags origin/master > 0.6-76-g308bfbf > ``` > > Are there plans to get release 0.7(?) out, so that users, not building > from repository, but from release source archives, can profit from them? There shouldn’t be users not building from the repository. Sincerely, Christoph Lohmann
Re: [dev] [st] Release planned?
Christoph Lohmann writes: > Greetings. > > On Thu, 11 Aug 2016 16:17:30 +0200 Paul Menzel wrote: > > Dear suckless folks, > > > > > > st 0.6 was released in June 2015, that means over a year ago. > > > > Since then, there were another 76 commits included into the master branch. > > > > ``` > > $ git describe --tags origin/master > > 0.6-76-g308bfbf > > ``` > > > > Are there plans to get release 0.7(?) out, so that users, not building > > from repository, but from release source archives, can profit from them? > > There shouldn’t be users not building from the repository. Ah, there's the suckless lunacy I've missed so much.
Re: [dev] [st] Release planned?
On Thu, 11 Aug 2016 16:07:29 +0200 Paul Menzel wrote: Hey Paul, > Are there plans to get release 0.7(?) out, so that users, not > building from repository, but from release source archives, can > profit from them? just FIY, Christoph tagged a 0.7 release a few minutes ago[0]. Cheers FRIGN [0]:http://git.suckless.org/st/commit/?id=6e79e8357ed1987a7f7a52cc06249aadef478041 -- FRIGN
Re: [dev] [st] Release planned?
> On 11 Aug 2016, at 16:17, Christoph Lohmann <2...@r-36.net> wrote: > On Thu, 11 Aug 2016 16:17:30 +0200 Paul Menzel wrote: >> Dear suckless folks, >> >> >> st 0.6 was released in June 2015, that means over a year ago. >> >> Since then, there were another 76 commits included into the master branch. >> >> ``` >> $ git describe --tags origin/master >> 0.6-76-g308bfbf >> ``` >> >> Are there plans to get release 0.7(?) out, so that users, not building >> from repository, but from release source archives, can profit from them? > > There shouldn’t be users not building from the repository. The release source comes out of the repository, so everything fine... eeeh ;) Seriously, you really want to start again the same stupid discussion about releases and version numbers, which last time led to splitting the mailing lists into dev and hackers? Let’s summarise what we have: There are users who build from release sources and there is nothing wrong with it. There are also packages available for most major distributions build from the release tarballs, and users which use these packages, again nothing wrong with it. If you do not want this, you may really want to remove all existing tarballs and releases, from suckless.org to state clear that these are not wanted and to avoid the above, but why did you provided them in the first then? ... and even if you do not provide them any longer, people will likely start rolling/providing and tagging own releases. For various reasons there are people which expect and want releases.
Re: [dev] [st] Release planned?
On Thu, 11 Aug 2016 16:37:39 +0200 Joerg Jung wrote: Hey Joerg, > Seriously, you really want to start again the same stupid discussion > about releases and version numbers, which last time led to splitting > the mailing lists into dev and hackers? chill down, you should know by know that Christoph is trolling more than 50% of the time. > Let’s summarise what we have: > There are users who build from release sources and there is nothing > wrong with it. There are also packages available for most major > distributions build from the release tarballs, and users which use > these packages, again nothing wrong with it. > > If you do not want this, you may really want to remove all existing > tarballs and releases, from suckless.org to state clear that these > are not wanted and to avoid the above, but why did you provided them > in the first then? ... and even if you do not provide them any > longer, people will likely start rolling/providing and tagging own > releases. For various reasons there are people which expect and want > releases. I agree with you there, but this is a limitation of the package managers. For more complex projects, going bleeding edge is not the way to go for "normal" users, but can we even talk of normal users wrt suckless software? It's a matter of responsibility, but I understand the notion of even professional users to run a stable version at the end of the day, just to make sure. It also makes it simpler to apply patches to it, as soon as patches are released for a stable version (I'm on it). Cheers FRIGN -- FRIGN
[dev] [st] 0.7 release
Greetings. I am proud to announce the common effort of many of you who made it pos‐ sible to release st 0.7 (»à Nuces«). Much has changed, so don’t forget to update your config.h. Think before you post such bug reports. I am st surfcon1 (thus the codename) and ready to fight. What has changed: * Big input and output to the escape code parser have been fixed. This was an addition to the copy and paste fix of the last release. * Many comments to the config.def.h were added to make the complexity of terminals easier to grasp. Terminals are still complex and not easy to understand. * -T is the same as -t for compatibility reasons – to set the title of the window. * You can now define the mouse shape, mouse background and mouse foreground color. * Fixes in the UTF-8 wide character handling were applied. * Invalid UTF-8 characters are handled better. * There is now more documentation for the -l option, which is the way to make st directly connect to some other pseudo terminal or a serial line. * You can now send a break to the terminal. * The default stty args have been changed. Look into the source for details, if you depend on them in your setup. * The default font is now using antialias and autohint. * The libXext dependency has been removed. * Some eastereggs were added. You may find them easily. * -n has been introduced for setting the application class. This is useful for complex st setups in dwm. * Some backspace fixes. Please still not forget to read up all the history books on backspace behaviour of the time and in different implementations before you file any bug on it. This is a requirement. * DPI handling is optimized. Many patches were incorporated by many contributes. Thank you for help‐ ing making st the tool which makes our life easier! Sincerely, Christoph Lohmann [0] http://st.suckless.org/ [1] http://dl.suckless.org/st/st-0.7.tar.gz
Re: [dev] [st] Release planned?
Greetings. On Thu, 11 Aug 2016 16:56:37 +0200 Joerg Jung wrote: > > > On 11 Aug 2016, at 16:17, Christoph Lohmann <2...@r-36.net> wrote: > > On Thu, 11 Aug 2016 16:17:30 +0200 Paul Menzel > > wrote: > >> Dear suckless folks, > >> > >> > >> st 0.6 was released in June 2015, that means over a year ago. > >> > >> Since then, there were another 76 commits included into the master branch. > >> > >> ``` > >> $ git describe --tags origin/master > >> 0.6-76-g308bfbf > >> ``` > >> > >> Are there plans to get release 0.7(?) out, so that users, not building > >> from repository, but from release source archives, can profit from them? > > > > There shouldn’t be users not building from the repository. > > The release source comes out of the repository, so everything fine... eeeh ;) > > Seriously, you really want to start again the same stupid discussion about > releases and > version numbers, which last time led to splitting the mailing lists into dev > and hackers? > > Let’s summarise what we have: > There are users who build from release sources and there is nothing wrong > with it. > There are also packages available for most major distributions build from the > release > tarballs, and users which use these packages, again nothing wrong with it. > > If you do not want this, you may really want to remove all existing tarballs > and releases, > from suckless.org to state clear that these are not wanted and to avoid the > above, but > why did you provided them in the first then? > ... and even if you do not provide them any longer, people will likely start > rolling/providing > and tagging own releases. For various reasons there are people which expect > and want > releases. You are using Apple Mail. Please stop talking. It’s not useful at all. Sincerely, Christoph Lohmann
Re: [dev] [st] Release planned?
> On 11 Aug 2016, at 16:56, Christoph Lohmann <2...@r-36.net> wrote: > > You are using Apple Mail. I know. Not sure why this is relevant to this thread. [I also use mutt, mailx, surf, monit, sct, sxiv, dwm, amethyst, vim, sometimes firefox, and a very long list of other small pieces and a few large hunks of software.] > Please stop talking. It’s not useful at all. Ok. However, thanks for the release!
[dev] st lack of scrollback
I realize it's a non-goal I realize there are patches that sort of work (still jumps to bottom on output unfortunately) It should be a goal because it's generally desirable and the alternative mentioned on the web page isn't. I use st because it let me control fonts precisely on new high-res monitor. I couldn't easily tell how to hack gnome-terminal to do that or I would still use it. Britton
Re: [dev] st lack of scrollback
Greetings. On Thu, 11 Aug 2016 19:42:13 +0200 Britton Kerin wrote: > I realize it's a non-goal Then why do you send this useless mail? > I realize there are patches that sort of work (still jumps to bottom > on output unfortunately) Fix the patches. > It should be a goal because it's generally desirable and the > alternative mentioned on the web page isn't. Are you some spy sent by Apple to get consumerism into the last places of earth? You are causing global warming, so stop it. > I use st because it let me control fonts precisely on new high-res > monitor. I couldn't easily tell how to hack gnome-terminal to do that > or I would still use it. The same flexibility is what makes st not having scrollback. Sincerely, Christoph Lohmann
Re: [dev] [sxiv] Discussion
Marc Collin wrote: For wallpaper I suggest bgs. https://github.com/Gottox/bgs It doesn't work well with compton. Cág
Re: [dev] st lack of scrollback
On Thu, Aug 11, 2016 at 9:42 AM, Christoph Lohmann <2...@r-36.net> wrote: > Greetings. > > On Thu, 11 Aug 2016 19:42:13 +0200 Britton Kerin > wrote: >> I realize it's a non-goal > > Then why do you send this useless mail? Because I care enough to call bs on stupid stuff, you should be grateful >> I realize there are patches that sort of work (still jumps to bottom >> on output unfortunately) > > Fix the patches. I have no idea how and I haven't found suckless people fun to work with >> It should be a goal because it's generally desirable and the >> alternative mentioned on the web page isn't. > > Are you some spy sent by Apple to get consumerism into the last places > of earth? You are causing global warming, so stop it. > >> I use st because it let me control fonts precisely on new high-res >> monitor. I couldn't easily tell how to hack gnome-terminal to do that >> or I would still use it. > > The same flexibility is what makes st not having scrollback. Nonsense Britton
Re: [dev] st lack of scrollback
On 2016-08-11 20:32, Britton Kerin wrote: I realize it's a non-goal I realize there are patches that sort of work (still jumps to bottom on output unfortunately) It should be a goal because it's generally desirable and the alternative mentioned on the web page isn't. I use st because it let me control fonts precisely on new high-res monitor. I couldn't easily tell how to hack gnome-terminal to do that or I would still use it. Britton treat it the way you treat nonscrolling terminals, less(1) Raiz
Re: [dev] st lack of scrollback
On Thu, Aug 11, 2016 at 8:36 PM, Britton Kerin wrote: >> Fix the patches. > > I have no idea how and I haven't found suckless people fun to work with > Interesting how you switch a virtue (writing code) with laziness (telling others where things go). Tell me more about your management virtues. > Nonsense > See above. You haven't tried to solve a problem, you only created one, and really, it's yours. cheers! mar77i
Re: [dev] st lack of scrollback
Hi, 2016-08-11 17:32 GMT, Britton Kerin : > It should be a goal because it's generally desirable and the > alternative mentioned on the web page isn't. I've fulfilled that desire by using tmux inside st.
Re: [dev] st lack of scrollback
For me it started playing nicely only with wrapper to tmux, though. Because I didn't liked how sessions stayed alive after killing terminals directly through window manager. $ st -e r.tmux $ cat r.tmux #!/bin/bash -e trap "tmux kill-session -t st-$$" INT TERM EXIT tmux new-session -s st-$$ "$@" On Thu, Aug 11, 2016 at 07:31:50PM +, Teodoro Santoni wrote: > Hi, > > 2016-08-11 17:32 GMT, Britton Kerin : > > It should be a goal because it's generally desirable and the > > alternative mentioned on the web page isn't. > > I've fulfilled that desire by using tmux inside st. >
Re: [dev] st lack of scrollback
Greetings. On Thu, 11 Aug 2016 22:35:26 +0200 Amer wrote: > For me it started playing nicely only with wrapper to tmux, though. > Because I didn't liked how sessions stayed alive after killing > terminals directly through window manager. > > $ st -e r.tmux > > $ cat r.tmux > #!/bin/bash -e > trap "tmux kill-session -t st-$$" INT TERM EXIT > tmux new-session -s st-$$ "$@" Add this to your $HOME/.tmux.conf: set -g destroy-unattached on Sincerely, Christoph Lohmann
[dev] [st] most suckless way to scroll & multiplex
Hey all! I'm new to suckless and trying to learn the suckless ways... I am accustomed to having scrolling and multiplexing (in xfce4-terminal). To get these the suckless way should I: a. use tmux/screen b. use tabbed and the st scrollback patch c. something else Thanks in advance for any advice! Joseph
Re: [dev] st lack of scrollback
Thanks for idea, but this option doesn't feet the purpose at all. It will always destroy any unattached session. Even on manual detach. And what now? Manually switch option each time before detach? Bind switching to 'd' key and hope it's robust enough solution? Moreover, what to do with global detached session, launched at boot, if I need it alive? Or how about SSH -- enable config option in dependence of using SSH or not? Managing all possible combination where detach and where not is much more painful then wrapper. On Thu, Aug 11, 2016 at 10:35:26PM +0200, Christoph Lohmann wrote: > Add this to your $HOME/.tmux.conf: > > set -g destroy-unattached on
Re: [dev] [st] most suckless way to scroll & multiplex
Joseph Graham wrote: > I am accustomed to having scrolling and multiplexing (in > xfce4-terminal). > To get these the suckless way should I: > a. use tmux/screen > b. use tabbed and the st scrollback patch > c. something else Heyho Joseph, for local multiplexing I use tabbed, since its keybindings are way easier to use (mod+BLA instead of mod+prefixkey, then BLA). For remote multiplexing I use tmux since it is mostly available on those systems and tmux is easier than opening up another ssh connection even with "ControlMaster auto". Scrollback I don't use as normal user, I just learned to use less for things which do not fit on one screen page. For root however I use tmux for it's scrollback (and multiplexing, no need to become root multiple times) feature, since there might be some unexpectedly long output on e.g. package updates, which I would want to scroll back to and I'm too lazy to always use less as root to be prepared for all corner-cases. --Markus
Re: [dev] [st] most suckless way to scroll & multiplex
On Thu, Aug 11, 2016 at 10:15:02PM +0100, Joseph Graham wrote: > I am accustomed to having scrolling and multiplexing (in xfce4-terminal). To > get these the suckless way should I: > a. use tmux/screen > b. use tabbed and the st scrollback patch > c. something else I'm not sure about "the suckless way" (or why you'd care), but... I use dvtm for scrolling. I think. If you set it right, you'll never notice it's there. Except when you try to scroll, and it works, instead of not not working. Yeah. For multiplexing, dwm.
Re: [dev] st lack of scrollback
On Thu, Aug 11, 2016 at 10:36:21AM -0800, Britton Kerin wrote: > On Thu, Aug 11, 2016 at 9:42 AM, Christoph Lohmann <2...@r-36.net> wrote: > > Greetings. > > > > On Thu, 11 Aug 2016 19:42:13 +0200 Britton Kerin > > wrote: > >> I realize it's a non-goal > > > > Then why do you send this useless mail? > > Because I care enough to call bs on stupid stuff, you should be grateful I know I'm grateful for the giggle. Cheers.
Re: [dev] [st] most suckless way to scroll & multiplex
On Fri, Aug 12, 2016 at 12:25 AM, Wolfgang Corcoran-Mathe wrote: > Hi Joseph, > I’ve been using the scrollback patch for local sessions recently > (terminal muxers inside window muxers seems overkill, and dvtm is > a _lot_ of code for just scrollback). If you need session management > and terminal muxing, there’s nothing better than dvtm/abduco. If all > you need is scrollback in a windowing environment, just patch st. > Actually, having the same kind of setup over ssh as well as locally is neat, to me a terminal session's visible back log might be all the context I need to go on where I left. Therefore I consistently ssh into tmux from tmux and don't mind having to type the prefix send-prefix keys to manipulate the remote session. To each their own, though. :) cheers! mar77i
Re: [dev] [sxiv] Discussion
[2016-08-11 21:13] Cág > > part text/plain 126 > Marc Collin wrote: > > > For wallpaper I suggest bgs. > > https://github.com/Gottox/bgs > > It doesn't work well with compton. Haven't tried with compton, but i use: https://github.com/ttzhou/setroot
Re: [dev] st lack of scrollback
On Thu, Aug 11, 2016 at 10:41:03PM +0300, Amer wrote: > For me it started playing nicely only with wrapper to tmux, though. > Because I didn't liked how sessions stayed alive after killing > terminals directly through window manager. > > $ st -e r.tmux > > $ cat r.tmux > #!/bin/bash -e > trap "tmux kill-session -t st-$$" INT TERM EXIT > tmux new-session -s st-$$ "$@" Cool hack, maybe we could add an "Idioms" section to the wiki to suggest this kind of things. -- mpu
