From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id CAE0A22D57 for ; Sun, 30 Jun 2024 21:10:10 +0200 (CEST) Received: from out-187.mta0.migadu.com ([91.218.175.187]) by 9front; Sun Jun 30 15:08:39 -0400 2024 X-Envelope-To: 9front@9front.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trbsw.dev; s=key1; t=1719774516; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FkfFV55W+JH1ue/Q9mwB8U2/ARkVP5ZqVV5rhd6xndo=; b=oIxfXHML1zrGsZiqr1h1+VHE3KP3KVZtG81G+ZSjy9dtduQEWpelw7H8H0AwGcHx+Y9m+z ZtNLqgr1VKRl5r1b9ohBXmGuPcTsdlLcCEHLl2MDxHuhBxTsMMWsp57vehFEHS8BlERArD WRIh2nkhrEHMOHuZhtsv7bWyeKWf3Gg= Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sun, 30 Jun 2024 15:08:32 -0400 Message-Id: X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Timothy Robert Bednarzyk" To: <9front@9front.org> References: In-Reply-To: X-Migadu-Flow: FLOW_OUT List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: self-healing extended ActivityPub storage persistence frontend Subject: Re: [9front] [PATCH] Fix shift release events in X11 drawterm with shift:both_capslock xmodmap option Reply-To: 9front@9front.org Precedence: bulk > this does seem like your xmodmap is causing a bug in x11. I do actually have to apologize, I've had these options set in an X11 configuration file for months and had forgotten which program was used to enable the option on the fly. Prior to sending my first e-mail, I had quickly looked up the option to re-remember what program it was, and xmodmap came up first (and, incidentally, I now remember that when I was first attempting to do something similar to those options, I had tried to do it with xmodmap first). As it turns out, those options can=20 actually be set by setxkbmap, not xmodmap. The specific X11 program that actually contains the options is mostly an inconsequential detail here, I realize, but I wanted to correct myself regardless. > the behavior is completely non-sensical. maybe nobody ever tested this > x11 feature? ;) I wouldn't be surprised if some emacs users were using the same options as me; after all, I originally set them when I wanted to attempt to try out emacs and was following the advice of many who suggest remapping caps lock to control (but still wanted to have some way of toggling caps lock). While I ended up not using emacs too much (honestly, I think I prefer even ed over emacs), I did like the options that I'd set and have kept them since. Drawterm was the first program that I've used where this insane behavior in X11 actually surfaced as a problem, so I also wouldn't be surprised if I was the first one to thoroughly test the option and discover exactly how it's screwy. > not sure how much we should care about workarounds for bugs that only > happen in an edge-case of a (mis-?)configuration. That is a good point. Originally, I was so focused on "fixing" the "bug" in drawterm (when I should've just gone to bed) that I hadn't even considered just getting the actual X11 bug fixed where it should be once I learned what was causing the problem. I'll try to get it fixed wherever appropriate first; this change to drawterm can be saved as a last resort if someone determines that the current X11 behavior is not to be changed for some bs reason like "compatibility", or even worse: claims that it's actually the correct and intended behavior. > otoh a few well commented lines that contain a good justification for > this braindamage, which now exists after such deep analysis wouldn't > bother me personally... even if it's just a link to this thread. Should this change actually be applied to upstream drawterm, I fully agree that the comment should just contain a link to this thread. -- trb