Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau

2024-03-29 Thread Storkman
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

2024-03-27 Thread Storkman
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] [dwm][patch] Stop input focus on pointers unselected monitor

2023-08-16 Thread Storkman
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] A better mailing list web archiver for suckless.org ... ?

2022-08-11 Thread Storkman
On Wed, Aug 10, 2022 at 09:29:43PM +0200, Thomas Oltmann wrote:
> Hi all!
> 
> I think we can all agree that the current web archive over at
> lists.suckless.org isn't all that great;
> Author names get mangled, the navigation is terrible, some messages
> are duplicated, some missing.
> 
> That's why I've started looking into #3 of the 'Project Ideas' page
> (https://suckless.org/project_ideas/) -- "Write a decent mailing list
> Web archive system".
> I see lots of potential to build something better than hypermail:
> 
> - We could take text encodings more seriously.
>   hypermail just copies the 'charset' notice over into the HTML
>   file, which doesn't work when listing multiple messages.
> 
> - We could use maildir instead of the really brittle mbox format for 
> mailboxes.
>   This might also help avoid message dropping/duplication, but I'm not
> sure about that.
> 
> - We could try a different navigation scheme. Perhaps flat threads
> instead of a hierarchy?
>   I don't really know how people here feel about this, but it's
> mentioned on the 'Project Ideas' page
>   and I'm in favour of it. Navigating message trees is really confusing.
> 
> - Bonus: We can ignore CGI, uuencode, HTML mail and all that cruft.
> 
> Is there currently any interest in such a project here?
> 
> So far, I've gone ahead and implemented a sort of proof-of-concept (at
> https://www.github.com/tomolt/mailarchiver).
> Of course I can't guarantee that this will go anywhere, as I only have
> limited time and patience myself, but I can give it a try.
> 
> Cheers,
>   Thomas Oltmann
> 

Hi!

When you list all these features, it sounds like everything a mailing list
archive front-end does just replicates things our mail clients already
do better, and without going through a web browser.

So I thought, why not just serve the maildir files as-is, with monthly
and yearly tarballs, and perhaps metadata files so you don't need to
download everything just to make sure you've got an entire thread?
But then, that would require additional instrumentation and would make e.g.
referencing mailing list threads in commit messages slightly less convenient.

In any case, I messed with the code a bit, running it on my own archive
maildir. I've constructed a very crude threaded view[1], and came up with a
few fixes in the process.

Patch 2 is a rewrite of collapse_ws(), because I found it really hard to
figure out what exactly it does and how. Your mileage may vary, but I
think the original code would overflow the buffer backwards when given
an empty input.

For patch 3, I've found some e-mails in the wild that used a lowercase
encoding in encoded-words, and the RFC says it's okay.

Patch 4 might not be correct, because I'm not sure how decode_qprintable()
can ever return without error when parsing an encoded-word in a header.
It seems that it would just find the last "=" in "?=", set length to -2,
and return NULL. Maybe I'm just not getting it. It did manage to process
a few dozen more e-mails in my test runs, though.

Hopefully I did this correctly and you can cherry-pick these commits
to your taste.

-- Storkman

  [1]: https://imgur.com/a/EbOblHt
>From 0627261f197a1bdacdca24d36fb0aee9e5d2c11b Mon Sep 17 00:00:00 2001
From: Paul Storkman 
Date: Thu, 11 Aug 2022 22:32:37 +0200
Subject: [PATCH 1/4] Rearrange process_field to reduce repetition.

---
 mailarchiver.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/mailarchiver.c b/mailarchiver.c
index 4e52d78..5b9001e 100644
--- a/mailarchiver.c
+++ b/mailarchiver.c
@@ -350,19 +350,7 @@ process_field(char *key, char *value)
 {
struct token token;
 
-   if (!strcasecmp(key, "From")) {
-   collapse_ws(value);
-   if (!decode_encwords(value)) return false;
-   mail.from = value;
-   } else if (!strcasecmp(key, "Subject")) {
-   collapse_ws(value);
-   if (!decode_encwords(value)) return false;
-   mail.subject = value;
-   } else if (!strcasecmp(key, "Date")) {
-   collapse_ws(value);
-   if (!decode_encwords(value)) return false;
-   mail.date = value;
-   } else if (!strcasecmp(key, "Content-Transfer-Encoding")) {
+   if (!strcasecmp(key, "Content-Transfer-Encoding")) {
token = TOKEN_INIT(value);
if (tokenize() != TOKEN_ATOM) return false;
if (!strcasecmp(token.atom, "7bit")) {
@@ -378,6 +366,17 @@ process_field(char *key, char *value)
} else {
return false;
}
+   return true;
+   }
+
+   collapse_ws(value);
+   if (!decode_encwords(value)) return false;
+   if (!strcasecmp(k