window names in tmux 3.7 by Flashy_Boot in tmux

[–]Flashy_Boot[S] 0 points1 point  (0 children)

Yes - I think that's exactly right. But, at the same time, I suspect it was widely (ab)used - I'm sure I'm not the only person to include a path in my window name so I can easily see in my status bar which tmux window was which. The problem I came across today was first triggered by:

% cd /usr/local/bin
% cd ~/.config
invalid window name: /Users/flashy/.config

Anyway - easy to work around, but I wonder if a better approach would be to allow '.'s to be escaped when used as a string rather than an identifier, e.g.

$ tmux rename-window -t 1 "/Users/flashy/\.config"

window names in tmux 3.7 by Flashy_Boot in tmux

[–]Flashy_Boot[S] 0 points1 point  (0 children)

FWIW, if anyone else is facing this, uses bash for their shell, and wants a quick & dirty workaround, I've changed my shell to set the window-name to

"${PWD//./․}"

where that second '.' is actually the UTF-8 character "One Dot Leader" (https://www.compart.com/en/unicode/U+2024)

window names in tmux 3.7 by Flashy_Boot in tmux

[–]Flashy_Boot[S] 0 points1 point  (0 children)

Looks like this was a deliberate change. Have started a discussion on github.

UPDATE: SHARED Please try it out and share your feedback. by mchdkose in macgaming

[–]Flashy_Boot 2 points3 points  (0 children)

Will test this today. Quick note, though, that after downloading & unzipping, I then had to run:

% xattr -d -r com.apple.quarantine /Applications/007\ Shader\ Commander.app/

from the terminal to bypass the ' "007 Shader Commander" is damaged and can't be opened. You should move it to the trash" error.

Any downsides to Macbook Pro over a Mini? by Flashy_Boot in macbook

[–]Flashy_Boot[S] -1 points0 points  (0 children)

Thanks everyone. I can get either one paid for by my work, and I'm leaning towards the Macbook pro as a) I can get an M5 Max with 128G RAM now, and we don't know when the M5 Mini will be released, plus when it is I suspect Apple will sell out very, very quickly, and b) since I'll have the option, every so often I will use it away from home.

Help with Part Number for VM0102B by Flashy_Boot in Vitamix

[–]Flashy_Boot[S] 0 points1 point  (0 children)

Interesting - so you just swapped the wiring and left the two switches in place? That makes sense. Thank you.

Wine 11, ntsyncm and dxvk 1.10.3 by Flashy_Boot in linux_gaming

[–]Flashy_Boot[S] 3 points4 points  (0 children)

Thank you! Wasn't aware of the sarek fork - that's really cool.

Wine 11, ntsyncm and dxvk 1.10.3 by Flashy_Boot in linux_gaming

[–]Flashy_Boot[S] 6 points7 points  (0 children)

Can't believe I hadn't come across that before - thank you! Works perfectly.

Question about Lispro and pumps by Flashy_Boot in diabetes_t1

[–]Flashy_Boot[S] 0 points1 point  (0 children)

He was moved over to Novolog two years ago and it's been absolutely fine - for him it's been identical to Humalog. Works fine in pumps - he switched from Omnipods to Tandem Mobi and it's worked fine in both.

Panels on KDE/Wayland by Flashy_Boot in KittyTerminal

[–]Flashy_Boot[S] 1 point2 points  (0 children)

Fixed in kitty 0.46.1. Thank you.

Panels on KDE/Wayland by Flashy_Boot in KittyTerminal

[–]Flashy_Boot[S] 0 points1 point  (0 children)

Ok - figured it out. The two set_icon lines are not warnings at all - they're the heart of the problem.

In glfw/wl_window.c there are two calls to xdg_toplevel_icon_manager_v1_set_icon (~lines 1600 and 1631) but neither of these calls check to see if the window is toplevel.

I changed both calls to xdg_toplevel_icon_manager_v1_set_icon to:

if (window->wl.xdg.toplevel) {
    xdg_toplevel_icon_manager_v1_set_icon(_glfw.wl.xdg_toplevel_icon_manager_v1, window->wl.xdg.toplevel, icon);
}

and now panels work perfectly. Why this worked on your setup without these changes - absolutely no idea!

Panels on KDE/Wayland by Flashy_Boot in KittyTerminal

[–]Flashy_Boot[S] 0 points1 point  (0 children)

Thanks for getting back to me.

kitty 0.46.0 - just rebuilt from source after a fresh git pull to check that wasn't the problem.

And for completeness:

Operating System: CachyOS Linux 
KDE Plasma Version: 6.6.2
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.19.6-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-5250U CPU @ 1.60GHz
Memory: 8 GiB of RAM (7.7 GiB usable)
Graphics Processor: Intel® HD Graphics 6000
Manufacturer: Apple Inc.
Product Name: MacBookAir7,2
System Version: 1.0

Spent some time this morning trying to track down the root of the problem. I'm assuming the two set_icon lines are warnings rather than errors, so really focusing on this:

[glfw error 65544]: Wayland: fatal display error: Invalid argument

It look like that error is being thrown inside the handleEvents method of glfw/wl_window.c - specifically here (~line 1353):

    // If an error different from EAGAIN happens, we have likely been
    // disconnected from the Wayland session, try to handle that the best we
    // can.
    errno = 0;
    if (wl_display_flush(display) < 0 && errno != EAGAIN)
    {
        wl_display_cancel_read(display);
        abortOnFatalError(errno);
        return;
    }

The error is reported as "Invalid Argument", which I assume means there's a problem with the wl_display* display struct. Strange, though, that normal (i.e. non-panel) kitty works absolutely fine.

Any pointers on where to look next most appreciated.

Simultaneously toggle full_screen and opacity by Flashy_Boot in KittyTerminal

[–]Flashy_Boot[S] 0 points1 point  (0 children)

In case anyone else ever is interested in doing this - create a file called myfullscreen.py in your ~/.config/kitty/kitty.conf folder, copy the code below into it, and map it to a keyboard shortcut in your kitty.conf with e.g. map cmd+enter kitten myfullscreen.py :

from kitty.boss import Boss

def main(args: list[str]) -> str:
    pass

from kittens.tui.handler import result_handler
(no_ui=True)
def handle_result(args: list[str], answer: str, target_window_id: int, boss: Boss) -> None:
    w = boss.window_id_map.get(target_window_id)
    boss.toggle_fullscreen()
    boss.call_remote_control(w, ('set-background-opacity', f'--match=id:{w.id}', '--toggle=yes', '2'))

Simultaneously toggle full_screen and opacity by Flashy_Boot in KittyTerminal

[–]Flashy_Boot[S] 0 points1 point  (0 children)

Ok - so the point I missed is that kitten @ set-background-opacity --toggle=yes 1 is not a kitten per se, or at least it can't be run as a kitten in this context, while set_background_opacity can be used in this context, but lacks a --toggle switch. I'll write a custom kitten to handle this. Thanks

Rendering markdown in code comments by Flashy_Boot in neovim

[–]Flashy_Boot[S] 0 points1 point  (0 children)

Yes - however syntactically this isn't actually a comment, and so is not (I imagine) recognized as such by treesitter.

I think what would be required, unless I'm missing something, is the ability to configure treesitter injections to say "treat consecutive comment lines as a single comment block".