Re: [dev] [st] RFC halt function
On 2013-04-25 20:05, Christoph Lohmann wrote: > while trying to copy some stuff from iotop I came to the idea of having > some ??halt?? function in st. This is like the ??halt?? in 9term, where ev??? > erything will stand still but the terminal is working on the output in > the background. Why not let tmux or screen handle that? Does st really need an (xon/xoff)++ feature?
Re: [dev] [st] RFC halt function
2013/4/25, Christoph Lohmann <2...@r-36.net>: > Greetings. > > On Thu, 25 Apr 2013 20:15:37 +0200 Nimrod Omer > wrote: >> On Thu, Apr 25, 2013 at 11:05 AM, Christoph Lohmann <2...@r-36.net> wrote: >> >> > Anyone has ever needed such a function and considers it worth to >> > be >> > added to st? >> > >> >> Oh, I've needed such a function--but I've also needed a scroll-back >> buffer. > > Nice joke. Try to implement a scrollback buffer without bugs and flaw‐ > lessly. Did you see scrollback buffer implementation in http://repo.or.cz/w/k8sterm.git ? What you think about it?
Re: [dev] [st] RFC halt function
On Thu, Apr 25, 2013, at 14:15, Christoph Lohmann wrote: > Nice joke. Try to implement a scrollback buffer without bugs and flaw‐ > lessly. > > > Sincerely, > > Christoph Lohmann The buffer's the easy part. What's hard is actually implementing scrolling. I've been tempted to hack in a way to have the mouse wheel transparently tell tmux to scroll up and down through its modal scrolling feature.
Re: [dev] [st] RFC halt function
Greetings. On Thu, 25 Apr 2013 20:15:37 +0200 Nimrod Omer wrote: > On Thu, Apr 25, 2013 at 11:05 AM, Christoph Lohmann <2...@r-36.net> wrote: > > > Anyone has ever needed such a function and considers it worth to be > > added to st? > > > > Oh, I've needed such a function--but I've also needed a scroll-back buffer. Nice joke. Try to implement a scrollback buffer without bugs and flaw‐ lessly. Sincerely, Christoph Lohmann
Re: [dev] [st] RFC halt function
On Thu, Apr 25, 2013 at 11:05 AM, Christoph Lohmann <2...@r-36.net> wrote: > Anyone has ever needed such a function and considers it worth to be > added to st? > Oh, I've needed such a function--but I've also needed a scroll-back buffer.
[dev] [st] RFC halt function
Greetings comrades, while trying to copy some stuff from iotop I came to the idea of having some »halt« function in st. This is like the »halt« in 9term, where ev‐ erything will stand still but the terminal is working on the output in the background. Anyone has ever needed such a function and considers it worth to be added to st? The implementation details would be a temporary screen which holds the current buffer copy. On a certain shortcut st would switch back to nor‐ mal mode. Sincerely, Christoph Lohmann
Re: [dev] st: Large pile of code
Greetings. On Thu, 25 Apr 2013 17:58:17 +0200 Carlos Torres wrote: > On Thu, Apr 25, 2013 at 2:59 AM, Alexander Sedov > wrote: > > Code should look compact to keep people from adding bloat. Multiple > > files by themselves add nothing to understanding, other than need to > > constantly switch contexts when one file's function is called from > > other file's. > > > I think you should define what "switch contexts" means to you. to me > its clear that terminal emulation is one context and terminal > rendering is another, and having it all mangled together does not make > it one context (unless your context is less concrete and refers to > terminals in general) and forces more context switching than sorting > it out into two different buckets (files w/e) in fact because its > separated i would argue that its easier to "see the forest from the > trees" and prevent bloat. Really, I am not planning to extend st to much more. The problem why st isn’t finished is the graphical stack of Linux, which sucks at printing UTF‐8 strings in monospace fonts. Now all of this has to be emulated. When double‐width and proper diacritics work st will be considered sta‐ ble and a true terminal emulator. Then this is set into stone and my in‐ terest is focused to different projects, like to get my mail client ready for release. For the file split: No. There is not much code addition added. Senseless idiocracy like spreading the terminal paradigm more widely won’t help here. St is the widget and st is the emulator you can embed everywhere using xembed. For a Wayland port you will need to modify huge chunks of code anways. A term.c won’t help you there much. Sincerely, Christoph Lohmann
Re: [dev] st: Large pile of code
2013/4/25 Roberto E. Vargas Caballero : > When you want pass it any type of data? (of course, without using typeof) Do you already want it? Also, you can have multiple functions, as math.h does.
Re: [dev] st: Large pile of code
On Thu, Apr 25, 2013 at 2:59 AM, Alexander Sedov wrote: > 2013/4/25 Kent Overstreet : >> So, to restate - code should be harder to understand to keep people >> from contributing? > Code should look compact to keep people from adding bloat. Multiple > files by themselves add nothing to understanding, other than need to > constantly switch contexts when one file's function is called from > other file's. > I think you should define what "switch contexts" means to you. to me its clear that terminal emulation is one context and terminal rendering is another, and having it all mangled together does not make it one context (unless your context is less concrete and refers to terminals in general) and forces more context switching than sorting it out into two different buckets (files w/e) in fact because its separated i would argue that its easier to "see the forest from the trees" and prevent bloat.
Re: [dev] [dwm] usage, was "dwm 6.0 - separate taglists for muli-monitor setup"
[2013-04-25 14:27] Markus Teich > > I have just added the link to the "Related discussion" paragraph. Thanks. That was exactly what I wanted (and not wanted to do myself). meillo
Re: [dev] [dwm] usage, was "dwm 6.0 - separate taglists for muli-monitor setup"
I have just added the link to the "Related discussion" paragraph. --Markus Am 25.04.2013 13:40, schrieb Martti Kühne: On Thu, Apr 25, 2013 at 1:28 PM, Raphaël Proust wrote: [0]: http://www.wongdev.com/blog/2013/01/24/dwm-tags-are-not-workspaces/ I'd suggest you add only a link, that would honor the writer and his blog most. ;-) cheers! mar77i
Re: [dev] [dwm] usage, was "dwm 6.0 - separate taglists for muli-monitor setup"
On Thu, Apr 25, 2013 at 1:28 PM, Raphaël Proust wrote: >>> [0]: http://www.wongdev.com/blog/2013/01/24/dwm-tags-are-not-workspaces/ I'd suggest you add only a link, that would honor the writer and his blog most. ;-) cheers! mar77i
Re: [dev] [dwm] usage, was "dwm 6.0 - separate taglists for muli-monitor setup"
On Thu, Apr 25, 2013 at 11:51 AM, markus schnalke wrote: > [2013-04-23 20:34] Markus Teich >> >> [0]: http://www.wongdev.com/blog/2013/01/24/dwm-tags-are-not-workspaces/ > > I like this text a lot. Please add it to the website. I like it too. If you want it added to the website, use http://suckless.org/wiki Cheers, -- __ Raphaël Proust
Re: [dev] st: Large pile of code
On Thu, Apr 25, 2013 at 12:38:02PM +0200, markus schnalke wrote: > [2013-04-24 17:14] random...@fastmail.us > > > > A) Why do min and max need to be macros at all? > > That's the point, IMO. All the problems are introduced by performance > optimizations that might not even necessary. If you write it as a > function you simply don't need to care for double-evaluation. It will > just work as expected ... and in many cases the compiler will do the > optimization for you. Show me the case that really needs a macro! When you want pass it any type of data? (of course, without using typeof)
Re: [dev] [dwm] usage, was "dwm 6.0 - separate taglists for muli-monitor setup"
[2013-04-23 20:34] Markus Teich > > [0]: http://www.wongdev.com/blog/2013/01/24/dwm-tags-are-not-workspaces/ I like this text a lot. Please add it to the website. meillo
Re: [dev] st: Large pile of code
[2013-04-24 17:14] random...@fastmail.us > > A) Why do min and max need to be macros at all? That's the point, IMO. All the problems are introduced by performance optimizations that might not even necessary. If you write it as a function you simply don't need to care for double-evaluation. It will just work as expected ... and in many cases the compiler will do the optimization for you. Show me the case that really needs a macro! meillo
Re: [dev] st: Large pile of code
one liners -> one filers ?
Re: [dev] st: Large pile of code
On Wed, Apr 24, 2013 at 11:59 PM, Alexander Sedov wrote: > 2013/4/25 Kent Overstreet : >> So, to restate - code should be harder to understand to keep people >> from contributing? > Code should look compact to keep people from adding bloat. Multiple > files by themselves add nothing to understanding, other than need to > constantly switch contexts when one file's function is called from > other file's. The split wasn't arbitrary, look at how many non static functions there are in term.c. The terminal emulation code has nothing to do with how it's rendered; term.c could conceivably be used for something like tmux (and reducing the number of vt100 emulator implementations out there would be a good thing!). And dividing the code into logically unrelated parts makes it easier to understand and figure out what various code is trying to do. Anyways, either you value readability and understandability or you don't. If you don't... I'm not going to cry if my code doesn't get merged in, it won't bother me in the slightest, and you can keep doing things how you see fit. *shrug*
