Re: [dev] [st][patch] scrollback buffer
On Mon, Oct 21, 2013 at 01:36:01PM +0200, v4hn wrote: > On Sat, Oct 19, 2013 at 02:17:54PM +0300, Edgaras wrote: > > Well it seems it does not work for me on raspberry, > > not that it is a huge loss, > > as I said I got used to this. > > The relevant kernel option is CONFIG_VGACON_SOFT_SCROLLBACK and > by default allocates 64K of RAM for software scrollback. > Maybe you dropped it for the pi? Premature optimization in my opinion. > screen consumes much more. > > Concerning the rest of the discussion: > > Using screen/tmux for scrollback is everything but suckless. > It's like using KDE to read your mail. > It tells you where your toothbrush is when you start cooking your meal. > > Oh, and screen tries to simulate multiple terminals. > It _multiplexes_ the history. > it's not meant to _provide_ it in the first place. > > Essentially, there are two suckless options here: > > - provide a scrollback with st and configurable scrollback size (hell, just > set it to 0 before compiling if you don't want it). The current behaviour > of the mousewheel is not even touched with the proposed patch. > The patch is clean and neat as Jochen spent quite some time on it. > - Write a clean standalone program which _only_ handles scrollback. > This scatters responsibility quite far even in terms of suckless, > but whatever. I only think this could result in worse code > than the current patch.. > > > v4hn Never said I have used tmux or screen. Last option is best. Things that I use: dtach for session handling. dvtm for terminal window managment (though iirc it has scrollback, ether way I don't use it). Also I dtach individual applications and not dvtm, since it is way more flexible that way. So separate program would could be good for people who need it. Otoh if we took my approach we would get this hipothetical app, dtach, dvtm, and real terminal, all being terminals... That isin't so cool. But as I said I most likelly wouldn't use such app. And having it separate would enable me to use it only when needed. I.E. some REPL/interactive applications as someone mentioned. Also speaking about wrappers there are even other kinds of wrappers: rlwrap/enhance for providing history and line editing to apps. And thees apps are cool too.
tinycore - Used to be [dev] I'm back
On Mon, Oct 21, 2013 at 1:15 PM, hiro <23h...@gmail.com> wrote: > Yeah, tinycore's biggest failure is that it's too difficult to find > the right man pages of certain packages. I knew tinycore wouldn't have docs included, they say so in the website, heck when i create a tcz for my self, i strip the docs out too (did i mention that?) so then...on a separate topic is stali meant to be a distro that sucks at being extensible? or is it meant to be a distro thats simple, lean and yet extensible. maybe i'm still not "hardcore" enough... > >> yes, i really enjoy the boot speed of tinycorelinux with the least deps for >> wifi, dwm (et. al.) , surf, acpi; but when i boot into this system its >> because i >> want to develop something, and so i always end up loading the rest of the >> world to build stuff. and i forget api's all them time, of which i end up >> using >> manuals for (which surely you've noticed everyone purposefully strips them >> out of packages (i do it too)... >> >> >
Re: [dev] I'm back
Yeah, tinycore's biggest failure is that it's too difficult to find the right man pages of certain packages. On 10/21/13, Carlos Torres wrote: > On Mon, Oct 21, 2013 at 8:41 AM, hiro <23h...@gmail.com> wrote: >> then simply don't use pure 64bit, why did you think that was a good idea? > > when i hopped on the pure 64 band wagon i "assumed" that the x86 packages > would have been rebuilt for pure 64 eventually... that was a big mistake on > my > part. > >> it's a feature (tm). works like intended. > > Yeah, its a feature i like. Maybe i'm just complaining about the lack of > packages for pure 64 :p, again i figured there was a community of pure64 > users that were contributing packages (slower but eventually - not true) > >> Just proves you have no taste. > > I tried other browsers before i went the with webkit/surf on this system, > i did most of my work with lynx, i tried opera, links2, w3m etc... none of > which anyone else was using on pure 64 :p (goes back to my initial bad > choice) > >>> I now cringe at the thought of rebuilding any suckless tool on >>> tinycorelinux for any >>> simple tweak. >> >> Granted, the everything-is-in-ram approach requires you to use special >> procedures to properly install anything. For many things that's too >> much of a trade-off. > > its a pretty big one. > >> I exploit this to make sure I don't have too many libraries installed >> so that autohell tools will build against the least amount of >> dependencies possible (without first having to find the right >> configure switches to manually turn features off). > > yes, i really enjoy the boot speed of tinycorelinux with the least deps for > wifi, dwm (et. al.) , surf, acpi; but when i boot into this system its > because i > want to develop something, and so i always end up loading the rest of the > world to build stuff. and i forget api's all them time, of which i end up > using > manuals for (which surely you've noticed everyone purposefully strips them > out of packages (i do it too)... > >
[dev] [PATCH] Sets _NET_WM_PID on startup
This sets _NET_WM_PID on startup. Not sure if any error handling's needed. I
used this for quite a while before I switched back to urxvt (for scrollback)
for the same purpose as the recent "in $PWD" thread.
---
st.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/st.c b/st.c
index 50b58a7..e3a7719 100644
--- a/st.c
+++ b/st.c
@@ -399,6 +399,7 @@ static int xsetcolorname(int, const char *);
static int xloadfont(Font *, FcPattern *);
static void xloadfonts(char *, int);
static int xloadfontset(Font *);
+static void xsetnetwmpid(void);
static void xsettitle(char *);
static void xresettitle(void);
static void xsetpointermotion(int);
@@ -3028,6 +3029,7 @@ xinit(void) {
xresettitle();
XMapWindow(xw.dpy, xw.win);
xhints();
+ xsetnetwmpid();
XSync(xw.dpy, 0);
}
@@ -3347,6 +3349,13 @@ xdrawcursor(void) {
}
}
+void
+xsetnetwmpid(void) {
+ Atom _NET_WM_PID = XInternAtom(xw.dpy, "_NET_WM_PID", False);
+ pid_t pid = getpid();
+ XChangeProperty(xw.dpy, xw.win, _NET_WM_PID, XA_CARDINAL, 32,
+ PropModeReplace, (unsigned char *)&pid, 1);
+}
void
xsettitle(char *p) {
--
1.8.4.1
Re: [dev] I'm back
On Mon, Oct 21, 2013 at 8:41 AM, hiro <23h...@gmail.com> wrote: > then simply don't use pure 64bit, why did you think that was a good idea? when i hopped on the pure 64 band wagon i "assumed" that the x86 packages would have been rebuilt for pure 64 eventually... that was a big mistake on my part. > it's a feature (tm). works like intended. Yeah, its a feature i like. Maybe i'm just complaining about the lack of packages for pure 64 :p, again i figured there was a community of pure64 users that were contributing packages (slower but eventually - not true) > Just proves you have no taste. I tried other browsers before i went the with webkit/surf on this system, i did most of my work with lynx, i tried opera, links2, w3m etc... none of which anyone else was using on pure 64 :p (goes back to my initial bad choice) >> I now cringe at the thought of rebuilding any suckless tool on >> tinycorelinux for any >> simple tweak. > > Granted, the everything-is-in-ram approach requires you to use special > procedures to properly install anything. For many things that's too > much of a trade-off. its a pretty big one. > I exploit this to make sure I don't have too many libraries installed > so that autohell tools will build against the least amount of > dependencies possible (without first having to find the right > configure switches to manually turn features off). yes, i really enjoy the boot speed of tinycorelinux with the least deps for wifi, dwm (et. al.) , surf, acpi; but when i boot into this system its because i want to develop something, and so i always end up loading the rest of the world to build stuff. and i forget api's all them time, of which i end up using manuals for (which surely you've noticed everyone purposefully strips them out of packages (i do it too)...
Re: [dev] I'm back
On 2013-10-21 16:28, koneu wrote: > On Oct 21, 2013, at 10:41 AM, hiro <23h...@gmail.com> wrote: > > I hope it scared you away from webkit also. > > Compared to Gecko (XUL, lol!), the only other web engine as popular as > WebKit, WebKit is a blessing, especially WebCore. I think only Hubbub beats > it in speed. Speed is nowhere near as important as correctness (I have never used Hubbub, so I cannot comment on whether I think it is "correct" or not). pgpOpeQrjqTuA.pgp Description: PGP signature
Re: [dev] I'm back
On Oct 21, 2013, at 10:41 AM, hiro <23h...@gmail.com> wrote: > I hope it scared you away from webkit also. Compared to Gecko (XUL, lol!), the only other web engine as popular as WebKit, WebKit is a blessing, especially WebCore. I think only Hubbub beats it in speed. Maybe it's time surf switched to swk + Hubbub? :P -- koneu
Re: [dev] [dwm] Multi-seat with dwm in a single X server
> Can you share your patches, please? I'm quite busy right now, and the code is so customized that making a patch right now takes some time. I'll start later tonight and see if I can manage a clean patch quickly. -- Raimundo Martins
Re: [dev] [st][patch] scrollback buffer
On Sat, Oct 19, 2013 at 02:17:54PM +0300, Edgaras wrote: > Well it seems it does not work for me on raspberry, > not that it is a huge loss, > as I said I got used to this. The relevant kernel option is CONFIG_VGACON_SOFT_SCROLLBACK and by default allocates 64K of RAM for software scrollback. Maybe you dropped it for the pi? Premature optimization in my opinion. screen consumes much more. Concerning the rest of the discussion: Using screen/tmux for scrollback is everything but suckless. It's like using KDE to read your mail. It tells you where your toothbrush is when you start cooking your meal. Oh, and screen tries to simulate multiple terminals. It _multiplexes_ the history. it's not meant to _provide_ it in the first place. Essentially, there are two suckless options here: - provide a scrollback with st and configurable scrollback size (hell, just set it to 0 before compiling if you don't want it). The current behaviour of the mousewheel is not even touched with the proposed patch. The patch is clean and neat as Jochen spent quite some time on it. - Write a clean standalone program which _only_ handles scrollback. This scatters responsibility quite far even in terms of suckless, but whatever. I only think this could result in worse code than the current patch.. v4hn pgpgFHK_Vb_Bx.pgp Description: PGP signature
Re: [dev] I'm back
On 10/20/13, Carlos Torres wrote: > On Tue, Aug 13, 2013 at 6:24 PM, Carlos Torres > wrote: >> Glad you changed your mind on Android core. >> Consider looking at tinycorelinux; it too is very simple. simpler than >> crux. > > hmm, after tooling around with tinycorelinux, i think its use > doesn't make sense > as a day-to-day distro. it would suit well a specific purpose or an > embeded system. > So i'm actually removing my "+" on tinycorelinux. I went for a pure > 64bit system > and that was hellish. then simply don't use pure 64bit, why did you think that was a good idea? > since there are barely any packages for it! soo it's a feature (tm). works like intended. > i had to build > webkit and its horrid dependencies from scratch... that basically > scared my away... I hope it scared you away from webkit also. > granted i completed the daunting task to the end. Just proves you have no taste. > I now cringe at the thought of rebuilding any suckless tool on > tinycorelinux for any > simple tweak. Granted, the everything-is-in-ram approach requires you to use special procedures to properly install anything. For many things that's too much of a trade-off. I exploit this to make sure I don't have too many libraries installed so that autohell tools will build against the least amount of dependencies possible (without first having to find the right configure switches to manually turn features off). You might be able to use chroot for the task, but to me that's also additional complexity. I now just use a basic tinycore install - either in a VM or just by rebooting into it - which makes these tasks seamless. It's also simple to just boot up and load a different library version without having to memorize how to specify some special library path flags for each build system out there.
Re: [dev] Some thoughts about XML
It seems like some subscribers haven't read the bible of suckless yet. http://harmful.cat-v.org/software/ and http://harmful.cat-v.org/software/xml/ On 10/20/13, Szymon Olewniczak wrote: > On Sun, Oct 20, 2013 at 01:02:34AM +0200, Dmitrij D. Czarkoff wrote: >> Evan Buswell said: >> > But OTOH, I do like the idea of separating the translation-to-html bit >> > from the generate-sensible-output bit. XSLT may have done this poorly, >> > but it's on the right track (and what else works better for this, Awk? >> > Perl? m4?). I mean, I take the point that we can't really make the web >> > stack all that much better, but at least we can containerize suck? >> > Yes? >> >> Containerize suck of web stack? It is already containerized in browsers >> - choose the one that sucks less. >> >> See, the problem with web stack are not somewhere between the stack and >> the rest of your software and data. You readily may have your data in >> whatever format you want and share it via whatever protocol you like. >> Eg. you may have a bunch of JSON files accessible via their URLs as they >> are and via werc (or your custom CGI script) as HTML. The problem with >> web stack is the ugliness of web stack itself, and there is no >> workaround for that. > But think that we need to find something between. If we develop our > own window manager on top of X11(which itself isn't very suckless), its > useful beouse it uses X11 (something that is standrad now) and it let us > use all X11 apps in a less sucky way. > > So I think that saying - all "modern web" sucks(which is right in fact) - > let's make something completly diffirent is like saying - X11 > sucks, let's create something that can replace it. > > I'm serching for something similar as dwm in the web services world. > We cannnot force everyone to use something diffirent than HTML and HTTP > becouse noone want a huge revolution(users, web browsers and http > servers developers). But maybe we can use this tools to create something > less sucky, something that would make the web a better place. > > I don't want to starting a new project that will make the web > worst place. I believe that web developdent can be done better rigth now and > > I want to show that it's possible. > > BR, > Szymon > >
