2026/03/12

Newest at the top

2026-03-12 03:15:08 +0100 <haskellbridge> Is there something wrong with my laptop and/or my Linux settings?
2026-03-12 03:15:05 +0100 <haskellbridge> <i​qubic (she/her)> So, for some reason, my laptop's built-in keyboard has stopped doing key-repeat. No matter how much I hold down a key, Linux only ever registers it a single time.
2026-03-12 00:21:47 +0100stackdroid18(~stackdroi@user/stackdroid) ()
2026-03-11 21:45:54 +0100scardinal(~supreme@0x573d64a9.static.cust.fastspeed.dk) (Quit: leaving)
2026-03-11 21:42:14 +0100 <geekosaur> resizing it manually afterward eorked fine, but next time you started your X session it would do it again
2026-03-11 21:41:48 +0100 <geekosaur> this had the amusing result that, back in the days when it had a frame size bug, it would get into a fight with kdewm that led to its initial window size visibly stepping down to about 3x2
2026-03-11 21:40:06 +0100 <geekosaur> emacs has a certain tendency to assume that the window manager (or for that matter anything else) should be subordinate to it
2026-03-11 21:39:06 +0100 <geekosaur> or reconfigure it with emacs commands instead of the mouse
2026-03-11 21:38:42 +0100 <geekosaur> I don't have an emacs confoiguration that saves frame information; if you do, you might need to turn it off or manually edit the save
2026-03-11 21:25:20 +0100 <geekosaur> those together (especially the second) sound like it's emacs doing it and the most you can accomplish from xmonad is starting a war with it (that is, you get a resize loop)
2026-03-11 20:31:06 +0100stackdroid18(~stackdroi@user/stackdroid) stackdroid
2026-03-11 20:04:19 +0100ectospasm(~ectospasm@user/ectospasm) ectospasm
2026-03-11 19:54:51 +0100Enrico63(~Enrico63@host-82-61-84-117.retail.telecomitalia.it) (Quit: Client closed)
2026-03-11 19:37:37 +0100ectospasm(~ectospasm@user/ectospasm) (Quit: WeeChat 4.8.1)
2026-03-11 18:53:13 +0100 <haskellbridge> <e​ldritchcookie> it also doesn't allow me to manually fix the window with the mouse.
2026-03-11 18:52:12 +0100 <haskellbridge> <e​ldritchcookie> i thought it was something i did wrong but i tested with another application and it works fine, when i use doFullFloat on emacs it covers more than the whole window vertically on the bottom and misses a little horizontally on the right. Are there workarounds for correctly floating emacs?
2026-03-11 17:52:32 +0100 <liskin> Even if, it'd look different than what X does
2026-03-11 17:52:17 +0100 <liskin> Yeah but maybe use the brain a bit? We're not trying to make a generic WM interface...
2026-03-11 17:50:26 +0100 <geekosaur> there was even a proposal to directly support it that got shot down for "security reasons"
2026-03-11 17:49:57 +0100 <geekosaur> the reason people miss it is wayland docs and devs tell you that's insecure and you shouldn't do it
2026-03-11 17:37:08 +0100 <liskin> I mean actually maybe that's good. Make me angrier and I might just sit down and fucking do this at last.
2026-03-11 17:36:24 +0100 <liskin> Sorry for the caps but how does everyone keep missing this bit? Makes me furious.
2026-03-11 17:36:04 +0100 <liskin> You REALLY FUCKING DON'T WANT TO HAVE TO RESTART YOUR WHOLE COMPOSITOR
2026-03-11 17:35:29 +0100 <liskin> Xmonad is configured by compiling - reload of configuration means restart.
2026-03-11 17:34:59 +0100 <liskin> (the most I managed was just under 2 years - that's completely unrealistic in the Wayland world)
2026-03-11 17:34:30 +0100 <liskin> In X11 you can restart xmonad a million times while still letting the X server run for months or even years
2026-03-11 17:34:00 +0100 <liskin> Also there's this big fundamental limitation of Wayland design - if the compositor crashes or needs to restart, your whole session goes down
2026-03-11 17:33:05 +0100 <liskin> Even Rust folks struggled to get wlroots bindings to feel good, that's why smithay is thriving these days. It's just better to do a Rust native Wayland library
2026-03-11 17:32:23 +0100 <liskin> And also it's much harder to write/maintain bindings to C APIs
2026-03-11 17:31:59 +0100 <liskin> Haskell is garbage collected - so that means latency might suffer unpredictably
2026-03-11 17:31:01 +0100 <liskin> 2 years ago that would mean being limited and being behind the protocols supported by gnome/kde/wlroots, but I think these days smithay is fine
2026-03-11 17:30:35 +0100 <haskellbridge> <E​nrico Maria De Angelis> What's fundamentally flawed with doing it in Haskell (out of curiosity, and with zero prerequisites to understand the answer, probably).
2026-03-11 17:30:21 +0100 <liskin> Smithay (the Rust alternative to wlroots) being in a good shape these days means doing it in Rust should be fine
2026-03-11 17:29:41 +0100 <liskin> I've been saying for years - let's just do that in Rust or C, and let it rpc to a Haskell window manager.
2026-03-11 17:29:05 +0100 <liskin> I still don't know why anyone's trying to have the compositor itself be written in Haskell.
2026-03-11 17:15:26 +0100vados(~vados@46-133-57-88.mobile.vf-ua.net)
2026-03-11 17:01:59 +0100Enrico63(~Enrico63@host-82-61-84-117.retail.telecomitalia.it) Enrico63
2026-03-11 16:02:44 +0100deepy(deepy@user/deepy) deepy
2026-03-11 16:02:17 +0100deepy(deepy@user/deepy) (Read error: Connection reset by peer)
2026-03-11 13:29:32 +0100DigitteknohippieDigit
2026-03-11 12:59:25 +0100Digitteknohippie(~user@user/digit) Digit
2026-03-11 12:35:48 +0100Digitteknohippie(~user@user/digit) (Ping timeout: 246 seconds)
2026-03-11 12:24:00 +0100ChubaDuba(~ChubaDuba@46.147.102.235) (Ping timeout: 255 seconds)
2026-03-11 12:19:33 +0100ChubaDuba(~ChubaDuba@46.147.102.235) ChubaDuba
2026-03-11 12:11:07 +0100vados(~vados@46-133-57-88.mobile.vf-ua.net) (Ping timeout: 264 seconds)
2026-03-11 12:08:15 +0100Digit(~user@user/digit) (Ping timeout: 268 seconds)
2026-03-11 12:08:09 +0100Digitteknohippie(~user@user/digit) Digit
2026-03-11 10:19:17 +0100ChubaDuba(~ChubaDuba@46.147.102.235) (Quit: WeeChat 4.8.1)
2026-03-11 09:28:53 +0100ChubaDuba(~ChubaDuba@46.147.102.235) ChubaDuba
2026-03-11 09:21:39 +0100DigitteknohippieDigit