Re: [hackers] [st][PATCH] sgr-patch
Hi Mikhail, > Colon-separated SGR (new version; ':' is the legacy one) Could explain a bit more what this patch is about, with some context and telling the goal?
Re: [hackers] [st][PATCH] Reset title when an empty title string is given
On Tue, Apr 02, 2024 at 09:41:15PM -0400, DOGMAN wrote: > With this patch, st will reset its window title when an empty string is > given as the terminal title. For example: > printf "\033]0;\007" > > Some applications, like termdown, expect this functionality. xterm > implements it, but it seems that most other terminal emulators don't. > In any case, I don't see why there should ever be a case where the st > window doesn't have a title property. > --- > x.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/x.c b/x.c > index b36fb8c..bd23686 100644 > --- a/x.c > +++ b/x.c > @@ -1617,6 +1617,9 @@ xseticontitle(char *p) > XTextProperty prop; > DEFAULT(p, opt_title); > > + if (p[0] == '\0') > + p = opt_title; > + > if (Xutf8TextListToTextProperty(xw.dpy, , 1, XUTF8StringStyle, > ) != Success) > return; > @@ -1631,6 +1634,9 @@ xsettitle(char *p) > XTextProperty prop; > DEFAULT(p, opt_title); > > + if (p[0] == '\0') > + p = opt_title; > + > if (Xutf8TextListToTextProperty(xw.dpy, , 1, XUTF8StringStyle, > ) != Success) > return; > -- > 2.44.0 > > Hi, Applied, thank you! -- Kind regards, Hiltjo
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Sat, Mar 30, 2024 at 01:59:28AM +0100, Storkman wrote: > On Fri, Mar 29, 2024 at 07:27:43PM +0100, Hiltjo Posthuma wrote: > > On Wed, Mar 27, 2024 at 04:11:27PM +0100, Storkman wrote: > > > On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > > > > commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5 > > > > Author: Quentin Rameau > > > > AuthorDate: Sun Feb 25 01:31:31 2024 +0100 > > > > Commit: Hiltjo Posthuma > > > > CommitDate: Sun Feb 25 11:56:43 2024 +0100 > > > > > > > > Fix cursor move with wide glyphs > > > > > > > > st would always move back 1 column, > > > > even with wide glyhps (using more than a single column). > > > > > > This is apparently what GNU readline expects, so this change breaks > > > line editing, which worked fine before. > > > > > > -- > > > Storkman > > > > > > > Hi, > > > > Can anyone confirm? Preferably with a small example test-case? > > > > Thank you! > > > > -- > > Kind regards, > > Hiltjo > > > > For a specific example, copy text followed by a wide glyph into bash > or mksh, e.g. > A字 > and press backspace once. Both characters will be erased. > > In xterm, "\b" also moves the cursor by one column: > > $ printf "A字\bB\n" > A B > > st after this patch: > > $ printf "A字\bB\n" > AB > > -- > Storkman > Thank you, I've reverted the original patch (with some archived notes) for now. If anyone wants to work on improving the patch, feel free to do so :) -- Kind regards, Hiltjo
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On 24/03/30 01:59AM, Storkman wrote: > For a specific example, copy text followed by a wide glyph into bash > or mksh, e.g. > A字 > and press backspace once. Both characters will be erased. Or, when using tmux, split vertically, then in the right pane copy the above text and press left arrow twice, then right arrow twice. The text will move to the left, "spilling" into the left pane! Fun times. signature.asc Description: PGP signature
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Fri, Mar 29, 2024 at 07:27:43PM +0100, Hiltjo Posthuma wrote: > On Wed, Mar 27, 2024 at 04:11:27PM +0100, Storkman wrote: > > On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > > > commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5 > > > Author: Quentin Rameau > > > AuthorDate: Sun Feb 25 01:31:31 2024 +0100 > > > Commit: Hiltjo Posthuma > > > CommitDate: Sun Feb 25 11:56:43 2024 +0100 > > > > > > Fix cursor move with wide glyphs > > > > > > st would always move back 1 column, > > > even with wide glyhps (using more than a single column). > > > > This is apparently what GNU readline expects, so this change breaks > > line editing, which worked fine before. > > > > -- > > Storkman > > > > Hi, > > Can anyone confirm? Preferably with a small example test-case? > > Thank you! > > -- > Kind regards, > Hiltjo > For a specific example, copy text followed by a wide glyph into bash or mksh, e.g. A字 and press backspace once. Both characters will be erased. In xterm, "\b" also moves the cursor by one column: $ printf "A字\bB\n" A B st after this patch: $ printf "A字\bB\n" AB -- Storkman
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Wed, Mar 27, 2024 at 04:11:27PM +0100, Storkman wrote: > On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > > commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5 > > Author: Quentin Rameau > > AuthorDate: Sun Feb 25 01:31:31 2024 +0100 > > Commit: Hiltjo Posthuma > > CommitDate: Sun Feb 25 11:56:43 2024 +0100 > > > > Fix cursor move with wide glyphs > > > > st would always move back 1 column, > > even with wide glyhps (using more than a single column). > > This is apparently what GNU readline expects, so this change breaks > line editing, which worked fine before. > > -- > Storkman > Hi, Can anyone confirm? Preferably with a small example test-case? Thank you! -- Kind regards, Hiltjo
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5 > Author: Quentin Rameau > AuthorDate: Sun Feb 25 01:31:31 2024 +0100 > Commit: Hiltjo Posthuma > CommitDate: Sun Feb 25 11:56:43 2024 +0100 > > Fix cursor move with wide glyphs > > st would always move back 1 column, > even with wide glyhps (using more than a single column). This is apparently what GNU readline expects, so this change breaks line editing, which worked fine before. -- Storkman
Re: [hackers] [sbase][PATCH] Add implementation of tac(1)
Hi, As this is a topic more about sbase/ubase organization more than about patches I am going to move the discussion to the dev mailing list. Please, answer there instead of here in hackers. Regards,
Re: [hackers] [sbase][PATCH] Add implementation of tac(1)
Hi, I was thinking about what to do with these patches adding new commands. They raised a concern about what should be the scope of sbase. The idea of sbase was to provide a minimal portable POSIX base, while having ubase for the POSIX commands that cannot be implemented in a portable way. Saying that, it is obvious that there are programs in sbase that are not part of POSIX: - md5sum - sha256sum - sha384sum - sha512sum - sponge - sync - tar - install and maybe some others. At this point is not clear to me what to do with tools like tac or shuf. There was a small discussion about this topic in the irc channel, and it was proposed to add a 3rd repository to contain all these tools that are not part of POSIX (a bit like the moretools package). From my point of view, the main drawback of it is that it requires a 3rd -box program (currently we have sbase-box and ubase-box). The current situation it not good, because the two -box are not sharing the library, and the disk space is duplicated (main reason of -box is to minimize disk space for restricted environments), and a 3rd -box would make the situation even worse. But in the other hand, I don't want to add more non POSIX tools in sbase (in fact, I personally would like to remove the current non POSIX tools). I would like to move the discussion here and see what alternatives we have and how to proceed in this case. Regards,
Re: [hackers] [ubase][PATCH 1/4] su: simplify logic
Hi, On Thu, Mar 07, 2024 at 02:52:49PM -0500, neeshy wrote: > On Thu Mar 7, 2024 at 1:19 PM EST, Roberto E. Vargas Caballero wrote: > > I think it makes it simpler while keeping the correct behaviour that I > > broke. > > Looks good to me! Pushed!
Re: [hackers] [ubase][PATCH 1/4] su: simplify logic
On Thu Mar 7, 2024 at 1:19 PM EST, Roberto E. Vargas Caballero wrote: > I think it makes it simpler while keeping the correct behaviour that I broke. Looks good to me!
Re: [hackers] [ubase][PATCH 1/4] su: simplify logic
Hi,
On Thu, Mar 07, 2024 at 02:18:28AM -0500, neeshy wrote:
> It seems that the modifications you made break the use case where su is
> called without a username. It would normally default to the root
> user, but now it invokes usage() instead. My original patch worked as
> intended. Could you rebase using the original patch instead? Thank you.
>
Sadly, I cannot rebase it as it is already in the central repository.
What do you think about adding a new change like this:
diff --git a/su.c b/su.c
index eb8bea7..8eea82b 100644
--- a/su.c
+++ b/su.c
@@ -26,7 +26,7 @@ usage(void)
int
main(int argc, char *argv[])
{
- char *usr = "root", *pass;
+ char *usr, *pass;
char *shell, *envshell, *term;
struct passwd *pw;
char *newargv[3];
@@ -43,9 +43,14 @@ main(int argc, char *argv[])
usage();
} ARGEND;
- if (argc != 1)
+ if (argc > 1)
usage();
- usr = argv[0];
+ usr = argc > 0 ? argv[0] : "root";
errno = 0;
pw = getpwnam(usr);
I think it makes it simpler while keeping the correct behaviour that I broke.
Kind Regards,
Roberto Vargas
Re: [hackers] [ubase][PATCH 1/4] su: simplify logic
On Wed Mar 6, 2024 at 4:14 AM EST, Roberto E. Vargas Caballero wrote: > Hi, > > > On Mon, Feb 12, 2024 at 04:25:49PM -0500, neeshy wrote: > > Inline dologin, and simplify common code > > I have applied the 4 patches with a minor modification to the 1st > one. > > Kind regards, > Roberto Vargas. Hello, It seems that the modifications you made break the use case where su is called without a username. It would normally default to the root user, but now it invokes usage() instead. My original patch worked as intended. Could you rebase using the original patch instead? Thank you.
Re: [hackers] [sbase][PATCH] tar: chktar: fix conditional typo
Hi, On Tue, Mar 05, 2024 at 09:20:57PM +0100, Elie Le Vaillant wrote: > --- > tar.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tar.c b/tar.c > index 0361b63..405b8d9 100644 > --- a/tar.c > +++ b/tar.c > @@ -423,7 +423,7 @@ chktar(struct header *h) > goto bad; > } > memcpy(tmp, h->chksum, sizeof(tmp)); > - for (i = 0; i < sizeof(tmp), tmp[i] == ' '; i++); > + for (i = 0; i < sizeof(tmp) && tmp[i] == ' '; i++); > for (; i < sizeof(tmp); i++) > if (tmp[i] == ' ') > tmp[i] = '\0'; Applied, thanks.
Re: [hackers] [ubase][PATCH 1/4] su: simplify logic
Hi, On Mon, Feb 12, 2024 at 04:25:49PM -0500, neeshy wrote: > Inline dologin, and simplify common code I have applied the 4 patches with a minor modification to the 1st one. Kind regards, Roberto Vargas.
Re: [hackers] [sbase][PATCH] libutil/random: better random seed
> - *state = ts.tv_nsec; > + *state = (intptr_t) ^ time(NULL) ^ (ts.tv_nsec * 0xAC5533CD); tv_nsec is `long` which is signed. Signed interger overflow is undefined. You need to cast it to `unsigned long` before multiply: ... ^ ((unsigned long)ts.tv_nsec * 0xAC5533CD) - NRK
Re: [hackers] [sbase][PATCH] libutil/random: better random seed
On Mon, Mar 4, 2024 at 5:03 PM Elie Le Vaillant wrote:
>
> Thanks NRK
> ---
> libutil/random.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libutil/random.c b/libutil/random.c
> index 780ba29..6b795a9 100644
> --- a/libutil/random.c
> +++ b/libutil/random.c
> @@ -1,4 +1,5 @@
> #include
> +#include
> #include
>
> static uint64_t globalstate;
> @@ -66,7 +67,7 @@ rng32_seed_r(uint64_t *state)
> {
> struct timespec ts;
> clock_gettime(CLOCK_REALTIME, );
> - *state = ts.tv_nsec;
> + *state = (intptr_t) ^ time(NULL) ^ (ts.tv_nsec * 0xAC5533CD);
> }
>
> void
> --
> 2.44.0
>
>
Instead of calling time(NULL), you already have the second of the
epoch in ts.tv_sec.
Re: [hackers] [sbase][PATCH] head: remove useless buffering
> + while (i < n && (c = fgetc(fp)) != EOF) {
> + if (fputc(c, stdout) == EOF)
I don't see this as an improvement. Each one of the fgetc and fputc are
going to go through a mutex lock (along with possibly going through a
call into a dynamic function).
I think the current solution with getline is fine in practice. It's
unlikely for a line to be too big to malloc.
I think a more worthwhile improvement - to head(1) and a couple other
utils - would be to add nul-delim support via `-z`. It's required in
order to correctly deal with all valid filenames in a shell script. And
AFAIK many of the `-z` like option are currently accepted into the next
POSIX draft.
- NRK
Re: [hackers] [sbase][PATCH] Add implementation of tac(1)
On Sun, Mar 03, 2024 at 12:34:16AM +0100, Elie Le Vaillant wrote:
> +static void
> +tac(FILE *fp)
> +{
> + struct linebuf buf = EMPTY_LINEBUF;
> + struct line line;
> + getlines(fp, );
> +
> + if (buf.nolf) {
> + /* If the last line is not LF-terminated, the
> + * first output line should not be either */
> + buf.nolf--;
> + buf.lines[buf.nlines - 1].len--;
> + }
> +
> + while (buf.nlines--) {
> + line = buf.lines[buf.nlines];
> + fwrite(line.data, 1, line.len, stdout);
> + free(line.data);
> + }
> + free(buf.lines);
> +}
I'm not sure what level of optimization the maintainers expect, but
personally, I think there should be separate implementations for
seekable vs non-seekable files to avoid buffering the entire contents of
the file in memory unnecessarily.
Eric
Re: [hackers] [sbase][PATCH v3] tar: sanitize, chktar: leading spaces should be skipped over
Hi, On Sun, Feb 11, 2024 at 09:26:14AM +0100, Elie Le Vaillant wrote: > Some tar archives (eg. ftp://ftp.gnu.org/gnu/shtool/shtool-2.0.8.tar.gz) > use leading spaces instead of leading zeroes for numeric fields. > Although it is not allowed by the ustar specification, most tar > implementations recognize it as correct. But since 3ef6d4e4, we > replace all spaces by NULs here, not just trailing ones, which leads to > recognizing such archives as malformed. This fixes it: we now skip > over leading spaces, allowing strtol(3) to read those numeric fields. Applied, thanks.
Re: [hackers] [sbase][PATCH v2] tar: sanitize: leading zeros should be recognized
On Tue, Mar 05, 2024 at 01:16:36PM +0100, Roberto E. Vargas Caballero wrote: > Hi, > > On Sat, Feb 10, 2024 at 11:57:38PM +0100, Elie Le Vaillant wrote: > > @@ -399,10 +400,17 @@ sanitize(struct header *h) > > for (i = 0; i < LEN(fields); i++) > > - for (j = 0; j < fields[i].l; j++) > > + for (leading = 1, j = 0; j < fields[i].l; j++) > > if (fields[i].f[j] == ' ') > > - fields[i].f[j] = '\0'; > > + fields[i].f[j] = leading ? '0' : '\0'; > > + else > > + leading = 0; > > } > > What do you think if we move this loop into a function and we use > it in both cases? Ok, I saw that there is a new version of the patch. I am going to apply v3 without changes. sorry for the noise. Roberto Vargas
Re: [hackers] [sbase][PATCH v2] tar: sanitize: leading zeros should be recognized
Hi, On Sat, Feb 10, 2024 at 11:57:38PM +0100, Elie Le Vaillant wrote: > @@ -399,10 +400,17 @@ sanitize(struct header *h) > for (i = 0; i < LEN(fields); i++) > - for (j = 0; j < fields[i].l; j++) > + for (leading = 1, j = 0; j < fields[i].l; j++) > if (fields[i].f[j] == ' ') > - fields[i].f[j] = '\0'; > + fields[i].f[j] = leading ? '0' : '\0'; > + else > + leading = 0; > } What do you think if we move this loop into a function and we use it in both cases? Roberto Vargas
Re: [hackers] [sbase][PATCH] Add implementation of tac(1)
Eric Pruitt wrote: > I think there should be separate implementations for seekable vs > non-seekable files to avoid buffering the entire contents of > the file in memory unnecessarily. In fact, performance could be also improved for non-seekable files by forcing a seekable context, ie. use a temporary file (that is seekable), and then perform the function for seekable files on it. coreutils' tac does this. But I'm not sure the performance gain is worth the complexity. On my computer, for a 115M file generated as follows yes Hello World | head -n1000 here is the time for this tac implementation, obtained by `tac
Re: [hackers] [st][PATCH] set upper limit for REP escape sequence argument
On Mon, Mar 04, 2024 at 10:24:36PM +0200, Tommi Hirvola wrote: > On Mon, Mar 04, 2024 at 01:55:29PM +0100, Hiltjo Posthuma wrote: > > I'm not sure about it. You could still chain REP sequences and "DoS" it. > > Fortunately, chained REP sequences can be terminated with ^C. You can > try this by copy-pasting the following line into st and pressing CTRL+C: > > $ for i in $(seq $((2147483647/65536))); do printf 'L\033[65535b'; done > > This also works if we cat a file containing 'L\033[65535b' x 32768. Note > that ^C doesn't work for printf 'L\033[2147483647b' with (unpatched) st. > > > For untrusted input one should be careful about escape sequences anyway. > > This seems to be the unfortunate reality for modern terminals. > > Personally I use st because I can be reasonably confident that cat'ing > server log files does not lead to code execution or other unexpected > behavior. This "REP DoS issue" (if we can call it that) is the only > problem that I've encountered so far. > > Even if this REP thing is not a security issue, I think it is still > important to fix in order to prevent (rare) accidental freezing of st. > xterm seems to similarly limit REP argument to ~55K characters in my > environment. > Hi again, OK that last part convinced me :). I also tested and looked at the xterm code and it seems to indeed limit certain parameter values to 65535. I pushed the patch. Thanks, > -- > Tommi Hirvola > -- Kind regards, Hiltjo
Re: [hackers] [st][PATCH] set upper limit for REP escape sequence argument
On Mon, Mar 04, 2024 at 01:55:29PM +0100, Hiltjo Posthuma wrote: > I'm not sure about it. You could still chain REP sequences and "DoS" it. Fortunately, chained REP sequences can be terminated with ^C. You can try this by copy-pasting the following line into st and pressing CTRL+C: $ for i in $(seq $((2147483647/65536))); do printf 'L\033[65535b'; done This also works if we cat a file containing 'L\033[65535b' x 32768. Note that ^C doesn't work for printf 'L\033[2147483647b' with (unpatched) st. > For untrusted input one should be careful about escape sequences anyway. This seems to be the unfortunate reality for modern terminals. Personally I use st because I can be reasonably confident that cat'ing server log files does not lead to code execution or other unexpected behavior. This "REP DoS issue" (if we can call it that) is the only problem that I've encountered so far. Even if this REP thing is not a security issue, I think it is still important to fix in order to prevent (rare) accidental freezing of st. xterm seems to similarly limit REP argument to ~55K characters in my environment. -- Tommi Hirvola
Re: [hackers] [st][PATCH] set upper limit for REP escape sequence argument
On Mon, Mar 04, 2024 at 12:56:30PM +0200, Tommi Hirvola wrote:
> Previously, printf 'L\033[2147483647b' would call tputc('L') 2^31 times,
> making st unresponsive. This commit allows repeating the last character
> at most 65535 times in order to prevent freezing and DoS attacks.
> ---
> st.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/st.c b/st.c
> index 77c3e8a..683493d 100644
> --- a/st.c
> +++ b/st.c
> @@ -1643,7 +1643,7 @@ csihandle(void)
> ttywrite(vtiden, strlen(vtiden), 0);
> break;
> case 'b': /* REP -- if last char is printable print it more times */
> - DEFAULT(csiescseq.arg[0], 1);
> + LIMIT(csiescseq.arg[0], 1, 65535);
> if (term.lastc)
> while (csiescseq.arg[0]-- > 0)
> tputc(term.lastc);
> --
> 2.39.2
>
>
Hi,
I'm not sure about it. You could still chain REP sequences and "DoS" it.
For untrusted input one should be careful about escape sequences anyway.
--
Kind regards,
Hiltjo
Re: [hackers] Re: [sbase] Orphan patches and unsent patches
On Sun, Mar 03, 2024 at 03:05:47PM +0100, Eolien55 wrote: > but should we not rather implement "Debiased Int Mult (t-opt)"? Both should be fine. The integer mul method avoids clz() so that could be a reason to prefer it. > arc4random(3) doesn't uses seeds, which means that I cannot initialize > it wrong. I see, that makes sense. You had the right idea on one of your eariler patch about mixing malloc-ed address and time but the implementation wasn't good. srandom((intptr_t)buf.nlines | time(NULL)); OR isn't a good mixer because it's biased towards 1 (it's also not reversible): 0 | 0 = 0 0 | 1 = 1 1 | 0 = 1 1 | 1 = 1 XOR would be better. But even better would be to hash it before xor-ing. Just a multiply by an large-ish odd number is usually sufficient: seed = ((uintptr_t)malloced_addr * 0xAC5533CD) ^ time(NULL) /* or use nanoseconds */; You could also mix in a stack address and/or the address of a (usually) dynamically linked function the same way. This should be enough to get a decent seed without relying on system specific interfaces. (See also: https://nullprogram.com/blog/2019/04/30/) - NRK
Re: [hackers] Re: [sbase] Orphan patches and unsent patches
NRK wrote: > I'd recommend using the bitmask approach described in here: > https://www.pcg-random.org/posts/bounded-rands.html#bitmask-with-rejection-unbiased-apples-method I thought the approach used by OpenBSD was simpler, and performed better, becaused it avoided the loop, which might cause the algorithm to repeat itself, overall slowing the algorithm. It seems not to be the case according to this link. However, the 2 last approaches described (Debiased Int Mult, (t-opt) and (t-opt, m-opt)) seem to perform better, for small-constant benchmarks, small-shuffle and all-ranges-shuffle, with non-negligible performance gains. Where Bitmask performs better, the difference seems negligible. I see that the implementation I sent doesn't have good performance, but should we not rather implement "Debiased Int Mult (t-opt)"? > And if you want a portable clz without depending on __builtin_clz() then see: > https://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 I'll work on that, thanks. > I'm not sure why you think arc4random() is better. I doubt you need any > cryptograhic guarantees here. rand(3) could not be used because RAND_MAX causes some problems. random(3) needs a seed, and a good random seed is tricky to get. We can't read from /dev/urandom because it might be that we're in a chroot ; the timestamp can be quite random on its lower bits, but it changes too slowly. Nanoseconds seem okay, but I'm not sure whether or not it's sufficiently random. arc4random(3) doesn't uses seeds, which means that I cannot initialize it wrong (ie., use a PRNG in a way that its results aren't random). > Personally I'd just go with a simple PCG construction. It takes about > ~6 lines of code [0], is fast and has good statistical properties. > Would also avoid spending time locking/unlocking mutex inside libc for > no reason. I think it's a good idea to have our own fast PRNG, but I originally thought it was better to trust the implementers of libc for making a _random_ PRNG. I will play with the PRNG you've sent me though. Thank you -- Elie Le Vaillant
Re: [hackers] Re: [sbase] Orphan patches and unsent patches
On Sun, Mar 03, 2024 at 12:58:20AM +0100, Elie Le Vaillant wrote: > I'm using the web interface to the mailing list to check what has been > sent, and these patches were not sent. The web archive is not reliable and often drops mails. > + * Copied off OpenBSD (original is arc4random_uniform) > + */ > +uint32_t > +random_uniform(uint32_t upper_bound) I'd recommend using the bitmask approach described in here: https://www.pcg-random.org/posts/bounded-rands.html#bitmask-with-rejection-unbiased-apples-method And if you want a portable clz without depending on __builtin_clz() then see: https://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 > + r = random(); /* arc4random() is better, but we don't always > have it */ I'm not sure why you think arc4random() is better. I doubt you need any cryptograhic guarantees here. Personally I'd just go with a simple PCG construction. It takes about ~6 lines of code [0], is fast and has good statistical properties. Would also avoid spending time locking/unlocking mutex inside libc for no reason. [0]: https://github.com/imneme/pcg-c-basic/blob/bc39cd76ac3d541e618606bcc6e1e5ba5e5e6aa3/pcg_basic.c#L60-L67 or: https://codeberg.org/NRK/slashtmp/src/branch/master/prng/pcg_32.c - NRK
Re: [hackers] Penfing patches for sbase and ubase
"Roberto E. Vargas Caballero" wrote: > I know that there are some pending patches for sbase and ubase, > but I am a bit busy these days and I will not be able to look > a bit deeper on them until next week. Be patient until then :) > > Thank you Sure, no problem! I've sent most of the patches I've made anyway, except for smaller bugfixes. Take care
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Sun Feb 25, 2024 at 8:13 AM CST, Quentin Rameau wrote: > Would you have a suggestion about how to handle cursor absolute > position with text position, maybe we need some addition state? I would suggest that cursor position control sequences should always operate on a single-column basis. This is in line with every other terminal that handles wide characters. It is up to the application running in the emulator to know where it wants to position the cursor. For example, the command below should move the cursor into the emoji but the second `\e[D` should have not *visual* change, but the cursor is actually in the "first" column of the emoji printf " " && sleep 2 && printf "\e[D" && sleep 2 && printf "\e[D" && sleep 2 Just my two cents. -- Tim
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
> Hi, Hola k0ga, > > st would always move back 1 column, > > even with wide glyhps (using more than a single column). > > > > The glyph rune is set on its first column, > > and the other ones are to 0, > > so loop until we detect the start of the previous glyph. > > Should this be done in every cursor addressing command? > What happens if we position the cursor in the middle of a glyph? That's a preliminary patch to encourage improving the matter, I suspect there might be some unhandled side-effects in some perticular cases, when using arbitrary cursor movement for example, though it's unclear if those should be handled separately or not. Would you have a suggestion about how to handle cursor absolute position with text position, maybe we need some addition state?
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
Hi, On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > st would always move back 1 column, > even with wide glyhps (using more than a single column). > > The glyph rune is set on its first column, > and the other ones are to 0, > so loop until we detect the start of the previous glyph. Should this be done in every cursor addressing command? What happens if we position the cursor in the middle of a glyph? Kind regards,
Re: [hackers] [st][PATCH] csi: check for private marker in 'S' case
On Sun, Feb 18, 2024 at 06:56:49AM -0600, Tim Culverhouse wrote: > The handler for 'S' final character does not check for a private > marker. This can cause a conflict with a sequence called 'XTSMGRAPHICS' > which also has an 'S' final character, but uses the private marker '?'. > Without checking for a private marker, st will perform a scroll up > operation when XTSMGRAPHICS is seen, which can cause unexpected display > artifacts. > --- > st.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/st.c b/st.c > index d6478f55a249..034954d0aa83 100644 > --- a/st.c > +++ b/st.c > @@ -1728,6 +1728,7 @@ csihandle(void) > } > break; > case 'S': /* SU -- Scroll line up */ > + if (csiescseq.priv) break; > DEFAULT(csiescseq.arg[0], 1); > tscrollup(term.top, csiescseq.arg[0]); > break; > -- > 2.43.2 > > Hi Tim, Thank you, it looks good to me. I've pushed the patch. Have a good day, -- Kind regards, Hiltjo
Re: [hackers] [sbase][PATCH] expr: tonum: handle case where result was previously calculated
Hi, On Mon, Jan 22, 2024 at 02:18:10PM -0700, Randy Palamar wrote: > As pointed out in a mail to dev expr was segfaulting when multiple > math operations were specified on the command line: eg. 'expr 3 \* > 2 + 1'. This happens because the tonum(), introduced in e50d533, > assumed that v->str was always non null. parse() guarantees this > for user input but this is not the case when doop() is called with > the result of a previous calculation. However in that case we know > that v->num is already valid so we can simply return. > --- Applied, thanks.
Re: [hackers] [sbase][PATCH 2/2] expr: don't evaluate matched substr as a number
Hi, On Sun, Jan 07, 2024 at 11:02:18AM -0700, Randy Palamar wrote: > POSIX specifies that if the pattern contains a subexpression then > the first matched subexpression should be returned if it exists. > > This fixes things like the following: > > ./expr 3 : '\(.*\)' > Before: 3 > After: 3 Applied, thanks! Roberto Vargas
Re: [hackers] [sbase][PATCH 1/2] expr: treat expressions as strs until evaluation
Hi On Sun, Jan 07, 2024 at 11:02:17AM -0700, Randy Palamar wrote: > Comparison operations (>, <, =, etc.) and matching operations must > operate originally provided string not one that has gone back and > forth through string formatting. This caused operations such as > the following to give incorrect results: > > ./expr 3 : '.*' > Before: 1 > After: 5 > > This commit fixes that issue. Applied, thanks! Roberto Vargas.
Re: [hackers] ed: Enable multi line commands
Hi, On Sun, Dec 24, 2023 at 12:07:44PM +0100, Rene Kita wrote: > On Wed, Dec 13, 2023 at 12:55:26PM +0100, Roberto E. Vargas Caballero wrote: > > It changes to read full lines before executing commands, escaping > > newlines when it is needed. It solves 2 different cases: > > > > - Substitution commands with newlines in the replace part > > This does not work with a range: > > #v+ > $ ./ed > i > foobar1 > foobar2 > . > 1,2s/foo/&\ > &/ > ,n > 1 foo > 2 foo > 3 foobar1 > 4 foobar2 Good catch, I am going to add it to the list of known bugs. Substitutions have problems, and this is the next thing that I want to fix. > #v- > > > - Global commands with append or insert commands > > > > Still, some additional problems were detected in the case of > > global commands but they will be fixed in a follow up patchset. > > I did not test much, but what I tested worked. > > BTW, why is there no test suite? I started adding tests[0] for ed when I > attempted to write a patch for this. It's still WIP, though. Basically due to a lack of time. It is something that I discussed with quinq a few weeks ago. We should add a test suite for all the sbase commands, and mainly for ed and sed that at this moment are the most complex one (the coming bc is also complex, but a bit less in my opinion). Regards
Re: [hackers] [PATCH 1/6] ed: Add optional parameter to string()
Hi,
On Tue, Dec 26, 2023 at 03:40:36PM +0100, Страхиња Радић wrote:
> On 23/12/24 11:46AM, Rene Kita wrote:
> > > + if (!from) {
> > > + len = 0;
> > > + t = NULL;
> > > + } else {
>
> This seems redundant. Normally, NULL shouldn't be passed, and even if it is,
> it
> is the responsibility of the "user-programmer" (think libc functions). This
> is
> further backed by the standard pattern of always checking for failed malloc.
As Rene commented maybe is better to split this function in two different
functions. Assigning NULL in this case was needed because it was used later
in a call to realloc. Ed is different to other sbase programs where is
acceptable
to abort when we run out of memory, because it is mainly used in an interactive
way and discarding all the changes from the user in that case seems a bit weird.
Regards,
Re: [hackers] [PATCH 1/6] ed: Add optional parameter to string()
Hi, On Sun, Dec 24, 2023 at 11:46:26AM +0100, Rene Kita wrote: > Nit as it's more a matter of style: I'd prefer to have one function to > create a String and another function to create a String from a char > array. This would make a cleaner interface and avoids passing and > dealing with NULL all the time. > This was my election in the first version, but then I moved to unify both. I think I will attend your comment and split it again. I will push it with that small modification and then I will send the second patch serie. Regards,
Re: [hackers] [PATCH 1/6] ed: Add optional parameter to string()
On 23/12/24 11:46AM, Rene Kita wrote:
> > + if (!from) {
> > + len = 0;
> > + t = NULL;
> > + } else {
This seems redundant. Normally, NULL shouldn't be passed, and even if it is, it
is the responsibility of the "user-programmer" (think libc functions). This is
further backed by the standard pattern of always checking for failed malloc.
signature.asc
Description: PGP signature
Re: [hackers] ed: Enable multi line commands
On Wed, Dec 13, 2023 at 12:55:26PM +0100, Roberto E. Vargas Caballero wrote: > It changes to read full lines before executing commands, escaping > newlines when it is needed. It solves 2 different cases: > > - Substitution commands with newlines in the replace part This does not work with a range: #v+ $ ./ed i foobar1 foobar2 . 1,2s/foo/&\ &/ ,n 1 foo 2 foo 3 foobar1 4 foobar2 #v- > - Global commands with append or insert commands > > Still, some additional problems were detected in the case of > global commands but they will be fixed in a follow up patchset. I did not test much, but what I tested worked. BTW, why is there no test suite? I started adding tests[0] for ed when I attempted to write a patch for this. It's still WIP, though. [0]: https://git.sr.ht/~rkta/sbase/tree/bsd/item/t
Re: [hackers] [PATCH 1/6] ed: Add optional parameter to string()
Comment inline.
On Wed, Dec 13, 2023 at 12:55:27PM +0100, Roberto E. Vargas Caballero wrote:
> This makes possible to use the function to initialize the string from
> an existing char array.
> ---
> ed.c | 30 +-
> 1 file changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/ed.c b/ed.c
> index b430e74..13e956a 100644
> --- a/ed.c
> +++ b/ed.c
> @@ -122,12 +122,24 @@ prevln(int line)
> }
>
> static String *
> -string(String *s)
> +string(String *s, char *from)
Nit as it's more a matter of style: I'd prefer to have one function to
create a String and another function to create a String from a char
array. This would make a cleaner interface and avoids passing and
dealing with NULL all the time.
> {
> + size_t len;
> + char *t;
> +
> + if (!from) {
> + len = 0;
> + t = NULL;
> + } else {
> + if ((t = strdup(from)) == NULL)
> + error("out of memory");
> + len = strlen(t);
> + }
Re: [hackers] [svkbd][PATCH] this patch fixes uppercase in armenian (and perhaps some other) layouts. svkbd was previously registering a key in one modification (xorg accepts up to 4 modifications). w
good, thank you. (:
On Wed, 13 Dec 2023 19:12:00 +0100
Hiltjo Posthuma wrote:
> Hi,
>
> Thanks, I've applied the patch and fixed a tiny typo in the debug message.
>
> I haven't tested the patch, but I trust you that it works.
>
> Of course if people notice bugs, feel free to report them.
>
> On Wed, Dec 13, 2023 at 04:30:17PM +0400, նորայր wrote:
> > also no need to know armenian to test.
> > just run ./svkbd-mobile-intl and type lowercase and uppercase in armenian
> > layout.
> >
> > do that for the patched version and you'll see the difference.
> >
> > for some reason on sxmo/postmarketos i have to restart the device in order
> > to run a newer binary. though i think i checked that when i remove the
> > keyboard with a gesture, the process gets killed. and if i replace the
> > binary and get the keyboard with a gesture again, it should run the newer
> > binary. but maybe something changed now, because last time i was testing
> > it, i had to restart the device. this is irrelevant to svkbd, i just think
> > of how you will test it, in case you will test it on sxmo/postmarketos the
> > restart might be needed.
> >
> > On Wed, 13 Dec 2023 16:21:04 +0400
> > նորայր wrote:
> >
> > > ok let me try to explain this very simply.
> > > some time ago i have added armenian and dvorak layouts.
> > > i have noticed that in dvorak and all other layouts uppercase characters
> > > work.
> > > while you don't have to do any extra effort for that. let's say:
> > >
> > > ```
> > > { 0, 0, XK_a, 1 },
> > > { 0, 0, XK_o, 1 },
> > > { 0, 0, XK_e, 1 },
> > > { 0, 0, XK_u, 1 },
> > > { 0, 0, XK_i, 1 },
> > > { 0, 0, XK_d, 1 },
> > > ```
> > >
> > > notice that layout describes only the lowercase variant, and the
> > > uppercase works automagically.
> > >
> > > same with cyrillic:
> > >
> > > ```
> > > { "й", 0, XK_Cyrillic_shorti, 1 },
> > > { "ц", 0, XK_Cyrillic_tse, 1 },
> > > { "у", 0, XK_Cyrillic_u, 1 },
> > > { "к", 0, XK_Cyrillic_ka, 1 },
> > > { "е", 0, XK_Cyrillic_ie, 1 },
> > > ```
> > >
> > > one doesn't even have to specify the uppercase variant.
> > > my guess is that the conversion is done by Xorg automatically for some
> > > layouts. i don't know why and how.
> > >
> > > however this approach didn't work with armenian layout (i guess it won't
> > > work with many other layouts), so i had to specify both uppercase and
> > > lowercase variants:
> > >
> > > ```
> > > { "ճ", "Ճ", XK_Armenian_tche, 1 },
> > > { "փ", "Փ", XK_Armenian_pyur, 1 },
> > > { "բ", "Բ", XK_Armenian_ben, 1 },
> > > { "ս", "Ս", XK_Armenian_se, 1 },
> > > { "մ", "Մ", XK_Armenian_men, 1 },
> > > { "ո", "Ո", XK_Armenian_vo, 1 },
> > > { "ւ", "Ւ", XK_Armenian_vyun, 1 },
> > > ```
> > >
> > > though i have had specified the uppercase letters, they were painted on
> > > the keyboard, but didn't work.
> > >
> > > now with this patch (see the commit message for more details) uppercase
> > > letters work.
> > > my guess is this will fix the behaviour not only for armenian, but for
> > > many other layouts for which Xorg doesn't have a method to get the
> > > uppercase symbol automatically for some reason.
> > > my guess is that cyrillic and latin are for some reason handled
> > > differently by xorg than the majority of other character sets.
> > >
> > > and one more detail, though this commit fixes almost every letter in
> > > armenian layout, one thing still don't work. namely, this line:
> > > { "՝","՜", XK_Armenian_exclam, 1 },
> > >
> > > for some reason only the second character described in this line ("՜")
> > > gets printed whether the shift is pressed or not. i will try to
> > > understand why this doesn't work some other day.
> > >
> > > but the commit fixes everything. i have this fix for a year already and
> > > i need to recompile svkbd every time after update, and restart the
> > > device, so if this is applied, it will simplify my life a lot.
> > >
> > > so to stress it again: this is not only relevant to armenian layout.
> > >
> > >
> > >
> > >
> > > On Sun, 3 Dec 2023 21:48:09 +0100
> > > Hiltjo Posthuma wrote:
> > >
> > > > On Sun, Dec 03, 2023 at 08:22:04PM +0400, norayr chilingarian wrote:
> > > > > ---
> > > > > svkbd.c | 11 ++-
> > > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/svkbd.c b/svkbd.c
> > > > > index e4dbd15..cce2463 100644
> > > > > --- a/svkbd.c
> > > > > +++ b/svkbd.c
> > > > > @@ -481,9 +481,18 @@ press(Key *k, KeySym buttonmod)
> > > > > int
> > > > > tmp_remap(KeySym keysym)
> > > > > {
> > > > > - XChangeKeyboardMapping(dpy, tmp_keycode, 1, , 1);
> > > > > + /* map lower and upper case of keysym to the temporary keycode
> > > > > */
> > > > > + KeySym syms[2];
> > > > > + XConvertCase(keysym, [0], [1]);
> > > > > +
> > > > > + /* if keysym
Re: [hackers] [svkbd][PATCH] this patch fixes uppercase in armenian (and perhaps some other) layouts. svkbd was previously registering a key in one modification (xorg accepts up to 4 modifications). w
Hi,
Thanks, I've applied the patch and fixed a tiny typo in the debug message.
I haven't tested the patch, but I trust you that it works.
Of course if people notice bugs, feel free to report them.
On Wed, Dec 13, 2023 at 04:30:17PM +0400, նորայր wrote:
> also no need to know armenian to test.
> just run ./svkbd-mobile-intl and type lowercase and uppercase in armenian
> layout.
>
> do that for the patched version and you'll see the difference.
>
> for some reason on sxmo/postmarketos i have to restart the device in order to
> run a newer binary. though i think i checked that when i remove the keyboard
> with a gesture, the process gets killed. and if i replace the binary and get
> the keyboard with a gesture again, it should run the newer binary. but maybe
> something changed now, because last time i was testing it, i had to restart
> the device. this is irrelevant to svkbd, i just think of how you will test
> it, in case you will test it on sxmo/postmarketos the restart might be needed.
>
> On Wed, 13 Dec 2023 16:21:04 +0400
> նորայր wrote:
>
> > ok let me try to explain this very simply.
> > some time ago i have added armenian and dvorak layouts.
> > i have noticed that in dvorak and all other layouts uppercase characters
> > work.
> > while you don't have to do any extra effort for that. let's say:
> >
> > ```
> > { 0, 0, XK_a, 1 },
> > { 0, 0, XK_o, 1 },
> > { 0, 0, XK_e, 1 },
> > { 0, 0, XK_u, 1 },
> > { 0, 0, XK_i, 1 },
> > { 0, 0, XK_d, 1 },
> > ```
> >
> > notice that layout describes only the lowercase variant, and the uppercase
> > works automagically.
> >
> > same with cyrillic:
> >
> > ```
> > { "й", 0, XK_Cyrillic_shorti, 1 },
> > { "ц", 0, XK_Cyrillic_tse, 1 },
> > { "у", 0, XK_Cyrillic_u, 1 },
> > { "к", 0, XK_Cyrillic_ka, 1 },
> > { "е", 0, XK_Cyrillic_ie, 1 },
> > ```
> >
> > one doesn't even have to specify the uppercase variant.
> > my guess is that the conversion is done by Xorg automatically for some
> > layouts. i don't know why and how.
> >
> > however this approach didn't work with armenian layout (i guess it won't
> > work with many other layouts), so i had to specify both uppercase and
> > lowercase variants:
> >
> > ```
> > { "ճ", "Ճ", XK_Armenian_tche, 1 },
> > { "փ", "Փ", XK_Armenian_pyur, 1 },
> > { "բ", "Բ", XK_Armenian_ben, 1 },
> > { "ս", "Ս", XK_Armenian_se, 1 },
> > { "մ", "Մ", XK_Armenian_men, 1 },
> > { "ո", "Ո", XK_Armenian_vo, 1 },
> > { "ւ", "Ւ", XK_Armenian_vyun, 1 },
> > ```
> >
> > though i have had specified the uppercase letters, they were painted on the
> > keyboard, but didn't work.
> >
> > now with this patch (see the commit message for more details) uppercase
> > letters work.
> > my guess is this will fix the behaviour not only for armenian, but for many
> > other layouts for which Xorg doesn't have a method to get the uppercase
> > symbol automatically for some reason.
> > my guess is that cyrillic and latin are for some reason handled differently
> > by xorg than the majority of other character sets.
> >
> > and one more detail, though this commit fixes almost every letter in
> > armenian layout, one thing still don't work. namely, this line:
> > { "՝","՜", XK_Armenian_exclam, 1 },
> >
> > for some reason only the second character described in this line ("՜") gets
> > printed whether the shift is pressed or not. i will try to understand why
> > this doesn't work some other day.
> >
> > but the commit fixes everything. i have this fix for a year already and i
> > need to recompile svkbd every time after update, and restart the device, so
> > if this is applied, it will simplify my life a lot.
> >
> > so to stress it again: this is not only relevant to armenian layout.
> >
> >
> >
> >
> > On Sun, 3 Dec 2023 21:48:09 +0100
> > Hiltjo Posthuma wrote:
> >
> > > On Sun, Dec 03, 2023 at 08:22:04PM +0400, norayr chilingarian wrote:
> > > > ---
> > > > svkbd.c | 11 ++-
> > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/svkbd.c b/svkbd.c
> > > > index e4dbd15..cce2463 100644
> > > > --- a/svkbd.c
> > > > +++ b/svkbd.c
> > > > @@ -481,9 +481,18 @@ press(Key *k, KeySym buttonmod)
> > > > int
> > > > tmp_remap(KeySym keysym)
> > > > {
> > > > - XChangeKeyboardMapping(dpy, tmp_keycode, 1, , 1);
> > > > + /* map lower and upper case of keysym to the temporary keycode
> > > > */
> > > > + KeySym syms[2];
> > > > + XConvertCase(keysym, [0], [1]);
> > > > +
> > > > + /* if keysym is capital letter then swap upper and lower case */
> > > > + if (keysym == syms[1])
> > > > + syms[1] = syms[0], syms[0] = keysym;
> > > > +
> > > > + XChangeKeyboardMapping(dpy, tmp_keycode, syms[0] == syms[1] ? 1
> > > > : 2, syms, 1);
> > > > XSync(dpy, False);
> > > >
> > > > +
Re: [hackers] [svkbd][PATCH] this patch fixes uppercase in armenian (and perhaps some other) layouts. svkbd was previously registering a key in one modification (xorg accepts up to 4 modifications). w
also no need to know armenian to test.
just run ./svkbd-mobile-intl and type lowercase and uppercase in armenian
layout.
do that for the patched version and you'll see the difference.
for some reason on sxmo/postmarketos i have to restart the device in order to
run a newer binary. though i think i checked that when i remove the keyboard
with a gesture, the process gets killed. and if i replace the binary and get
the keyboard with a gesture again, it should run the newer binary. but maybe
something changed now, because last time i was testing it, i had to restart the
device. this is irrelevant to svkbd, i just think of how you will test it, in
case you will test it on sxmo/postmarketos the restart might be needed.
On Wed, 13 Dec 2023 16:21:04 +0400
նորայր wrote:
> ok let me try to explain this very simply.
> some time ago i have added armenian and dvorak layouts.
> i have noticed that in dvorak and all other layouts uppercase characters work.
> while you don't have to do any extra effort for that. let's say:
>
> ```
> { 0, 0, XK_a, 1 },
> { 0, 0, XK_o, 1 },
> { 0, 0, XK_e, 1 },
> { 0, 0, XK_u, 1 },
> { 0, 0, XK_i, 1 },
> { 0, 0, XK_d, 1 },
> ```
>
> notice that layout describes only the lowercase variant, and the uppercase
> works automagically.
>
> same with cyrillic:
>
> ```
> { "й", 0, XK_Cyrillic_shorti, 1 },
> { "ц", 0, XK_Cyrillic_tse, 1 },
> { "у", 0, XK_Cyrillic_u, 1 },
> { "к", 0, XK_Cyrillic_ka, 1 },
> { "е", 0, XK_Cyrillic_ie, 1 },
> ```
>
> one doesn't even have to specify the uppercase variant.
> my guess is that the conversion is done by Xorg automatically for some
> layouts. i don't know why and how.
>
> however this approach didn't work with armenian layout (i guess it won't work
> with many other layouts), so i had to specify both uppercase and lowercase
> variants:
>
> ```
> { "ճ", "Ճ", XK_Armenian_tche, 1 },
> { "փ", "Փ", XK_Armenian_pyur, 1 },
> { "բ", "Բ", XK_Armenian_ben, 1 },
> { "ս", "Ս", XK_Armenian_se, 1 },
> { "մ", "Մ", XK_Armenian_men, 1 },
> { "ո", "Ո", XK_Armenian_vo, 1 },
> { "ւ", "Ւ", XK_Armenian_vyun, 1 },
> ```
>
> though i have had specified the uppercase letters, they were painted on the
> keyboard, but didn't work.
>
> now with this patch (see the commit message for more details) uppercase
> letters work.
> my guess is this will fix the behaviour not only for armenian, but for many
> other layouts for which Xorg doesn't have a method to get the uppercase
> symbol automatically for some reason.
> my guess is that cyrillic and latin are for some reason handled differently
> by xorg than the majority of other character sets.
>
> and one more detail, though this commit fixes almost every letter in armenian
> layout, one thing still don't work. namely, this line:
> { "՝","՜", XK_Armenian_exclam, 1 },
>
> for some reason only the second character described in this line ("՜") gets
> printed whether the shift is pressed or not. i will try to understand why
> this doesn't work some other day.
>
> but the commit fixes everything. i have this fix for a year already and i
> need to recompile svkbd every time after update, and restart the device, so
> if this is applied, it will simplify my life a lot.
>
> so to stress it again: this is not only relevant to armenian layout.
>
>
>
>
> On Sun, 3 Dec 2023 21:48:09 +0100
> Hiltjo Posthuma wrote:
>
> > On Sun, Dec 03, 2023 at 08:22:04PM +0400, norayr chilingarian wrote:
> > > ---
> > > svkbd.c | 11 ++-
> > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/svkbd.c b/svkbd.c
> > > index e4dbd15..cce2463 100644
> > > --- a/svkbd.c
> > > +++ b/svkbd.c
> > > @@ -481,9 +481,18 @@ press(Key *k, KeySym buttonmod)
> > > int
> > > tmp_remap(KeySym keysym)
> > > {
> > > - XChangeKeyboardMapping(dpy, tmp_keycode, 1, , 1);
> > > + /* map lower and upper case of keysym to the temporary keycode */
> > > + KeySym syms[2];
> > > + XConvertCase(keysym, [0], [1]);
> > > +
> > > + /* if keysym is capital letter then swap upper and lower case */
> > > + if (keysym == syms[1])
> > > + syms[1] = syms[0], syms[0] = keysym;
> > > +
> > > + XChangeKeyboardMapping(dpy, tmp_keycode, syms[0] == syms[1] ? 1 : 2,
> > > syms, 1);
> > > XSync(dpy, False);
> > >
> > > + printdbg("Temorary map keysym %ld (%ld, %ld) to keycode %d\n", keysym,
> > > syms[0], syms[1], tmp_keycode);
> > > return tmp_keycode;
> > > }
> > >
> > > --
> > > 2.41.0
> > >
> > >
> >
> > Thanks for the patch,
> >
> > I'm not a svkbd user right now and also not Armenian.
> >
> > Can anyone test this and report if it makes sense?
> >
> > Thanks,
> >
> > --
> > Kind regards,
> > Hiltjo
> >
>
>
> --
> There are two ways of constructing a software design. One way is to make it
> so simple that there are obviously no deficiencies. And the
Re: [hackers] [svkbd][PATCH] this patch fixes uppercase in armenian (and perhaps some other) layouts. svkbd was previously registering a key in one modification (xorg accepts up to 4 modifications). w
ok let me try to explain this very simply.
some time ago i have added armenian and dvorak layouts.
i have noticed that in dvorak and all other layouts uppercase characters work.
while you don't have to do any extra effort for that. let's say:
```
{ 0, 0, XK_a, 1 },
{ 0, 0, XK_o, 1 },
{ 0, 0, XK_e, 1 },
{ 0, 0, XK_u, 1 },
{ 0, 0, XK_i, 1 },
{ 0, 0, XK_d, 1 },
```
notice that layout describes only the lowercase variant, and the uppercase
works automagically.
same with cyrillic:
```
{ "й", 0, XK_Cyrillic_shorti, 1 },
{ "ц", 0, XK_Cyrillic_tse, 1 },
{ "у", 0, XK_Cyrillic_u, 1 },
{ "к", 0, XK_Cyrillic_ka, 1 },
{ "е", 0, XK_Cyrillic_ie, 1 },
```
one doesn't even have to specify the uppercase variant.
my guess is that the conversion is done by Xorg automatically for some layouts.
i don't know why and how.
however this approach didn't work with armenian layout (i guess it won't work
with many other layouts), so i had to specify both uppercase and lowercase
variants:
```
{ "ճ", "Ճ", XK_Armenian_tche, 1 },
{ "փ", "Փ", XK_Armenian_pyur, 1 },
{ "բ", "Բ", XK_Armenian_ben, 1 },
{ "ս", "Ս", XK_Armenian_se, 1 },
{ "մ", "Մ", XK_Armenian_men, 1 },
{ "ո", "Ո", XK_Armenian_vo, 1 },
{ "ւ", "Ւ", XK_Armenian_vyun, 1 },
```
though i have had specified the uppercase letters, they were painted on the
keyboard, but didn't work.
now with this patch (see the commit message for more details) uppercase letters
work.
my guess is this will fix the behaviour not only for armenian, but for many
other layouts for which Xorg doesn't have a method to get the uppercase symbol
automatically for some reason.
my guess is that cyrillic and latin are for some reason handled differently by
xorg than the majority of other character sets.
and one more detail, though this commit fixes almost every letter in armenian
layout, one thing still don't work. namely, this line:
{ "՝","՜", XK_Armenian_exclam, 1 },
for some reason only the second character described in this line ("՜") gets
printed whether the shift is pressed or not. i will try to understand why this
doesn't work some other day.
but the commit fixes everything. i have this fix for a year already and i need
to recompile svkbd every time after update, and restart the device, so if this
is applied, it will simplify my life a lot.
so to stress it again: this is not only relevant to armenian layout.
On Sun, 3 Dec 2023 21:48:09 +0100
Hiltjo Posthuma wrote:
> On Sun, Dec 03, 2023 at 08:22:04PM +0400, norayr chilingarian wrote:
> > ---
> > svkbd.c | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/svkbd.c b/svkbd.c
> > index e4dbd15..cce2463 100644
> > --- a/svkbd.c
> > +++ b/svkbd.c
> > @@ -481,9 +481,18 @@ press(Key *k, KeySym buttonmod)
> > int
> > tmp_remap(KeySym keysym)
> > {
> > - XChangeKeyboardMapping(dpy, tmp_keycode, 1, , 1);
> > + /* map lower and upper case of keysym to the temporary keycode */
> > + KeySym syms[2];
> > + XConvertCase(keysym, [0], [1]);
> > +
> > + /* if keysym is capital letter then swap upper and lower case */
> > + if (keysym == syms[1])
> > + syms[1] = syms[0], syms[0] = keysym;
> > +
> > + XChangeKeyboardMapping(dpy, tmp_keycode, syms[0] == syms[1] ? 1 : 2,
> > syms, 1);
> > XSync(dpy, False);
> >
> > + printdbg("Temorary map keysym %ld (%ld, %ld) to keycode %d\n", keysym,
> > syms[0], syms[1], tmp_keycode);
> > return tmp_keycode;
> > }
> >
> > --
> > 2.41.0
> >
> >
>
> Thanks for the patch,
>
> I'm not a svkbd user right now and also not Armenian.
>
> Can anyone test this and report if it makes sense?
>
> Thanks,
>
> --
> Kind regards,
> Hiltjo
>
--
There are two ways of constructing a software design. One way is to make it so
simple that there are obviously no deficiencies. And the other way is to make
it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
pgp_iE9TIQXP0.pgp
Description: PGP signature
Re: [hackers] [sbase] sbase-box: Fix segmentation fault when exe without args
Hi, On Fri, Dec 01, 2023 at 01:33:36PM +0100, Jules Maselbas wrote: > when sbase-box is executed without argument, the check sbase-box > options doesn't verify the argument count leading to a segfault. > > Add a check on the argc before parsing sbase-box options (currently > only `-i`) Applied, thanks!
Re: [hackers] [sbase][PATCH] ed: Allow newlines in a Substitute Command
Hi, On Wed, Nov 15, 2023 at 08:56:56AM +0100, Rene Kita wrote: > > I think the way to fix this problem is reading the full command before > > executing it, otherwise there are so many traps. I am going to try to > > fix this in th enext days. > > I had the same idea. Reading the full command will put the > logic to detect the end of the command in one place. This should give > better code. > > Also, you will have to change how addresses for the global command are > collected/remembered. We need to act on the original lines and not on > the lines inserted by a global command. I have sent the patches to the hacker ml. I tested them for a few days and it seems to work fine, but would be wonderful if you can take a look and see if they are fine for you too. Regards,
Re: [hackers] [svkbd][PATCH] this patch fixes uppercase in armenian (and perhaps some other) layouts. svkbd was previously registering a key in one modification (xorg accepts up to 4 modifications). w
On Sun, Dec 03, 2023 at 08:22:04PM +0400, norayr chilingarian wrote:
> ---
> svkbd.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/svkbd.c b/svkbd.c
> index e4dbd15..cce2463 100644
> --- a/svkbd.c
> +++ b/svkbd.c
> @@ -481,9 +481,18 @@ press(Key *k, KeySym buttonmod)
> int
> tmp_remap(KeySym keysym)
> {
> - XChangeKeyboardMapping(dpy, tmp_keycode, 1, , 1);
> + /* map lower and upper case of keysym to the temporary keycode */
> + KeySym syms[2];
> + XConvertCase(keysym, [0], [1]);
> +
> + /* if keysym is capital letter then swap upper and lower case */
> + if (keysym == syms[1])
> + syms[1] = syms[0], syms[0] = keysym;
> +
> + XChangeKeyboardMapping(dpy, tmp_keycode, syms[0] == syms[1] ? 1 : 2,
> syms, 1);
> XSync(dpy, False);
>
> + printdbg("Temorary map keysym %ld (%ld, %ld) to keycode %d\n", keysym,
> syms[0], syms[1], tmp_keycode);
> return tmp_keycode;
> }
>
> --
> 2.41.0
>
>
Thanks for the patch,
I'm not a svkbd user right now and also not Armenian.
Can anyone test this and report if it makes sense?
Thanks,
--
Kind regards,
Hiltjo
Re: [hackers] [sbase][PATCH] ed: Allow newlines in a Substitute Command
On Tue, Nov 14, 2023 at 07:42:03PM +0100, Roberto E. Vargas Caballero wrote: > Hi, > > On Sun, Nov 05, 2023 at 02:38:20PM +0100, Rene Kita wrote: > > On Fri, Nov 03, 2023 at 01:32:37PM +0100, Rene Kita wrote: > > > borked patch > > > > Patch is not sufficient, sorry for the noise. > [...] > I think the way to fix this problem is reading the full command before > executing it, otherwise there are so many traps. I am going to try to > fix this in th enext days. I had the same idea. Reading the full command will put the logic to detect the end of the command in one place. This should give better code. Also, you will have to change how addresses for the global command are collected/remembered. We need to act on the original lines and not on the lines inserted by a global command.
Re: [hackers] [sbase][PATCH] ed: Allow newlines in a Substitute Command
Hi, On Sun, Nov 05, 2023 at 02:38:20PM +0100, Rene Kita wrote: > On Fri, Nov 03, 2023 at 01:32:37PM +0100, Rene Kita wrote: > > borked patch > > Patch is not sufficient, sorry for the noise. I have this problem in my radar. I began to write a solution for it, but I had to switch to implement bc(1) that I hope I will submit soon. I think the way to fix this problem is reading the full command before executing it, otherwise there are so many traps. I am going to try to fix this in th enext days. Regards,
Re: [hackers] [sbase] TODO: add replacement bug reported for ed || Hiltjo Posthuma
Applied, thanks.
Re: [hackers] [PATCH] find: Make parameter error messages more specific
Applied, thanks.
Re: [hackers] [PATCH 2/2] scripts: Fix non-portable find -perm /mode
Applied, thanks.
Re: [hackers] [PATCH 1/2] scripts: Fix non-portable usage of find -maxdepth
Applied, thanks.
Re: [hackers] [PATCH] scripts: Force file copying on install
Applied, thanks.
Re: [hackers] [PATCH] make: fix rogue parameter in install target
Applied, thanks.
Re: [hackers] [sbase][PATCH] ed: Allow newlines in a Substitute Command
On Fri, Nov 03, 2023 at 01:32:37PM +0100, Rene Kita wrote: > borked patch Patch is not sufficient, sorry for the noise.
Re: [hackers] [PATCH 2/2] scripts: Fix non-portable find -perm /mode
> > I guess that the original intent of the code here > > was to to find any executable file. > > I concur. It seems to me that the default output mode for `cc` is 755 > even if the parent directory has more restrictive permissions. So the > more concise -perm -111 should suffice. I will leave the decision up > to Roberto though. Well, the file creation mode for the executables is 777, with user umask applied, so could be anything really, like absent executable bit for others. The install script though, once executables have been identified, changes the target file mode to 755. I'm not fond of that method, especially that we already know the name of target executables. I guess I'll propose some improvement there at some point.
Re: [hackers] [PATCH 2/2] scripts: Fix non-portable find -perm /mode
> Not exactly, -perm -111 matches if at least the mode has executable bit > for all (could be 751 for example), > while GNU -perm /111 matches if any bit is set (could be 500). Thanks for the info, I didn't really check the GNU manpage. > I guess that the original intent of the code here > was to to find any executable file. I concur. It seems to me that the default output mode for `cc` is 755 even if the parent directory has more restrictive permissions. So the more concise -perm -111 should suffice. I will leave the decision up to Roberto though.
Re: [hackers] [PATCH 2/2] scripts: Fix non-portable find -perm /mode
> Hi Quentin, Hola Randy, > > -find . ! -name . -prune -type f -perm /111 | > > +find . ! -name . -prune -type f \( -perm -u+x -o -perm -g+x -o -perm o+x > > \) | > > I believe `-perm -111` is equivalent and specified by POSIX. Not exactly, -perm -111 matches if at least the mode has executable bit for all (could be 751 for example), while GNU -perm /111 matches if any bit is set (could be 500). I guess that the original intent of the code here was to to find any executable file.
Re: [hackers] [PATCH 2/2] scripts: Fix non-portable find -perm /mode
Hi Quentin, > -find . ! -name . -prune -type f -perm /111 | > +find . ! -name . -prune -type f \( -perm -u+x -o -perm -g+x -o -perm o+x \) | I believe `-perm -111` is equivalent and specified by POSIX. - Randy
Re: [hackers] [st][PATCH] Add terminfo entries for bracketed paste mode
On Thu, Oct 12, 2023 at 12:40:15PM +0200, Peter Hofmann wrote: > It has been brought to my attention that this patch breaks pasting text > in older versions of Vim, e.g. the ones coming with OpenBSD 7.2 or > Ubuntu 22.04. The ncurses terminfo db mentions that Vim 9.0.1117 or > newer is needed. > > IIUC, old Vim doesn't read PS/PE from terminfo but it does read BE/BD, > so it gets totally confused. (When you paste something, st sends PS but > Vim doesn't expect it -- and the first character of PS is '\e', so Vim > switches back from insert mode to normal mode, and then chaos ensues.) > > I guess you might want to revert that patch and we can try again in a > couple of years. Sorry. > > If you keep the patch, then bracketed paste mode works out-of-the-box > for users of newer Vim versions, but users of older Vim versions must > fix this situation in their .vimrc, for example by specifying the > missing sequences: > > exec "set t_PS=\e[200~" > exec "set t_PE=\e[201~" > > Best regards, > Peter > Hi Peter, No worries, I'll leave it as is unless many people will complain. I don't use vim. -- Kind regards, Hiltjo
Re: [hackers] [st][PATCH] Add terminfo entries for bracketed paste mode
It has been brought to my attention that this patch breaks pasting text in older versions of Vim, e.g. the ones coming with OpenBSD 7.2 or Ubuntu 22.04. The ncurses terminfo db mentions that Vim 9.0.1117 or newer is needed. IIUC, old Vim doesn't read PS/PE from terminfo but it does read BE/BD, so it gets totally confused. (When you paste something, st sends PS but Vim doesn't expect it -- and the first character of PS is '\e', so Vim switches back from insert mode to normal mode, and then chaos ensues.) I guess you might want to revert that patch and we can try again in a couple of years. Sorry. If you keep the patch, then bracketed paste mode works out-of-the-box for users of newer Vim versions, but users of older Vim versions must fix this situation in their .vimrc, for example by specifying the missing sequences: exec "set t_PS=\e[200~" exec "set t_PE=\e[201~" Best regards, Peter
Re: [hackers] [st][PATCH] Unhide cursor on RIS (\033c)
Hi Hiltjo, you're welcome, and thanks for merging. Cheers Peter
Re: [hackers] [st][PATCH] Unhide cursor on RIS (\033c)
On Sat, Oct 07, 2023 at 07:40:45AM +0200, Peter Hofmann wrote: > From: Peter Hofmann > > It is unclear if it's "required" to do this on RIS, but it's useful when > calling reset(1) after interactive programs have crashed and garbled up > the screen. > > FWIW, other terminals do it as well (tested with XTerm, VTE, Kitty, > Alacritty, Linux VT). > --- > st.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/st.c b/st.c > index 4754c87..d6478f5 100644 > --- a/st.c > +++ b/st.c > @@ -2330,6 +2330,7 @@ eschandle(uchar ascii) > treset(); > resettitle(); > xloadcols(); > + xsetmode(0, MODE_HIDE); > break; > case '=': /* DECPAM -- Application keypad */ > xsetmode(1, MODE_APPKEYPAD); > -- > 2.42.0 > > Hi Peter, Thanks for all the patches and clear steps to reproduce the issues :) I've pushed the patches to the master branch. -- Kind regards, Hiltjo
Re: [hackers] [dwm][PATCH] Implement key shortcut mapping
On 230924-093006, Hiltjo Posthuma 'hil...@codemadness.org' wrote:
>
>
>On Sun, Sep 24, 2023 at 05:34:48AM +, suiso67@macadamia.rocks wrote:
>> From: suiso67
>>
>> ---
>> config.def.h | 43 +++
>> dwm.c| 47 +++
>> 2 files changed, 90 insertions(+)
>>
>> diff --git a/config.def.h b/config.def.h
>> index 061ad66..98ff36f 100644
>> --- a/config.def.h
>> +++ b/config.def.h
>> @@ -51,6 +51,8 @@ static const Layout layouts[] = {
>> { MODKEY|ControlMask, KEY, toggleview, {.ui = 1 <<
>> TAG} }, \
>> { MODKEY|ShiftMask, KEY, tag,{.ui = 1 <<
>> TAG} }, \
>> { MODKEY|ControlMask|ShiftMask, KEY, toggletag, {.ui = 1 <<
>> TAG} },
>> +#define KEYEVENT(SRC_MOD,SRC_KEY,DST_MOD,DST_KEY) \
>> +{ SRC_MOD, SRC_KEY, sendkeyevent, { .v = &(const KeyShortcut){ DST_MOD,
>> DST_KEY } } },
>>
>> /* helper for spawning shell commands in the pre dwm-5.0 fashion */
>> #define SHCMD(cmd) { .v = (const char*[]){ "/bin/sh", "-c", cmd, NULL } }
>> @@ -84,6 +86,47 @@ static const Key keys[] = {
>> { MODKEY, XK_period, focusmon, {.i = +1 } },
>> { MODKEY|ShiftMask, XK_comma, tagmon, {.i = -1 } },
>> { MODKEY|ShiftMask, XK_period, tagmon, {.i = +1 } },
>> +// Navigation(two-handed)
>> +KEYEVENT(Mod1Mask, XK_h, 0, XK_Left)
>> +KEYEVENT(Mod1Mask, XK_l, 0, XK_Right)
>> +KEYEVENT(Mod1Mask, XK_k, 0, XK_Up)
>> +KEYEVENT(Mod1Mask, XK_j, 0, XK_Down)
>> +KEYEVENT(Mod1Mask, XK_p, 0, XK_Up)
>> +KEYEVENT(Mod1Mask, XK_n, 0, XK_Down)
>> +KEYEVENT(Mod1Mask, XK_i, ControlMask, XK_Left)
>> +KEYEVENT(Mod1Mask, XK_o, ControlMask, XK_Right)
>> +KEYEVENT(Mod1Mask, XK_q, ControlMask, XK_Left)
>> +KEYEVENT(Mod1Mask, XK_w, ControlMask, XK_Right)
>> +KEYEVENT(Mod1Mask, XK_equal, ControlMask, XK_Home)
>> +KEYEVENT(Mod1Mask, XK_minus, ControlMask, XK_End)
>> +// Navigation(one-handed)
>> +KEYEVENT(Mod1Mask, XK_s, 0, XK_Up)
>> +KEYEVENT(Mod1Mask, XK_x, 0, XK_Down)
>> +KEYEVENT(Mod1Mask, XK_z, 0, XK_Left)
>> +KEYEVENT(Mod1Mask, XK_c, 0, XK_Right)
>> +KEYEVENT(Mod1Mask, XK_d, 0, XK_Return)
>> +KEYEVENT(Mod1Mask, XK_a, 0, XK_Home)
>> +KEYEVENT(Mod1Mask, XK_e, 0, XK_End)
>> +// Selection(two-handed)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_h, ShiftMask, XK_Left)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_l, ShiftMask, XK_Right)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_k, ShiftMask, XK_Up)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_j, ShiftMask, XK_Down)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_p, ShiftMask, XK_Up)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_n, ShiftMask, XK_Down)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_i, ControlMask|ShiftMask, XK_Left)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_o, ControlMask|ShiftMask, XK_Right)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_equal, ControlMask|ShiftMask, XK_Home)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_minus, ControlMask|ShiftMask, XK_End)
>> +// Selection(one-handed)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_s, ShiftMask, XK_Up)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_x, ShiftMask, XK_Down)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_z, ShiftMask, XK_Left)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_c, ShiftMask, XK_Right)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_q, ControlMask|ShiftMask, XK_Left)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_w, ControlMask|ShiftMask, XK_Right)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_a, ShiftMask, XK_Home)
>> +KEYEVENT(Mod1Mask|ShiftMask, XK_e, ShiftMask, XK_End)
>> TAGKEYS(XK_1, 0)
>> TAGKEYS(XK_2, 1)
>> TAGKEYS(XK_3, 2)
>> diff --git a/dwm.c b/dwm.c
>> index e5efb6a..6988c77 100644
>> --- a/dwm.c
>> +++ b/dwm.c
>> @@ -106,6 +106,11 @@ typedef struct {
>> const Arg arg;
>> } Key;
>>
>> +typedef struct {
>> +unsigned int mod;
>> +KeySym keysym;
>> +} KeyShortcut;
>> +
>> typedef struct {
>> const char *symbol;
>> void (*arrange)(Monitor *);
>> @@ -196,6 +201,7 @@ static void restack(Monitor *m);
>> static void run(void);
>> static void scan(void);
>> static int sendevent(Client *c, Atom proto);
>> +static void sendkeyevent(const Arg *arg);
>> static void sendmon(Client *c, Monitor *m);
>> static void setclientstate(Client *c, long state);
>> static void setfocus(Client *c);
>> @@ -1458,6 +1464,47 @@ sendevent(Client *c, Atom proto)
>> return exists;
>> }
>>
>> +XKeyEvent
>> +createkeyevent(Display *display, Window win, Window rootWindow, int type,
>> KeyShortcut *keyShortcut)
>> +{
>> +int keysym = keyShortcut->keysym;
>> +unsigned int modifier = keyShortcut->mod;
>> +
>> +XKeyEvent event;
>> +event.type = type;
>> +event.display = display;
>> +event.window =
Re: [hackers] [sbase][PATCH] Ensure commands are followed by a blank
Applied.
Re: [hackers] [st] [PATCH] Makefile: always output the build options, even when building with install
On Fri, 2023-09-22 at 15:12 +0200, Hiltjo Posthuma wrote: > On Sun, Sep 17, 2023 at 12:11:28AM +, Tom Schwindl wrote: > > --- > > Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Makefile b/Makefile > > index 470ac86407bb..6eb2d9d04852 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -40,7 +40,7 @@ dist: clean > > tar -cf - st-$(VERSION) | gzip > st-$(VERSION).tar.gz > > rm -rf st-$(VERSION) > > > > -install: st > > +install: all Wouldn't be best that install does not build stuff? Because sudo make install could possibly build files as root if the user forgot to run make before. -- David
Re: [hackers] [dwm][PATCH] Implement key shortcut mapping
On Sun, Sep 24, 2023 at 05:34:48AM +, suiso67@macadamia.rocks wrote:
> From: suiso67
>
> ---
> config.def.h | 43 +++
> dwm.c| 47 +++
> 2 files changed, 90 insertions(+)
>
> diff --git a/config.def.h b/config.def.h
> index 061ad66..98ff36f 100644
> --- a/config.def.h
> +++ b/config.def.h
> @@ -51,6 +51,8 @@ static const Layout layouts[] = {
> { MODKEY|ControlMask, KEY, toggleview, {.ui = 1 <<
> TAG} }, \
> { MODKEY|ShiftMask, KEY, tag,{.ui = 1 <<
> TAG} }, \
> { MODKEY|ControlMask|ShiftMask, KEY, toggletag, {.ui = 1 <<
> TAG} },
> +#define KEYEVENT(SRC_MOD,SRC_KEY,DST_MOD,DST_KEY) \
> + { SRC_MOD, SRC_KEY, sendkeyevent, { .v = &(const KeyShortcut){ DST_MOD,
> DST_KEY } } },
>
> /* helper for spawning shell commands in the pre dwm-5.0 fashion */
> #define SHCMD(cmd) { .v = (const char*[]){ "/bin/sh", "-c", cmd, NULL } }
> @@ -84,6 +86,47 @@ static const Key keys[] = {
> { MODKEY, XK_period, focusmon, {.i = +1 } },
> { MODKEY|ShiftMask, XK_comma, tagmon, {.i = -1 } },
> { MODKEY|ShiftMask, XK_period, tagmon, {.i = +1 } },
> + // Navigation(two-handed)
> + KEYEVENT(Mod1Mask, XK_h, 0, XK_Left)
> + KEYEVENT(Mod1Mask, XK_l, 0, XK_Right)
> + KEYEVENT(Mod1Mask, XK_k, 0, XK_Up)
> + KEYEVENT(Mod1Mask, XK_j, 0, XK_Down)
> + KEYEVENT(Mod1Mask, XK_p, 0, XK_Up)
> + KEYEVENT(Mod1Mask, XK_n, 0, XK_Down)
> + KEYEVENT(Mod1Mask, XK_i, ControlMask, XK_Left)
> + KEYEVENT(Mod1Mask, XK_o, ControlMask, XK_Right)
> + KEYEVENT(Mod1Mask, XK_q, ControlMask, XK_Left)
> + KEYEVENT(Mod1Mask, XK_w, ControlMask, XK_Right)
> + KEYEVENT(Mod1Mask, XK_equal, ControlMask, XK_Home)
> + KEYEVENT(Mod1Mask, XK_minus, ControlMask, XK_End)
> + // Navigation(one-handed)
> + KEYEVENT(Mod1Mask, XK_s, 0, XK_Up)
> + KEYEVENT(Mod1Mask, XK_x, 0, XK_Down)
> + KEYEVENT(Mod1Mask, XK_z, 0, XK_Left)
> + KEYEVENT(Mod1Mask, XK_c, 0, XK_Right)
> + KEYEVENT(Mod1Mask, XK_d, 0, XK_Return)
> + KEYEVENT(Mod1Mask, XK_a, 0, XK_Home)
> + KEYEVENT(Mod1Mask, XK_e, 0, XK_End)
> + // Selection(two-handed)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_h, ShiftMask, XK_Left)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_l, ShiftMask, XK_Right)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_k, ShiftMask, XK_Up)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_j, ShiftMask, XK_Down)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_p, ShiftMask, XK_Up)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_n, ShiftMask, XK_Down)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_i, ControlMask|ShiftMask, XK_Left)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_o, ControlMask|ShiftMask, XK_Right)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_equal, ControlMask|ShiftMask, XK_Home)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_minus, ControlMask|ShiftMask, XK_End)
> + // Selection(one-handed)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_s, ShiftMask, XK_Up)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_x, ShiftMask, XK_Down)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_z, ShiftMask, XK_Left)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_c, ShiftMask, XK_Right)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_q, ControlMask|ShiftMask, XK_Left)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_w, ControlMask|ShiftMask, XK_Right)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_a, ShiftMask, XK_Home)
> + KEYEVENT(Mod1Mask|ShiftMask, XK_e, ShiftMask, XK_End)
> TAGKEYS(XK_1, 0)
> TAGKEYS(XK_2, 1)
> TAGKEYS(XK_3, 2)
> diff --git a/dwm.c b/dwm.c
> index e5efb6a..6988c77 100644
> --- a/dwm.c
> +++ b/dwm.c
> @@ -106,6 +106,11 @@ typedef struct {
> const Arg arg;
> } Key;
>
> +typedef struct {
> + unsigned int mod;
> + KeySym keysym;
> +} KeyShortcut;
> +
> typedef struct {
> const char *symbol;
> void (*arrange)(Monitor *);
> @@ -196,6 +201,7 @@ static void restack(Monitor *m);
> static void run(void);
> static void scan(void);
> static int sendevent(Client *c, Atom proto);
> +static void sendkeyevent(const Arg *arg);
> static void sendmon(Client *c, Monitor *m);
> static void setclientstate(Client *c, long state);
> static void setfocus(Client *c);
> @@ -1458,6 +1464,47 @@ sendevent(Client *c, Atom proto)
> return exists;
> }
>
> +XKeyEvent
> +createkeyevent(Display *display, Window win, Window rootWindow, int type,
> KeyShortcut *keyShortcut)
> +{
> + int keysym = keyShortcut->keysym;
> + unsigned int modifier = keyShortcut->mod;
> +
> + XKeyEvent event;
> + event.type = type;
> + event.display = display;
> + event.window = win;
> + event.root = rootWindow;
> + event.subwindow = None;
> + event.time = CurrentTime;
> +
Re: [hackers] [st] [PATCH] Makefile: always output the build options, even when building with install
On Sun, Sep 17, 2023 at 12:11:28AM +, Tom Schwindl wrote: > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 470ac86407bb..6eb2d9d04852 100644 > --- a/Makefile > +++ b/Makefile > @@ -40,7 +40,7 @@ dist: clean > tar -cf - st-$(VERSION) | gzip > st-$(VERSION).tar.gz > rm -rf st-$(VERSION) > > -install: st > +install: all > mkdir -p $(DESTDIR)$(PREFIX)/bin > cp -f st $(DESTDIR)$(PREFIX)/bin > chmod 755 $(DESTDIR)$(PREFIX)/bin/st > -- > 2.40.0 > > Thanks, I've pushed changes to dwm, dmenu and st to just remove this target. A detailed description of why is in the commit message. -- Kind regards, Hiltjo
Re: [hackers] [sbase][PATCH] xargs: implement -I flag
Hi,
On Sun, Jul 30, 2023 at 10:15:49AM +0300, sewn wrote:
> From 9f4be567ff25fee986976c6afa193223496013a6 Mon Sep 17 00:00:00 2001
> From: sewn
> Date: Fri, 28 Jul 2023 18:58:37 +0300
> Subject: [PATCH] xargs: add replace string flag (-I)
I have applied the patch with some small modifications that I am going
to elaborate in the mail. There is still pending work to have a correct
-I implementation.
> diff --git a/libutil/strnsubst.c b/libutil/strnsubst.c
> new file mode 100644
> index 000..a76d484
> --- /dev/null
> +++ b/libutil/strnsubst.c
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright (c) 2002 J. Mallett. All rights reserved.
> + * You may do whatever you want with this file as long as
> + * the above copyright and this notice remain intact, along
> + * with the following statement:
> + * For the man who taught me vi, and who got too old, too young.
> + */
> +
> +#include
> +#include
> +#include
> +#include
unistd.h is not needed and it was removed.
> +void
> +strnsubst(char **str, const char *match, const char *replstr, size_t maxsize)
> +{
> + char *s1, *s2, *this;
> + size_t matchlen, repllen, s2len;
> + int n;
replen was set but it was not used, thus I remove it.
> +done:
> + *str = s2;
*str is holding a previously allocated string, so we have to free it.
> diff --git a/util.h b/util.h
> index 8d5004b..d6911bd 100644
> --- a/util.h
> +++ b/util.h
> @@ -63,6 +63,8 @@ size_t estrlcpy(char *, const char *, size_t);
> #define strsep xstrsep
> char *strsep(char **, const char *);
>
> +void strnsubst(char **str, const char *match, const char *replstr, size_t
> maxsize);
> +
We don't use parameter names in prototypes.
> @@ -252,7 +260,11 @@ main(int argc, char *argv[])
> leftover = 1;
> break;
> }
> - cmd[i] = estrdup(arg);
> + if (ri > 0)
> + strnsubst([ri], replstr, arg, (size_t)255);
> + else
> + cmd[i] = estrdup(arg);
> +
> argsz += arglen + 1;
> i++;
> a++;
the cast to size_t is not required because the prototype already does the work.
The problems with this implementation is that POSIX mandates that when -I is
used
then spaces don't break arguments and they are just separated by newlines. I
tried
something like:
- case ' ': case '\t': case '\n':
+ case ' ':
+ case '\t':
+ if (Iflag)
+ goto fill;
+ case '\n':
goto out;
case '\'':
if (parsequote('\'') < 0)
@@ -126,6 +130,7 @@ poparg(void)
eprintf("backslash at EOF\n");
break;
default:
+ fill:
fillargbuf(ch);
argbpos++;
break;
@@ -227,6 +232,7 @@ main(int argc, char *argv[])
eofstr = EARGF(usage());
break;
case 'I':
+ Iflag = 1;
xflag = 1;
nflag = 1;
maxargs = 1;
but we pass the full line (after removing leading spaces) to exec, being
a single parameter instead of being split. For example:
xargs -I x ls x <
Re: [hackers] [ubase][PATCH] Explicitly include sys/sysmacros.h for makedev etc
On Sun, Aug 06, 2023 at 03:03:21PM +0200, Markus Rudy wrote: > This header used to be included by sys/types.h in glibc, and musl > adopted the behaviour. However, this dependency was never desired, so > glibc deprecated it in 2016 and finally removed it in 2019, and so Applied.
Re: [hackers] [sbase][PATCH] tr: fix behavior of cflag when using character classes
Hi, On Sun, Aug 06, 2023 at 10:50:25PM +0200, noneofyourbusin...@danwin1210.de wrote: > a simple test case: > > printf ab3 | tr -c '[:alpha:]' '\n' Applied.
Re: [hackers] [dwm][PATCH] gruvbok dark hard color scheme
Open source writes: Some people like me find it beautiful, simple, and comfortable eye, It's a personal preference at the end of the day, it's just a simple patch for those who want it. This mailing list is for mainline patch submissions and discussion, please submit other things to the wiki. Thanks, Chris signature.asc Description: PGP signature
Re: [hackers] [dwm][PATCH] gruvbok dark hard color scheme
On 9/1/23 23:16, Ethan Marshall wrote: I do not like this color scheme, the old iconic suckless blue is much better! Why does it need changing? Some people like me find it beautiful, simple, and comfortable eye, It's a personal preference at the end of the day, it's just a simple patch for those who want it. `st` has a similar one btw OpenPGP_0x0501802A1D496528.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [hackers] [dwm][PATCH] gruvbok dark hard color scheme
> I do not like this color scheme, the old iconic suckless blue is much > better! Why does it need changing? It is possible that this was intended to be submitted to the wiki instead. In which case, http://suckless.org/hacking/. Ethan
Re: [hackers] [dwm][PATCH] gruvbok dark hard color scheme
On Fri, Sep 01, 2023 at 08:44:50PM +0300, anas.elgarhy@gmail.com wrote:
> From: Anas Elgarhy
>
> ---
> config.def.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/config.def.h b/config.def.h
> index 9efa774..d357f2c 100644
> --- a/config.def.h
> +++ b/config.def.h
> @@ -7,11 +7,11 @@ static const int showbar= 1;/* 0 means
> no bar */
> static const int topbar = 1;/* 0 means bottom bar */
> static const char *fonts[] = { "monospace:size=10" };
> static const char dmenufont[] = "monospace:size=10";
> -static const char col_gray1[] = "#22";
> -static const char col_gray2[] = "#44";
> -static const char col_gray3[] = "#bb";
> -static const char col_gray4[] = "#ee";
> -static const char col_cyan[]= "#005577";
> +static const char col_gray1[] = "#1D2021";
> +static const char col_gray2[] = "#928374";
> +static const char col_gray3[] = "#EBDBB2";
> +static const char col_gray4[] = "#98971A";
> +static const char col_cyan[]= "#32302F";
> static const char *colors[][3] = {
> /* fg bg border */
> [SchemeNorm] = { col_gray3, col_gray1, col_gray2 },
> --
> 2.42.0
I do not like this color scheme, the old iconic suckless blue is much
better! Why does it need changing?
--
Christopher
Re: [hackers] [dmenu][PATCH] Allow only one dmenu_run selection
On Wed, Aug 30, 2023 at 11:25:18AM -0700, Jeremy wrote:
> On 08/30/23 05:41PM, Christopher Lang wrote:
> > This would be my implementation for executing all selected commands:
> >
> > #!/bin/sh
> > for x in $(dmenu_path | dmenu "$@"); do
> > echo "$x" | ${SHELL:-"/bin/sh"} &
> > done
> >
> > I suppose this behaviour is more intuitive, but it is a little more
> > complicated. What are peoples preferences between original patch and
> > executing all commands?
> >
>
> The darker color on the "selected" items makes me think the blocking
> effect of the `$()` makes the most sense, with two exceptions:
> - the selected options are run in the same order as the input
> - each selected option is only run once
>
> Which would look like:
>
> #!/bin/sh
> t=$(mktemp)
> dmenu_path | tee "$t" | dmenu "$@" | awk 'NR==FNR { x[$0]++; next } x[$0]' -
> "$t" | sh -x
>
> Jeremy
>
If this route is taken I think it would make more sense to not print the lines
directly when CTRL-Enter is used to select multiple lines.
And flush all selected lines on output.
This would make sense for dmenu_run but not some existing scripts that use it.
--
Kind regards,
Hiltjo
Re: [hackers] [dmenu][PATCH] Allow only one dmenu_run selection
On Wed, Aug 30, 2023 at 05:41:28PM +0100, Christopher Lang wrote:
> On Wed, Aug 30, 2023 at 05:48:13PM +0200, Страхиња Радић wrote:
> > On 23/08/30 09:43AM, Randy Palamar wrote:
> > > Personally I see little need for such a patch. I don't really
> > > think anyone is pressing + by mistake; they
> > > are nowhere near each other on most (all?) keyboard layouts.
>
> A dmenu script in the dmenu repository should set the example for how to
> properly use dmenu. If dmenu_run has this (albiet small) bug, then it
> could make users assume dmenu always outputs a single line.
>
> > > Actually I didn't even know about this feature despite using
> > > dmenu in a number of different scripts for many years. I'm
> > > already thinking of some use cases.
>
> If users saw that dmenu_run was handling multi line output from dmenu,
> it could alert them to this feature.
>
> > I would actually turn this patch the other way around--and have multiple
> > selection execute all the selected commands.
>
> This would be my implementation for executing all selected commands:
>
> #!/bin/sh
> for x in $(dmenu_path | dmenu "$@"); do
> echo "$x" | ${SHELL:-"/bin/sh"} &
> done
>
> I suppose this behaviour is more intuitive, but it is a little more
> complicated. What are peoples preferences between original patch and
> executing all commands?
>
> --
> Christopher
>
Hi,
If it is a bug then I think it would make more sense to execute all current
output lines.
Currently when you CTRL-Enter on an entry the output will not directly flush.
For example you could type "st" and press CTRL-ENTER 3 times and press escape.
Then it would still open st 3 times:
It is safer to use printf instead of echo, because echo interprets escape
sequences.
Concept patch below:
diff --git a/dmenu.c b/dmenu.c
index 40f93e0..4839f47 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -490,6 +490,7 @@ insert:
case XK_Return:
case XK_KP_Enter:
puts((sel && !(ev->state & ShiftMask)) ? sel->text : text);
+ fflush(stdout);
if (!(ev->state & ControlMask)) {
cleanup();
exit(0);
diff --git a/dmenu_run b/dmenu_run
index 834ede5..73d77ec 100755
--- a/dmenu_run
+++ b/dmenu_run
@@ -1,2 +1,4 @@
#!/bin/sh
-dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} &
+dmenu_path | dmenu "$@" | while read -r line; do
+ printf '%s' "${line}" | ${SHELL:-"/bin/sh"} &
+done
--
Kind regards,
Hiltjo
Re: [hackers] [dmenu][PATCH] Allow only one dmenu_run selection
On 08/30/23 05:41PM, Christopher Lang wrote:
> This would be my implementation for executing all selected commands:
>
> #!/bin/sh
> for x in $(dmenu_path | dmenu "$@"); do
> echo "$x" | ${SHELL:-"/bin/sh"} &
> done
>
> I suppose this behaviour is more intuitive, but it is a little more
> complicated. What are peoples preferences between original patch and
> executing all commands?
>
The darker color on the "selected" items makes me think the blocking
effect of the `$()` makes the most sense, with two exceptions:
- the selected options are run in the same order as the input
- each selected option is only run once
Which would look like:
#!/bin/sh
t=$(mktemp)
dmenu_path | tee "$t" | dmenu "$@" | awk 'NR==FNR { x[$0]++; next } x[$0]' -
"$t" | sh -x
Jeremy
Re: [hackers] [dmenu][PATCH] Allow only one dmenu_run selection
On Wed, Aug 30, 2023 at 05:48:13PM +0200, Страхиња Радић wrote:
> On 23/08/30 09:43AM, Randy Palamar wrote:
> > Personally I see little need for such a patch. I don't really
> > think anyone is pressing + by mistake; they
> > are nowhere near each other on most (all?) keyboard layouts.
A dmenu script in the dmenu repository should set the example for how to
properly use dmenu. If dmenu_run has this (albiet small) bug, then it
could make users assume dmenu always outputs a single line.
> > Actually I didn't even know about this feature despite using
> > dmenu in a number of different scripts for many years. I'm
> > already thinking of some use cases.
If users saw that dmenu_run was handling multi line output from dmenu,
it could alert them to this feature.
> I would actually turn this patch the other way around--and have multiple
> selection execute all the selected commands.
This would be my implementation for executing all selected commands:
#!/bin/sh
for x in $(dmenu_path | dmenu "$@"); do
echo "$x" | ${SHELL:-"/bin/sh"} &
done
I suppose this behaviour is more intuitive, but it is a little more
complicated. What are peoples preferences between original patch and
executing all commands?
--
Christopher
Re: [hackers] [dmenu][PATCH] Allow only one dmenu_run selection
On 23/08/30 09:43AM, Randy Palamar wrote: > Personally I see little need for such a patch. I don't really > think anyone is pressing + by mistake; they > are nowhere near each other on most (all?) keyboard layouts. > > Actually I didn't even know about this feature despite using > dmenu in a number of different scripts for many years. I'm > already thinking of some use cases. I would actually turn this patch the other way around--and have multiple selection execute all the selected commands. signature.asc Description: PGP signature
Re: [hackers] [dmenu][PATCH] Allow only one dmenu_run selection
On Wed, Aug 30, 2023 at 6:13 AM Christopher Lang
wrote:
>
> Using +, multiple selections can be make in dmenu, each
> outputting on a new line. If multiple selections are made in dmenu_run
> then multiple lines will be piped to $SHELL which will not be properly
> handled.
>
> This patch only pipes the last line of the output of dmenu to the shell.
> In effect, the last or only program you selected is run.
>
> I think its quite unintuitive that dmenu can output multiple lines, but
> I understand removing the feature may break some users' scripts. Perhaps
> a command option could be added to dissable multiple output.
> ---
> dmenu_run | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dmenu_run b/dmenu_run
> index 834ede5..d6bbe5d 100755
> --- a/dmenu_run
> +++ b/dmenu_run
> @@ -1,2 +1,2 @@
> #!/bin/sh
> -dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} &
> +dmenu_path | dmenu "$@" | tail -n 1 | ${SHELL:-"/bin/sh"} &
> --
> 2.42.0
Hi Christopher,
Personally I see little need for such a patch. I don't really
think anyone is pressing + by mistake; they
are nowhere near each other on most (all?) keyboard layouts.
Actually I didn't even know about this feature despite using
dmenu in a number of different scripts for many years. I'm
already thinking of some use cases.
All the best,
Randy
Re: [hackers] [dwm][patch] Stop input focus on pointers unselected monitor
On Sun, Aug 27, 2023 at 08:09:47PM +0100, Christopher Lang wrote: > To get more feedback on this patch, I will submit it to the wiki under > the name fixmultimon. In the patch wiki page, I will add a message > explaining it is intended for the mainline but is waiting for more > feedback. > > -- > Christopher > Hi, I've already received some feedback, also from IRC that this patch changes some peoples workflow or at least isn't what their used to. Considering this is how dwm works for many years now for multi-monitor users I will leave it as is for now. Not all dwm behaviours can please everyone, so hacking some of the source-code to ones preference is also intended. So I'm not ignoring your feedback, but I won't apply this patch for now (opinion may always change in the future of course). Thank you, -- Kind regards, Hiltjo
Re: [hackers] [dwm][patch] Stop input focus on pointers unselected monitor
To get more feedback on this patch, I will submit it to the wiki under the name fixmultimon. In the patch wiki page, I will add a message explaining it is intended for the mainline but is waiting for more feedback. -- Christopher
Re: [hackers] [dwm][patch] Stop input focus on pointers unselected monitor
On 23/08/17 09:22, Christopher Lang wrote: > Say you have two tiled monitors: M1 and M2. M1 and M2 each contain a > single client occupying their full area. M1 is selected, the pointer is > in M2. If a keybinding is pressed that moves M1's client to M2, then the > new monitor selected depends on where in M2 the pointer was! (if the > pointer is over the moved window after the move then the selection > changes otherwise selection remains on M1). > > I have been using dwm with multiple monitors for about a year now and > have not gotten used to this behaviour. In X, focus-follows-mouse is a tradition. Having that, it would be expected for active monitor to follow focus (= mouse pointer). signature.asc Description: PGP signature
Re: [hackers] [dwm][patch] Stop input focus on pointers unselected monitor
On Wed, Aug 16, 2023 at 07:30:05PM +0200, Hiltjo Posthuma wrote: > On Wed, Aug 16, 2023 at 06:06:40PM +0200, Storkman wrote: > > On Wed, Aug 16, 2023 at 10:07:16AM +0200, Hiltjo Posthuma wrote: > > > On Tue, Aug 15, 2023 at 10:43:32AM +0100, Christopher Lang wrote: > > > > When the pointer is on an unselected monitor and is not moving, it > > > > should not interfere what window is selected/focused. > > > > [...] > > > > If focusmon selects a monitor with no clients then XSetInputFocus is > > > > called on the root window. Due to the above rules, an FocusIn event is > > > > sent > > > > to the window under the pointer which may be on another monitor. Now a > > > > window on one monitor is getting our keyboard input but another monitor > > > > is selected. In this undesirable state, a killclient shortcut (for > > > > example) will not destroy the window that is accepting input. > > > > Perhaps more relevantly, if you select an empty monitor and press Mod+P, > > dmenu shows up on the monitor the pointer is on, but the program you start > > shows up on the selected monitor. > > I feel like this has been discussed before on the mailing list... > > > > Probably > > > > > > > > > We fix this by focusing on the bar window instead of root when an empty > > > > monitor is selected. Windows on other monitors are not a children of the > > > > bar window so they will not be focused by a NotifyPointer event. > > > > 2: > > > > > > > > If a window is moved from the selected monitor to the monitor under the > > > > pointer and the rearrangement of windows on the second monitor causes a > > > > different window to be under the pointer, then an enternotify event is > > > > sent for that window. This causes that window to be focused and the > > > > second monitor to be selected. If the arrangement on the second monitor > > > > did not cause the pointer to be under a different window then the > > > > selected monitor would not change (very unpredictable behaviour!). > > > > We fix this by suppressing all enternotify events at the end of an > > > > arrange(NULL) call. > > > > So currently, if you move a client to another monitor, focus stays on > > the same monitor, *unless* your mouse pointer just happens to be in the > > master area of the second monitor. I see no reason for this exception, > > so in that sense the patch is correct. Not just in the master area of the second monitor: after client has been moved and windows have been arranged. The focus stays on the same monitor unless the mouse pointer is over a different window than it was before due to the new arrangement of windows. If there were two windows on the second monitor before the move, then it is possible the pointer changes from being over one to another without it being over the master. > > Thanks for sharing, it sounds good. > > It's not always very clear what the correct or expected behaviour should be or > what all people prefer. Even though it may sound obvious to one person. I want > to be careful about changing such things, considering this behaviour has been > in dwm for many years. > > For example a while ago there was a patch for fullscreen behaviour: > https://git.suckless.org/dwm/commit/67d76bdc68102df976177de351f65329d8683064.html > https://git.suckless.org/dwm/commit/138b405f0c8aa24d8a040cc1a1cf6e3eb5a0ebc7.html > > Currently I'm not a heavy multi-monitor user either. > But I'm still curious about this change of course. > > > > > > > [...] > > > > > > Hi, > > > > > > Thanks for the patch. I'm not yet sure about it. > > > > > > If there are any other multi-monitor users, please test this and share > > > your > > > opinion of if the change makes sense to you. > > > > Seems to work okay so far (applied to master with a bunch of other patches > > on top). > > > > > > > > -- > > > Kind regards, > > > Hiltjo > > > > > > > -- > > Storkman > > > > -- > Kind regards, > Hiltjo > I will give an example to show just how unpredictable current behaviour is. Say you have two tiled monitors: M1 and M2. M1 and M2 each contain a single client occupying their full area. M1 is selected, the pointer is in M2. If a keybinding is pressed that moves M1's client to M2, then the new monitor selected depends on where in M2 the pointer was! (if the pointer is over the moved window after the move then the selection changes otherwise selection remains on M1). I have been using dwm with multiple monitors for about a year now and have not gotten used to this behaviour. -- Christopher
Re: [hackers] [dwm][patch] Stop input focus on pointers unselected monitor
On Wed, Aug 16, 2023 at 06:06:40PM +0200, Storkman wrote: > On Wed, Aug 16, 2023 at 10:07:16AM +0200, Hiltjo Posthuma wrote: > > On Tue, Aug 15, 2023 at 10:43:32AM +0100, Christopher Lang wrote: > > > When the pointer is on an unselected monitor and is not moving, it > > > should not interfere what window is selected/focused. > > > [...] > > > If focusmon selects a monitor with no clients then XSetInputFocus is > > > called on the root window. Due to the above rules, an FocusIn event is > > > sent > > > to the window under the pointer which may be on another monitor. Now a > > > window on one monitor is getting our keyboard input but another monitor > > > is selected. In this undesirable state, a killclient shortcut (for > > > example) will not destroy the window that is accepting input. > > Perhaps more relevantly, if you select an empty monitor and press Mod+P, > dmenu shows up on the monitor the pointer is on, but the program you start > shows up on the selected monitor. > I feel like this has been discussed before on the mailing list... > Probably > > > > > > We fix this by focusing on the bar window instead of root when an empty > > > monitor is selected. Windows on other monitors are not a children of the > > > bar window so they will not be focused by a NotifyPointer event. > > > 2: > > > > > > If a window is moved from the selected monitor to the monitor under the > > > pointer and the rearrangement of windows on the second monitor causes a > > > different window to be under the pointer, then an enternotify event is > > > sent for that window. This causes that window to be focused and the > > > second monitor to be selected. If the arrangement on the second monitor > > > did not cause the pointer to be under a different window then the > > > selected monitor would not change (very unpredictable behaviour!). > > > We fix this by suppressing all enternotify events at the end of an > > > arrange(NULL) call. > > So currently, if you move a client to another monitor, focus stays on > the same monitor, *unless* your mouse pointer just happens to be in the > master area of the second monitor. I see no reason for this exception, > so in that sense the patch is correct. Thanks for sharing, it sounds good. It's not always very clear what the correct or expected behaviour should be or what all people prefer. Even though it may sound obvious to one person. I want to be careful about changing such things, considering this behaviour has been in dwm for many years. For example a while ago there was a patch for fullscreen behaviour: https://git.suckless.org/dwm/commit/67d76bdc68102df976177de351f65329d8683064.html https://git.suckless.org/dwm/commit/138b405f0c8aa24d8a040cc1a1cf6e3eb5a0ebc7.html Currently I'm not a heavy multi-monitor user either. But I'm still curious about this change of course. > > > > [...] > > > > Hi, > > > > Thanks for the patch. I'm not yet sure about it. > > > > If there are any other multi-monitor users, please test this and share your > > opinion of if the change makes sense to you. > > Seems to work okay so far (applied to master with a bunch of other patches > on top). > > > > > -- > > Kind regards, > > Hiltjo > > > > -- > Storkman > -- Kind regards, Hiltjo
Re: [hackers] [dwm][patch] Stop input focus on pointers unselected monitor
On Wed, Aug 16, 2023 at 10:07:16AM +0200, Hiltjo Posthuma wrote: > On Tue, Aug 15, 2023 at 10:43:32AM +0100, Christopher Lang wrote: > > When the pointer is on an unselected monitor and is not moving, it > > should not interfere what window is selected/focused. > > [...] > > If focusmon selects a monitor with no clients then XSetInputFocus is > > called on the root window. Due to the above rules, an FocusIn event is sent > > to the window under the pointer which may be on another monitor. Now a > > window on one monitor is getting our keyboard input but another monitor > > is selected. In this undesirable state, a killclient shortcut (for > > example) will not destroy the window that is accepting input. Perhaps more relevantly, if you select an empty monitor and press Mod+P, dmenu shows up on the monitor the pointer is on, but the program you start shows up on the selected monitor. I feel like this has been discussed before on the mailing list... > > > > We fix this by focusing on the bar window instead of root when an empty > > monitor is selected. Windows on other monitors are not a children of the > > bar window so they will not be focused by a NotifyPointer event. > > 2: > > > > If a window is moved from the selected monitor to the monitor under the > > pointer and the rearrangement of windows on the second monitor causes a > > different window to be under the pointer, then an enternotify event is > > sent for that window. This causes that window to be focused and the > > second monitor to be selected. If the arrangement on the second monitor > > did not cause the pointer to be under a different window then the > > selected monitor would not change (very unpredictable behaviour!). > > We fix this by suppressing all enternotify events at the end of an > > arrange(NULL) call. So currently, if you move a client to another monitor, focus stays on the same monitor, *unless* your mouse pointer just happens to be in the master area of the second monitor. I see no reason for this exception, so in that sense the patch is correct. > > [...] > > Hi, > > Thanks for the patch. I'm not yet sure about it. > > If there are any other multi-monitor users, please test this and share your > opinion of if the change makes sense to you. Seems to work okay so far (applied to master with a bunch of other patches on top). > > -- > Kind regards, > Hiltjo > -- Storkman
Re: [hackers] [dwm][patch] Stop input focus on pointers unselected monitor
On Tue, Aug 15, 2023 at 10:43:32AM +0100, Christopher Lang wrote:
> When the pointer is on an unselected monitor and is not moving, it
> should not interfere what window is selected/focused.
>
> 1:
>
> From
> https://tronche.com/gui/x/xlib/events/input-focus/normal-and-grabbed.html:
> When the focus moves from window A to window B, A is an inferior of B,
> and the pointer is in window P, the X server does the following:
> It generates a FocusOut event on window A...
> It generates a FocusOut event on each win...
> It generates a FocusIn event on window B,...
> If window P is an inferior of window B but window P is not window A or
> an inferior or ancestor of window A, it generates a FocusIn event on
> each window below window B, down to and including window P, with the
> detail member of each XFocusInEvent structure set to NotifyPointer.
>
> If focusmon selects a monitor with no clients then XSetInputFocus is
> called on the root window. Due to the above rules, an FocusIn event is sent
> to the window under the pointer which may be on another monitor. Now a
> window on one monitor is getting our keyboard input but another monitor
> is selected. In this undesirable state, a killclient shortcut (for
> example) will not destroy the window that is accepting input.
>
> We fix this by focusing on the bar window instead of root when an empty
> monitor is selected. Windows on other monitors are not a children of the
> bar window so they will not be focused by a NotifyPointer event.
>
> 2:
>
> If a window is moved from the selected monitor to the monitor under the
> pointer and the rearrangement of windows on the second monitor causes a
> different window to be under the pointer, then an enternotify event is
> sent for that window. This causes that window to be focused and the
> second monitor to be selected. If the arrangement on the second monitor
> did not cause the pointer to be under a different window then the
> selected monitor would not change (very unpredictable behaviour!).
>
> We fix this by suppressing all enternotify events at the end of an
> arrange(NULL) call.
> ---
> dwm.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/dwm.c b/dwm.c
> index f1d86b2..5b71b33 100644
> --- a/dwm.c
> +++ b/dwm.c
> @@ -382,6 +382,7 @@ applysizehints(Client *c, int *x, int *y, int *w, int *h,
> int interact)
> void
> arrange(Monitor *m)
> {
> + XEvent ev;
> if (m)
> showhide(m->stack);
> else for (m = mons; m; m = m->next)
> @@ -389,8 +390,12 @@ arrange(Monitor *m)
> if (m) {
> arrangemon(m);
> restack(m);
> - } else for (m = mons; m; m = m->next)
> - arrangemon(m);
> + } else {
> + for (m = mons; m; m = m->next)
> + arrangemon(m);
> + XSync(dpy, False);
> + while (XCheckMaskEvent(dpy, EnterWindowMask, ));
> + }
> }
>
> void
> @@ -804,7 +809,7 @@ focus(Client *c)
> XSetWindowBorder(dpy, c->win,
> scheme[SchemeSel][ColBorder].pixel);
> setfocus(c);
> } else {
> - XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
> + XSetInputFocus(dpy, selmon->barwin, RevertToPointerRoot,
> CurrentTime);
> XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
> }
> selmon->sel = c;
> --
> 2.41.0
>
>
Hi,
Thanks for the patch. I'm not yet sure about it.
If there are any other multi-monitor users, please test this and share your
opinion of if the change makes sense to you.
--
Kind regards,
Hiltjo
Re: [hackers] help
Perhaps his kidnappers have forced him to write this email 樂. On Thu, Aug 3, 2023 at 3:20 PM Dr. André Desgualdo Pereira wrote: > > That's a huge relief! > > On 03/08/2023 12:29, Christopher Lang wrote: > > I was trying to subscribe to the mailing list but didn't get a response > > from so I tried this. I think I have figured it > > out not though. > > Sorry if I pinged you. And I'm fine haha. > > PS. I'm sorry if this is html mail, still trying to set up a better email > > client. > > > > On Thu, 3 Aug 2023 at 12:14, Dr. André Desgualdo Pereira > > wrote: > > > > > Can anyone track where Christopher is? Does anyone know a friend of him? > > > Maybe he was kidnapped or in risk of suicide. Maybe call local police? > > > > > > On 02/08/2023 23:10, Christopher Lang wrote: > > > > help > > > > > > > > > > > -- > Dr. André Desgualdo Pereira > Psiquiatra - CRM/SP: 120218 - RQE: 61032 > WhatsApp: (11) 985-847-809 - email: des...@gmail.com > Consultório Lapa: Rua Clélia, 2208 - sala 307 > Consultório Santana: Av. Gen. Ataliba Leonel, 93 - sala 61 >
Re: [hackers] help
That's a huge relief! On 03/08/2023 12:29, Christopher Lang wrote: > I was trying to subscribe to the mailing list but didn't get a response > from so I tried this. I think I have figured it > out not though. > Sorry if I pinged you. And I'm fine haha. > PS. I'm sorry if this is html mail, still trying to set up a better email > client. > > On Thu, 3 Aug 2023 at 12:14, Dr. André Desgualdo Pereira > wrote: > > > Can anyone track where Christopher is? Does anyone know a friend of him? > > Maybe he was kidnapped or in risk of suicide. Maybe call local police? > > > > On 02/08/2023 23:10, Christopher Lang wrote: > > > help > > > > > > -- Dr. André Desgualdo Pereira Psiquiatra - CRM/SP: 120218 - RQE: 61032 WhatsApp: (11) 985-847-809 - email: des...@gmail.com Consultório Lapa: Rua Clélia, 2208 - sala 307 Consultório Santana: Av. Gen. Ataliba Leonel, 93 - sala 61
Re: [hackers] help
On Thu, 3 Aug 2023 12:29:04 +0100 Christopher Lang wrote: Dear Christopher, > I was trying to subscribe to the mailing list but didn't get a > response from so I tried this. I think I > have figured it out not though. > Sorry if I pinged you. And I'm fine haha. > PS. I'm sorry if this is html mail, still trying to set up a better > email client. how can we be sure it's you and not your kidnapper? HANG IN THERE, CHRISTOPHER, IF YOU CAN HEAR THIS! With best regards Laslo
Re: [hackers] help
I was trying to subscribe to the mailing list but didn't get a response from so I tried this. I think I have figured it out not though. Sorry if I pinged you. And I'm fine haha. PS. I'm sorry if this is html mail, still trying to set up a better email client. On Thu, 3 Aug 2023 at 12:14, Dr. André Desgualdo Pereira wrote: > Can anyone track where Christopher is? Does anyone know a friend of him? > Maybe he was kidnapped or in risk of suicide. Maybe call local police? > > On 02/08/2023 23:10, Christopher Lang wrote: > > help > > >
Re: [hackers] help
Can anyone track where Christopher is? Does anyone know a friend of him? Maybe he was kidnapped or in risk of suicide. Maybe call local police? On 02/08/2023 23:10, Christopher Lang wrote: > help
Re: [hackers] [dwm][patch] ISO 8859-1-only window name bugfix
On 23/07/12 10:28PM, Hiltjo Posthuma wrote:
> Unless I'm missing something. It seems like an application or environment
> issue.
>
> For dwm it is assumed the environment is utf-8 and application should use it.
Sorry, I forgot to list my locale-related variables. They are set up as such:
LANG=sr_RS.UTF-8
LC_ALL=
LC_CTYPE=
LC_NUMERIC=
LC_TIME=
LC_COLLATE=
LC_MONETARY=
LC_MESSAGES=
and I still experience the behavior from this issue. I use Alpine Linux, so
it's also not related to libc or distro.
> I think it makes sense if the application uses utf-8 or the same encoding as
> the environment. It shouldn't pick some encoding an expect the window manager
> to autodetect and handle all of them.
If I understand the process correctly, there are currently two cases,
differentiated by the encoding field. If it's set to XA_STRING, no conversion
is made, otherwise it is passed to XmbTextPropertyToTextList which does the
conversion from locale ("Multi Byte") to UTF-8. From what I've observed, the
encoding field cannot be used to make this distinction. This is a table of
cases I've encountered ("Passed to Xmb...?" means the value being passed to
XmbTextPropertyToTextList under the current upstream, unaltered dwm):
Actual Encoding encoding field Source Passed to Xmb...?
---
1. ISO 8859-1 31 (=XA_STRING) LibreOffice No
2. (COMPOUND_TEXT?) 385 LibreOffice Yes
3. UTF-831 (=XA_STRING) slstatusNo
Now that I look at it again, I am not sure what is the actual encoding in case
#2. When I use od(1) to take a look at the bytes in the value field, I get
this for "thisátestњ.odt - LibreOffice Writer":
$ od -t c value.log
000 t h i s 341 t e s t 033 - L 372 . o d
020 t - L i b r e O f f i c e
040 W r i t e r \n
047
Octal 341 (=225=0xE1) for "á" is ISO 8859-1, but the sequence "033 - L 372"
for "њ" is... COMPOUND_TEXT[1]? Ah--now I see[2]:
> For supported locales, existence of a converter from COMPOUND_TEXT, STRING,
^
> UTF8_STRING or the encoding of the current locale is guaranteed if
^^^
> XSupportsLocale returns True for the current locale (but the actual text may
> contain unconvertible characters).
So I guess that explains case #2 then. Still, I think case #1 should be handled
somehow. I'm not sure whether LibreOffice or X.Org should be blamed for setting
WM_NAME to unconverted ISO 8859-1 bytes. As stated, contents of my LANG ends in
.UTF-8, so "current locale" should not be ISO 8859-1, unless hardcoded.
[1]: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/CTEXT/ctext.html
[2]: https://linux.die.net/man/3/xmbtextpropertytotextlist
signature.asc
Description: PGP signature
Re: [hackers] [dwm][patch] ISO 8859-1-only window name bugfix
On Wed, Jul 12, 2023 at 06:48:45PM +0200, Страхиња Радић wrote:
> Hi, recently André Desgualdo Pereira reported a bug in dwm when window names
> consist only of characters in ISO 8859-1. In short, windows with such names
> had their names broken at the place of ISO 8859-1-specific characters which
> are
> not in ASCII, for example áâãéíóôúç. When the window name has other Unicode
> characters, for example Cyrillic characters etc., the window name is shown
> correctly, because it is encoded in UTF-8 and its WM_NAME's type as reported
> by
> xprop is COMPOUND_TEXT (encoding field is set to 385). In the other case, it
> is
> set to STRING and encoding field is set to 31.
>
> I have determined that the window name is encoded in ISO 8859-1 and passed to
> drw_text in drw.c as-is, when that function assumes the argument is encoded
> in
> UTF-8. Commenting out the first part of the relevant if-test results in such
> titles being shown correctly due to conversion by
> XmbTextPropertyToTextList.
>
> However, doing so results in other strings passed to gettextprop, which are
> encoded in UTF-8 but with encoding field set to 31 (XA_STRING), to also be
> passed to that function and converted according to current locale, resulting
> in
> garbage being output instead of the intended text. This happens for root
> window
> name set by slstatus, for example.
>
> In this patch, I have commented out the existing first if-branch in
> gettextprop, and introduced another which tests if the window is a root
> window.
> This is probably not ideal, but the alternative would be some form of UTF-8
> autodetection, the passed data being mislabeled as it is.
> From c5b399e138f6873e2eb9a292d55c5382e654f074 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
> =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?=
> Date: Mon, 10 Jul 2023 09:25:30 +0200
> Subject: [PATCH] dwm.c: Always convert title to UTF-8, except for root window
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Window names containing only ISO 8859-1 were broken on the location of
> non-ASCII ISO 8859-1 character, for example áâãéíóôúç, because they were
> treated as UTF-8. When commenting out the if-branch testing for XA_STRING,
> root
> window title, usually set by status programs such as slstatus to UTF-8 text,
> was not shown correctly, so this patch adds an exception for root window
> instead, skipping conversion in that case.
>
> Reported by Dr. André Desgualdo Pereira.
>
> Signed-off-by: Страхиња Радић
> ---
> dwm.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/dwm.c b/dwm.c
> index f1d86b2..c896325 100644
> --- a/dwm.c
> +++ b/dwm.c
> @@ -917,7 +917,10 @@ gettextprop(Window w, Atom atom, char *text, unsigned
> int size)
> text[0] = '\0';
> if (!XGetTextProperty(dpy, w, , atom) || !name.nitems)
> return 0;
> - if (name.encoding == XA_STRING) {
> + /*if (name.encoding == XA_STRING) {
> + strncpy(text, (char *)name.value, size - 1);
> + } else */
> + if (w == DefaultRootWindow(dpy)) {
> strncpy(text, (char *)name.value, size - 1);
> } else if (XmbTextPropertyToTextList(dpy, , , ) >= Success
> && n > 0 && *list) {
> strncpy(text, *list, size - 1);
> --
> 2.38.5
>
Hi,
Unless I'm missing something. It seems like an application or environment
issue.
For dwm it is assumed the environment is utf-8 and application should use it.
I think it makes sense if the application uses utf-8 or the same encoding as
the environment. It shouldn't pick some encoding an expect the window manager
to autodetect and handle all of them.
--
Kind regards,
Hiltjo
Re: [hackers] [dmenu][PATCH] minor improvement to the nomatches cache
Hi Hiltjo,
On Thu, Jul 06, 2023 at 07:08:57PM +0200, Hiltjo Posthuma wrote:
> What hash algorithm is this exactly, it looks interesting? I've found it at:
>
> https://github.com/skeeto/hash-prospector
>
> Is that the one?
The "xor-shift multiply" construct itself is fairly popular and can be
found on many hash algorithms (e.g murmur, fnv etc). I *think* it
originates from LGCs, but not sure about that:
https://en.wikipedia.org/wiki/Linear_congruential_generator
The specific multiplier and shift constants are indeed taken from
hash-prospector README, I've updated v2 commit message to include it.
> What's the measured performance improvement and wouldn't it increase
> collisions
> vs a simple linear search?
In case the cache gets filled up, the false-negative rate of either a
linear search or the hash-table will be unpredictable since both of them
use a "dumb" eviction policy.
The old method overwrites whatever came in first and the new one
overwrites whatever was in `h1`. Something like an LRU *might* help in
those cases, but I think it's not worth the trouble.
As for collisions, the new 2x size made collisions rarer. Testing with a
list of ~1.6k emojies I saw only 5 collisions. (The result will
obviously vary depending on your installed fonts).
But this made me realize that it was dumb to throw away the high bits of
the hash. It can be used to probe another slot. With that, I now only
get 1 collision. I've updated the v2 patch with the new logic.
> I'm not sure we should change the assumption for ints to POSIX in dmenu in all
> cases and assume 32-bit int (although a lot of software in practise does).
> But
> this is very pedantic :)
>
> Bit off-topic: recently I tested some software on MS-DOS with the OpenWatcom
> compiler. It had 16-bit int and caught a bug in my code (lower-level parser
> stuff).
Since dmenu already requires POSIX, I didn't think it'd be a problem.
`uint_least32_t` or `uint32_t` can probably be used, but suckless code
base typically seems to avoid .
---
Avoiding wastage and thus being able to 2x the cache size is the *main*
improvement here, IMO.
The hash-table is measurably faster than linear search but it won't be
noticeable by the user (~30ns vs ~130ns, in theory it also avoids
polluting the cache but I doubt that'll matter much either) so I don't
mind dropping the hash-table if there's concerns about it.
But I think avoiding waste and 2x cache size is worthwhile since it
means we can avoid even more unnecessary and expensive XftFontMatch()
calls.
- NRK
>From 7359c32b9612f8b5fe8c4e6ebf2ab1d903eda989 Mon Sep 17 00:00:00 2001
From: NRK
Date: Fri, 9 Jun 2023 21:11:52 +0600
Subject: [PATCH] minor improvement to the nomatches cache
1. use `unsigned int` to store the codepoints, this avoids waste on
common case where `long` is 64bits. and POSIX guarantees `int` to be
at least 32bits so there's no risk of truncation.
2. since switching to `unsigned int` cuts down the memory requirement by
half, double the cache size from 64 to 128.
3. instead of a linear search, use a simple hash-table for O(1) lookups.
to reduce collusions, the both the lower and the higher bits of the
hash are used to probe 2 different slots.
the hash constants are taken form:
https://github.com/skeeto/hash-prospector
---
dmenu.c | 1 -
drw.c | 23 ---
util.h | 1 +
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/dmenu.c b/dmenu.c
index 62f1089..40f93e0 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -22,7 +22,6 @@
/* macros */
#define INTERSECT(x,y,w,h,r) (MAX(0, MIN((x)+(w),(r).x_org+(r).width) -
MAX((x),(r).x_org)) \
* MAX(0, MIN((y)+(h),(r).y_org+(r).height) -
MAX((y),(r).y_org)))
-#define LENGTH(X) (sizeof X / sizeof X[0])
#define TEXTW(X) (drw_fontset_getwidth(drw, (X)) + lrpad)
/* enums */
diff --git a/drw.c b/drw.c
index a58a2b4..78a2b27 100644
--- a/drw.c
+++ b/drw.c
@@ -238,8 +238,8 @@ drw_rect(Drw *drw, int x, int y, unsigned int w, unsigned
int h, int filled, int
int
drw_text(Drw *drw, int x, int y, unsigned int w, unsigned int h, unsigned int
lpad, const char *text, int invert)
{
- int i, ty, ellipsis_x = 0;
- unsigned int tmpw, ew, ellipsis_w = 0, ellipsis_len;
+ int ty, ellipsis_x = 0;
+ unsigned int tmpw, ew, ellipsis_w = 0, ellipsis_len, hash, h0, h1;
XftDraw *d = NULL;
Fnt *usedfont, *curfont, *nextfont;
int utf8strlen, utf8charlen, render = x || y || w || h;
@@ -251,9 +251,7 @@ drw_text(Drw *drw, int x, int y, unsigned int w, unsigned
int h, unsigned int lp
XftResult result;
int charexists = 0, overflow = 0;
/* keep track of a couple codepoints for which we have no match. */
- enum { nomatches_len = 64 };
- static struct { long codepoint[nomatches_len]; unsigned int idx; }
nomatches;
- static unsigned int ellipsis_width = 0;
+ static unsigned int nomatches[128],
