On Sun, Feb 23, 2025 at 05:28:46AM +0000, ~skejg wrote:

When a menu doesn't fit into the screen, it puts : at the end to note that it can be scrolled: https://0x0.st/8TO1.png

However, if the parent terminal is resized, and the menu is called again, it won't get updated, and will have the same : to note that it still doesn't fit the screen: https://0x0.st/8TOe.png

I reuploaded the pictures to avoid the pictures to be deleted before the ticket is resolved:

http://rkta.de/pub/todo-73-menu-new.png http://rkta.de/pub/todo-73-menu-not-fit.png http://rkta.de/pub/todo-73-menu-resized.png

Interestingly, it seems that if some option is set after that via :SET_OPTION command, then the menu size actually does get updated.

Important: this is not the same menu, which just doesn't get redrawn after the terminal changes (and which is probably expected): https://0x0.st/8TO_.png -- but a whole new menu called after the parent terminal resize.

SET_OPTION/setOpt calls sync_with_option which calls initMenu which probably does something. :) You can achieve the same with REINIT.

I will have to check why w3m doesn't act accordingly on the SIGWINCH here. Thanks for the report.

(On a side note, it could be handy if we could "cycle" the menu: to go to the last entry when we press 'Up' at the first entry, and vice versa :)

When a menu doesn't fit into the screen, it puts : at the end to note that it can be scrolled: https://0x0.st/8TO1.png

However, if the parent terminal is resized, and the menu is called again, it won't get updated, and will have the same : to note that it still doesn't fit the screen: https://0x0.st/8TOe.png

Interestingly, it seems that if some option is set after that via :SET_OPTION command, then the menu size actually does get updated.

Important: this is not the same menu, which just doesn't get redrawn after the terminal changes (and which is probably expected): https://0x0.st/8TO_.png -- but a whole new menu called after the parent terminal resize.

It would be nice if w3m could ignore 1x1 images.

Those are mostly used for tracking purposes, and it could prove really handy to block those if images in general are enabled (display_image option set to 1), or not to pollute the layout with their placeholders if images are disabled (display_image=0).

Maybe a separate option could be introduced, something like display_image_1x1=0.

Checked with ghostty v1.0.1, too (aerc v0.19.0):

• ghostty -> aerc: shows sixel, however, the image can't be cleared with <C-l> or clear. With respect to emails, this means that displayed sixel images stay on top, accumulate and leave artifacts when scrolling. This is how it looks: https://qu.ax/EvrYF.png

• ghostty -> tmux -> aerc: does not show sixel (shows SIXEL IMAGE (38x15)+++...)

Was playing with aerc and sixel a bit (Ubuntu 22.04, aerc commit 6b97085a, vaxis 0.11.0, tmux next-3.6 with the default configuration), and noticed that this happens:

• temrinal with sixel support: shows sixel
• temrinal with sixel support -> tmux: shows sixel
• temrinal with sixel support -> aerc: shows sixel
• temrinal with sixel support -> tmux -> aerc: does not show sixel
• temrinal with sixel support -> aerc -> tmux: does not show sixel (shows SIXEL IMAGE (38x15)+++...)

I tested it with this https://github.com/csdvrx/sixel-testsuite/blob/master/snake.six image in aerc's :terminal (so I was able to launch tmux inside aerc, too, the last case :)

Terminals in question were alactritty (via https://github.com/alacritty/alacritty/pull/4763 ), xterm 372 (default for Ubuntu 22.04), xterm 397 and mlterm 3.9.3. The last two, however, provided a bit different results:

• temrinal with sixel support: shows sixel
• temrinal with sixel support -> tmux: shows sixel
• temrinal with sixel support -> aerc: shows sixel, however, the image can't be cleared with <C-l> or clear, and if a TUI program is launched afterwards, sixel image stays on top of it (https://qu.ax/JPuYG.png )
• temrinal with sixel support -> tmux -> aerc: doesn't support true colors, shows sixel with artifacts (https://qu.ax/OoCkE.png ), the image can't be cleared [...]
• temrinal with sixel support -> aerc -> tmux: does not show sixel (shows SIXEL IMAGE (38x15)+++...)

Honestly don't know who's to blame here but since something gets off inside vaxis, thought maybe I'd simply share these results with you :)

It seems, one can't have a mapping, which would end with a minus sign ('-'). A single minus sign works just fine, though.

To overcome that, a user needs to add one more minus to the mapping. E.g., to map the two key sequence a-, one should create a mapping for a-- instead.

For example, despite two minuses in a mapping below, bookmarks will be opened immediately on the first key press:

keymap -- BOOKMARK

However, if we put 3 minuses in the very same mapping, like this:

keymap --- BOOKMARK

...bookmarks will only be shown after two consecutive minuses.

Probably, w3m treats one of these minuses as a junction between keys (as it would be used in something like C-a), and therefore doesn't add it to an actual mapping. Some sort of a guard could probably solve that :)

Commit 5b51ce35.

the only solution is to disable seccomp

And it worked, thanks again! :)

~skejg wrote:

Could you please post the output of cha -Vd?

Ah, sorry, didn't think about that, here you go:

STDERR: Sandbox violation in buffer: syscall #102 Error in buffer about:chawan fatal.nim(53) sysFatal Error: unhandled exception: pager.nim(3198, 7) pager.consoleWrapper.container != nil [AssertionDefect]

And if trying to open an actual URL, then there's also STDERR: Sandbox violation in network: syscall #102.

-- View on the web: https://todo.sr.ht/~bptato/chawan/37#event-401699

102 is socketcall(2):

On x86-32, socketcall() was historically the only entry point for the sockets API. However, starting in Linux 4.3, direct system calls are provided on x86-32 for the sockets API. This facilitates the creation of seccomp(2) filters that filter sockets system calls.

socketcall makes it impossible to filter for UNIX sockets in a way that doesn't also let through arbitrary TCP/IP connections. It seems, with such an old libc/kernel, the only solution is to disable seccomp: [...] make DANGER_DISABLE_SANDBOX=1.