Re: [dev] Launching new terminals in $PWD
On 2013-10-20 23:31, ad...@dav1d.de wrote: > Ever tried to launch that through sh?: > > /bin/sh -c "urxvt -cd `pwd`" Please read the rest of the thread before posting. If you had done so, you would know that: - This question has already been answered; - This answer was already given; - This answer is wrong. pgpA9kZxqtENW.pgp Description: PGP signature
Re: [dev] Launching new terminals in $PWD
Am 2013-10-18 11:14, schrieb Manolo Martínez: Hello, I was trying to create a shortcut to launch new terminals in my current working directory. I've seen there's a two year-old thread, and a patch, about this, which probably means that the kind of easy solutions I've been trying cannot work. Still, I wonder, wouldn't it be possible to use config.h to bind a key combination to, say, "urxvt -cd $PWD", or "pwd | urxvt", or "urxvt -cd `pwd`". None of these options work, and I am not sure why -- I guess pipes cannot be used? And env variables are somehow not read? What am I doing wrong here? Cheers, Manolo Ever tried to launch that through sh?: /bin/sh -c "urxvt -cd `pwd`" - David
Re: [dev] Some thoughts about XML
Szymon Olewniczak said: > I'm serching for something similar as dwm in the web services world. The thing you were talking about initially - if I got you right - is another CMS engine. You may look at werc for a good implementation of this idea. If you want something more lightweight, you may have your data in JSON and provide URLs for raw data together with HTML presentation either via JS or your custom CGI script. > 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). What are you talking about? We are stuck with HTML+JS+CSS over HTTP with no possible workaround. (Apart from re-doing the web stack from scratch and mirroring it with HTML+JS+CSS over HTTP for unbelievers.) > But maybe we can use this tools to create something less sucky, > something that would make the web a better place. "Better place" undefined. Really, to date you suggested XML+XSLT, which doesn't sound like a workable replacement, leave alone "suckless" bit. -- Dmitrij D. Czarkoff
Re: [dev] [st] [patch] Cleanup config.def.h, eliminate mappedkeys, simplify matching.
On Sun, Oct 20, 2013 at 9:51 AM, Roberto E. Vargas Caballero wrote: > I think this patch is correct, because XK_NO_MOD is 0, so if there is > some modifier then 'state == mask' will be false. After the simplification, > match is too short and does nothing, so I think it should be > merged into kmap. Note that match() is used in four places, so I can't merge it into kmap(). On Sat, Oct 19, 2013 at 12:43 PM, Alexander S. wrote: > However, I do not like using != as a logical operator. I'd suggest > using (IS_SET(MODE_APPKEYPAD) ? kp->keypad < 0 : kp->keypad > 0), I've done this, but I'm not sure it reads as well. The existing version first checks the *kp fields because if they are zero, the is no need to peek at term.mode. -Mark 0001-Simplify-logic-in-match.patch Description: Binary data 0002-Simplify-logic-in-kmap.patch Description: Binary data
Re: [dev] [dwm] Multi-seat with dwm in a single X server
> Multi-seat with full 3d acceleration. Is this something of interest to you? I am very interested :) Can you share your patches, please? I would also be very interested in your specific setup and if you had to tweak e.g. xorg configuration.
Re: [dev] [st] [patch] Cleanup config.def.h, eliminate mappedkeys, simplify matching.
On Sun, Oct 20, 2013 at 9:51 AM, Roberto E. Vargas Caballero wrote: > Please send atomic patches Sorry for the mess, I've broken these changes out now. > In this case the tab part is not correct, because we use > smart tabs in the project, tabs for indentation and spaces for > alignment. Yes, mshortcuts[] and shortcuts[] in config.def.h are using tabs for alignment instead of spaces. Isn't that against the style? > appkey and appcursor have the 'app' prefix because > they are related to the application modes of the terminal OK, I've kept the names from st.c and changed only config.def.h. -Mark 0001-Fix-comments-in-config.def.h-to-match-field-names.patch Description: Binary data 0002-Replace-alignment-tabs-with-spaces.patch Description: Binary data 0003-Use-designators-to-clean-up-definitions-in-config.de.patch Description: Binary data
Re: [dev] I'm back
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. since there are barely any packages for it! soo i had to build webkit and its horrid dependencies from scratch... that basically scared my away... granted i completed the daunting task to the end. I now cringe at the thought of rebuilding any suckless tool on tinycorelinux for any simple tweak. --Carlos
Re: [dev] Some thoughts about XML
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
Re: [dev] [st] [patch] Cleanup config.def.h, eliminate mappedkeys, simplify matching.
Greetings. On Sun, 20 Oct 2013 18:05:09 +0200 Mark Edgar wrote: > However, since (I'm assuming) the only point of mappedkeys[] or > sorting key[] is for performance, and since there is no measurable > performance difference among these three versions, I think the > simplest code should win. Of course, it's possible that on someone's > system there is a noticeable performance difference, but this would be > surprising to me. On my system, making one million calls to kmap() and > checking all key[] entries on each call takes 0.7s. I don't know > anyone who can type that fast. :) Are you on some kind of drugs? That optimisation there is for me, be‐ cause I type faster than that. Otherwise things get too slow in st. Please stop pushing your Java mentality that created suckless into suck‐ less projects. Yes, there are people stronger, more fit and more devel‐ oped than you. The patch is rejected. Sincerely, Christoph Lohmann
Re: [dev] [st] [patch] Cleanup config.def.h, eliminate mappedkeys, simplify matching.
On Sat, Oct 19, 2013 at 12:43 PM, Alexander S. wrote: > Why removing mappedkeys? Sure, there may be no visible regression, but > checking every keypress against key bindings seems unreasonable to me. On Sun, Oct 20, 2013 at 9:11 AM, Roberto E. Vargas Caballero wrote: > I don't like the actual solution of this problem, but we > need some way of avoiding check all the keys. My thought process was that it seemed strange to search one table before searching another table, as it unnecessarily complicates the code and the config. I assumed mappedkeys[] exists only for performance reasons, and so I had first thought to replace mappedkeys with a sorted key[] table so that searches can be aborted early. When I found that I could not detect any performance difference between searching a sorted key[] and an unsorted key[], I decided to remove the sorting as well. I've attached this version of the patch for reference. It's maybe a bit nice that sorting also removes the need to be careful about the order of key definitions in config.h with respect to XK_ANY_MOD. It's also less code than the existing mappedkeys[] code. However, since (I'm assuming) the only point of mappedkeys[] or sorting key[] is for performance, and since there is no measurable performance difference among these three versions, I think the simplest code should win. Of course, it's possible that on someone's system there is a noticeable performance difference, but this would be surprising to me. On my system, making one million calls to kmap() and checking all key[] entries on each call takes 0.7s. I don't know anyone who can type that fast. :) -Mark 0001-Replace-mappedkeys-with-sorting-on-key.patch Description: Binary data
Re: [dev] [sbase] S_ISVTX patches
On Sun, Oct 20, 2013 at 11:11:21AM +0200, Markus Wichmann wrote: > Hi all, > > as previously threatened, here are some git patches. Hope that helps. Applied, thanks. In the future please use tabs instead of spaces (I've manually fixed your patches for now). Thanks, sin
[dev] [sbase] S_ISVTX patches
Hi all,
as previously threatened, here are some git patches. Hope that helps.
Ciao,
Markus
>From dfe485c4298aa8572f7534e19336b682239d0879 Mon Sep 17 00:00:00 2001
From: Markus Wichmann
Date: Sun, 20 Oct 2013 10:49:59 +0200
Subject: [PATCH 1/4] Make mkdir read mode argument as octal.
---
mkdir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mkdir.c b/mkdir.c
index 8080797..781654a 100644
--- a/mkdir.c
+++ b/mkdir.c
@@ -30,7 +30,7 @@ main(int argc, char *argv[])
break;
case 'm':
mflag = true;
- mode = estrtol(EARGF(usage()), 10);
+ mode = estrtol(EARGF(usage()), 8);
break;
default:
usage();
--
1.8.4.rc3
>From 40cf23698c688972e072f5352af7def861caa327 Mon Sep 17 00:00:00 2001
From: Markus Wichmann
Date: Sun, 20 Oct 2013 10:50:58 +0200
Subject: [PATCH 2/4] Make chmod honor S_ISVTX.
---
chmod.c | 4
1 file changed, 4 insertions(+)
diff --git a/chmod.c b/chmod.c
index 6d0f8a7..1af3f45 100644
--- a/chmod.c
+++ b/chmod.c
@@ -95,6 +95,7 @@ parsemode(const char *str)
if(*end == '\0') {
if(octal & 04000) mode |= S_ISUID;
if(octal & 02000) mode |= S_ISGID;
+if(octal & 01000) mode |= S_ISVTX;
if(octal & 00400) mode |= S_IRUSR;
if(octal & 00200) mode |= S_IWUSR;
if(octal & 00100) mode |= S_IXUSR;
@@ -140,6 +141,9 @@ parsemode(const char *str)
case 's':
mode |= S_ISUID|S_ISGID;
break;
+case 't':
+mode |= S_ISVTX;
+break;
/* error */
default:
eprintf("%s: invalid mode\n", str);
--
1.8.4.rc3
>From cd2c8a254aa18b020fa499c509d981a49401ee65 Mon Sep 17 00:00:00 2001
From: Markus Wichmann
Date: Sun, 20 Oct 2013 10:53:43 +0200
Subject: [PATCH 3/4] Make chmod and ls recognize sticky bit (S_ISVTX).
---
chmod.c | 4 ++--
ls.c| 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/chmod.c b/chmod.c
index 1af3f45..74c8700 100644
--- a/chmod.c
+++ b/chmod.c
@@ -31,9 +31,9 @@ main(int argc, char *argv[])
case 'R':
rflag = true;
break;
- case 'r': case 'w': case 'x': case 's':
+case 'r': case 'w': case 'x': case 's': case 't':
/*
- * -[rwxs] are valid modes so do not interpret
+ * -[rwxst] are valid modes so do not interpret
* them as options - in any case we are done if
* we hit this case
*/
diff --git a/ls.c b/ls.c
index af1336d..c5eae89 100644
--- a/ls.c
+++ b/ls.c
@@ -228,6 +228,7 @@ output(Entry *ent)
if(ent->mode & S_ISUID) mode[3] = (mode[3] == 'x') ? 's' : 'S';
if(ent->mode & S_ISGID) mode[6] = (mode[6] == 'x') ? 's' : 'S';
+if(ent->mode & S_ISVTX) mode[9] = (mode[9] == 'x') ? 't' : 'T';
errno = 0;
pw = getpwuid(ent->uid);
--
1.8.4.rc3
>From a0749cdc82e5fc55e7feba70c081ad3a42684beb Mon Sep 17 00:00:00 2001
From: Markus Wichmann
Date: Sun, 20 Oct 2013 10:56:49 +0200
Subject: [PATCH 4/4] Add sticky bit to documentation.
---
chmod.1 | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/chmod.1 b/chmod.1
index 579aa68..4deb792 100644
--- a/chmod.1
+++ b/chmod.1
@@ -9,7 +9,7 @@ chmod \- change file mode
.P
.B chmod
.RB [ \-r ]
-.RB [ ugoa ]*[ +-= ][ rwxs ]*
+.RB [ ugoa ]*[ +-= ][ rwxst ]*
.RI [ file ...]
.SH DESCRIPTION
.B chmod
@@ -18,7 +18,7 @@ changes the file mode for the given files.
If the mode is an
.I octal
number, the modes are set according to that number's comprising bits. The first
-digit defines the setuid (4) and setgid (2) attributes. The second digit
+digit defines the setuid (4), setgid (2), and sticky (1) attributes. The second digit
defines the owner's permissions: read (4), write (2), and execute (1); the third
defines permissions for others in the file's group; and the fourth for all other
users. Leading zeroes may be omitted.
@@ -62,6 +62,9 @@ execute permissions.
.TP
.B s
setuid and setgid attributes.
+.TP
+.B t
+sticky attribute.
.PD
.SH OPTIONS
.TP
--
1.8.4.rc3
Re: [dev] [st] [patch] Ignore numlock (Mod2Mask) for button events too.
> A bug presents if you try to add a button shortcut to mshortcuts using
> a mask, for example:
>
> { Button3, ShiftMask, "hi"},
>
> The above does not work if Numlock (Mod2Mask) is on, which is unexpected.
>
I'll apply it, thanks.
--
Roberto E. Vargas Caballero
___
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'
(Doug McIlroy)
In Other Words - Don't design like polkit or systemd
___
Re: [dev] [st] [patch] Cleanup config.def.h, eliminate mappedkeys, simplify matching.
>The first patch is purely aesthetic: it cleans up column headings
>(comments) and internal tabs in the shortcuts/key/mshortcuts tables in
>config.def.h. It also renames the fields in Key to match the nicer names
>given in config.def.h.
Please send atomic patches, The patch must do only one thing and
only one. In this case the tab part is not correct, because we use
smart tabs in the project, tabs for indentation and spaces for
alignment. About the name of the fields, I think is a good idea
have the same in both places, but I am not sure where we have to
change the name. appkey and appcursor have the 'app' prefix because
they are related to the application modes of the terminal, so moving
them to key and cursor quits also this information, but it also
reduce the length of the name, which is good.
>
>The second patch removes the mappedkeys[] optimization. I tested this by
>adding 1.000.000 additional entries to the end of key[]:
>
>static Key key[] = {
> ...
>#include "lots"
>/*
> * "lots" contains 999.999 repetitions of this entry, which is crafted
> * to hit all the tests in kmap() and fail the last:
> * { 'x', XK_ANY_MOD, "nope", .keypad=-1, .cursor=-1, .crlf=1 },
> */
> { 'x', XK_NO_MOD, "exit" },
>};
>
>While gcc goes from a few seconds to more than a minute to compile and
>link the above, I could not detect a performance regression in st. ;)
I have send the reply to this point in the other mail.
>
>The third patch simplifies the matching logic in kmap() and match()
>without changing the behavior. Hopefully, it is straightforward, but it
>probably deserves a careful reading to make sure I haven't made any
>mistakes.
>
Uysss, here be dragons. These conditions were a point of problems
in the past, and the actual result, is a collection of different
patches to fix different problems. So any change will be tested in
deep before applying it.
> static inline bool
> match(uint mask, uint state) {
> state &= ~ignoremod;
>-
>- if(mask == XK_NO_MOD && state)
>- return false;
>- if(mask != XK_ANY_MOD && mask != XK_NO_MOD && !state)
>- return false;
>- if(mask == XK_ANY_MOD)
>- return true;
>- return state == mask;
>+ return mask == XK_ANY_MOD || state == mask;
> }
>
>
I think this patch is correct, because XK_NO_MOD is 0, so if there is
some modifier then 'state == mask' will be false. After the simplification,
match is too short and does nothing, so I think it should be
merged into kmap.
>@@ -3528,25 +3521,18 @@ kmap(KeySym k, uint state) {
> if(!match(kp->mask, state))
> continue;
>
>- if(kp->keypad > 0) {
>- if(!IS_SET(MODE_APPKEYPAD))
>+ if(kp->keypad) {
>+ if(IS_SET(MODE_APPKEYPAD) != (kp->keypad > 0))
> continue;
> if(term.numlock && kp->keypad == 2)
> continue;
>- } else if(kp->keypad < 0 && IS_SET(MODE_APPKEYPAD)) {
>- continue;
> }
>
>- if((kp->cursor < 0 && IS_SET(MODE_APPCURSOR)) ||
>- (kp->cursor > 0
>- && !IS_SET(MODE_APPCURSOR))) {
>+ if(kp->cursor && IS_SET(MODE_APPCURSOR) != (kp->cursor > 0))
> continue;
>- }
>
>- if((kp->crlf < 0 && IS_SET(MODE_CRLF)) ||
>- (kp->crlf > 0 && !IS_SET(MODE_CRLF))) {
>+ if(kp->crlf && IS_SET(MODE_CRLF) != (kp->crlf > 0))
> continue;
>- }
>
> return kp->s;
> }
>--
I agree with Alexander here, and maybe the ?: version could be better.
--
Roberto E. Vargas Caballero
___
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'
(Doug McIlroy)
In Other Words - Don't design like polkit or systemd
___
Re: [dev] [st] [patch] Cleanup config.def.h, eliminate mappedkeys, simplify matching.
> > The third patch simplifies the matching logic in kmap() and match() without > > changing the behavior. Hopefully, it is straightforward, but it probably > > deserves a careful reading to make sure I haven't made any mistakes. > Why removing mappedkeys? Sure, there may be no visible regression, but > checking every keypress against key bindings seems unreasonable to me. I agree. I don't like the actual solution of this problem, but we need some way of avoiding check all the keys. -- Roberto E. Vargas Caballero ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- Roberto E. Vargas Caballero ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
