From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6AyPHB7H72GjIgAAgWs5BA (envelope-from ) for ; Tue, 25 Jan 2022 10:47:10 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 8Fr1GR7H72EhPwAA9RJhRA (envelope-from ) for ; Tue, 25 Jan 2022 10:47:10 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 86DB639A5E for ; Tue, 25 Jan 2022 10:47:09 +0100 (CET) Received: from localhost ([::1]:52002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCIPs-00014E-FK for larch@yhetil.org; Tue, 25 Jan 2022 04:47:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33468) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCILd-00082n-6a for emacs-orgmode@gnu.org; Tue, 25 Jan 2022 04:42:46 -0500 Received: from [2607:f8b0:4864:20::42a] (port=37770 helo=mail-pf1-x42a.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nCILZ-0006K6-Qe for emacs-orgmode@gnu.org; Tue, 25 Jan 2022 04:42:44 -0500 Received: by mail-pf1-x42a.google.com with SMTP id p37so19186057pfh.4 for ; Tue, 25 Jan 2022 01:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=B3CLcgCXD9tT920w9Aj54nWuUBtxz/xB9uR0mnhuLFg=; b=U8d+yW/qa4wFBRpKVB6MRpkQl//bJmS8W1LeP23DZCfIwV5VRKvLrPVmtDP2uiZa5u N2sNpfj/o0X2RFG5FL5zEtzB868za9+zcNfPBwQCXNr49wmP1XZxAWWDqgLJuGB6/f+S HhqcO5rHYhqcPEjo32zPIVD4VlaGn3+1IDeDJMHKkyMcMQHhS1QvMCVwOs+aeiJ3Sp52 Dw41xMoTaZ1cAs0O2pqqMM/4vfSbwShczPx1TBh136x4rPm1VGAuUJqkSEawj1D0NBOQ ++efbAVgGtylbx7Oec+a9weGLKddxpVutOtZy7WOUprClfptIy523CH1WkpUBGOvwJxh zKNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=B3CLcgCXD9tT920w9Aj54nWuUBtxz/xB9uR0mnhuLFg=; b=7sHmlSoiPtYbl0Yum/QbkSK8NE7Alxlj5IreCkNkg6wdLp3HzTmYFkYGJEXhZnLkl2 vkzhAfE8Y+uSUkYYV/Lvi1r38IWtbpcyMCCwUR1SHBw2eD8hKEPvZ4HJlXme66MGMDaf xiBuBjxI6v21+i8SVsK/5eYB+hfFAtl7wSamfeevSxjAX01kvmXuVc54wv1minigEj2Q grmhNU8wsLUWaYYoHKyscnDmD2ra8J6IIua+5tMqHV0qx/MomKvrGbbpo9EN/mDoIgY9 ToDTqdembjrDNiYduPcBC8/if86KtJqsqGrud49Jj2UwDsv9kgbcvvvo/JuOgbgNakgD i28Q== X-Gm-Message-State: AOAM53000xjK6h4Ap9Z+oqBLUVzgxFFqdUgiqlkPRKQCh5J8rYxHG2uC oIYCftnE6QUVQWrPWyta5B4WxRuqg1g= X-Google-Smtp-Source: ABdhPJyJHX/IEnCHnqJEGV9tj3h5yFXXYw9J8P+MPLgromJUNWVvHHFHGNwi636Auj5dRy+9yGY1EQ== X-Received: by 2002:a63:b202:: with SMTP id x2mr15122081pge.234.1643103663783; Tue, 25 Jan 2022 01:41:03 -0800 (PST) Received: from dingbat (2001-44b8-31f2-bb00-ccfd-eb43-81e6-ad1a.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:ccfd:eb43:81e6:ad1a]) by smtp.gmail.com with ESMTPSA id a13sm1513775pgv.27.2022.01.25.01.41.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jan 2022 01:41:03 -0800 (PST) References: <877daw6i8l.fsf@hornfels.zedat.fu-berlin.de> <878rvblwmx.fsf@localhost> <87y23b6dvz.fsf@hornfels.zedat.fu-berlin.de> <874k5zlsd2.fsf@localhost> <87sftj6ard.fsf@hornfels.zedat.fu-berlin.de> <871r13kvfg.fsf@localhost> <874k5x4oc7.fsf@gmail.com> <874k5tkym6.fsf@localhost> User-agent: mu4e 1.7.6; emacs 28.0.91 From: Tim Cross To: Ihor Radchenko Subject: Re: Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected) Date: Tue, 25 Jan 2022 19:51:15 +1100 In-reply-to: <874k5tkym6.fsf@localhost> Message-ID: <87ee4wdufr.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::42a (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::42a; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42a.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1643104030; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=B3CLcgCXD9tT920w9Aj54nWuUBtxz/xB9uR0mnhuLFg=; b=bYt2gU5RpZbiUKwPGTR34P03pi2rCg9UH1BglE5tXWjcZqHYRjIbMkxW6iluR8rBMTW8a7 p9jgvIXmWobHXIISwS8zzY9e6J1xd+xtrbj+NG4DZO/XVCO6UAgBEL0S5ptKuFWAtLbDHZ lYTdZ2KunsWtcvU5ZOhQTMlYnksz/5po1/Sle66RTcKdypj6zy+BFe8v1QD8OLPIR6QWD3 Icmz6JEqt3ve/tQvRvn2EUpI28VPfPtb8Ui1AoSeS4SZ/awzQn9GZnAT4Xr/S4pgaQaPw/ UXXAQV41mC0GtMzEwR9FmH/KtODXp/27wwPIo6B/poz6frmJBuSPOdxV4493wA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643104030; a=rsa-sha256; cv=none; b=ePYRvby1+pOlhqU417TZA5CPXiNoOAzeCDCKFeehgvThhwD2Bk80WGfAIKAzq0f1NmYVtd qUHxW7EubwxsO2q8CPhyCvTI0mEAh6B8dNNwfBTD6Co7iNIWEV/vVSnXArJIqRj2+NnSxc V3RGq7Wo8D3zRYbchZOa7CC26R6q0ag+zwsdocwSuWorTaAYv9jB8cqcKIRzF17BvVrTz2 BwRt4wBVyIqWadiWSOFN8z82LtmSCbceDKiX2zLdWwxxetjI++PGI5dQhYR08PK+Ggm6fO Wd2xHADr5ELP78YI9S/21KRe50kdL2Ymz34/bGYBMEfsHISEs626F3pmwtB8CA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="U8d+yW/q"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -7.83 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="U8d+yW/q"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 86DB639A5E X-Spam-Score: -7.83 X-Migadu-Scanner: scn0.migadu.com X-TUID: ra+Mvt2qoSUI Ihor Radchenko writes: > Tim Cross writes: > >> Ihor Radchenko writes: >> >>> Also, it appears to me that we may keep losing terminal-incompatible >>> keys in future unless we provide some mechanisms to check terminal >>> compatibility automatically. Any ideas? >>> >> >> No ideas on this. Problem being I don't think there is anything like a >> terminfo service which will tell you about what capabilities/bindings a >> terminal emulator has. >> >> Just some thoughts on this - >> >> I fear any such attempt is likely to end up in a game of 'wack-a-mole'. >> While it makes some sense to provide alternative key bindings for Emacs >> running under the GNU Linux console, especially given the limitations >> under the console are well defined and constant, I'm not sure >> we can provide reliable solutions or tests for different terminal >> emulators (which will often 'reserve' various key bindings for their own >> use. This is especially true for more advanced terminal emulators like >> tmux. > > We cannot even handle GNU Linux console now. Technically, man 5 terminfo > describes all the details on how to obtain terminal specs, but I am not > sure how to extract useful information for key binding purposes. Can we > do it programatically? > I probably wasn't clear enough in what I was trying to explain/suggest. I'll try to clarify. I think there are two different issues at play here. Key binding limitations in the Linux console and key handling in different terminal emulators. The first is fundamentally a limitation in the low level kernel terminal driver and not much which can be done except choose alternative key bindings when running under the linux console. The second is more about limitations within the specific terminal emulator program. Some emulators handle this better than others and it will be near impossible to find key bindings which will work across all different terminal emulators unless we restrict which key bindings we use to a much smaller subset, which will inevitably mean many difficult to use or less convenient bindings. This will just make everyone, including those using more capable terminal emulators, suffer less convenient key bindings and key bindings which are significantly different from those used when running native window/GUI version. It would make switching between GUI versions and terminal versions of Emacs even less convenient. As an example, on my Ubuntu 21.10 system, when running Emacs under the Linux console, C-c C-, completely fails. In fact,if you try to do describe key for that combination, it won't work because Emacs never sees the second key press. On the other hand, if I run Emacs inside mate-terminal, Emacs will see C-c , and not C-c C-, (but it does get both key presses). If I run Emacs under xterm, lxterm or uxterm, everything actually works just fine. Describe key will report the correct binding for C-c C-, I don't believe terminfo will be of any help here. If you look at the TERM setting for mate-terminal, uxterm, lxterm and xterm, they will all reference various versions of xterm (often xterm-color or xterm-256color etc). Looking at the terminfo definitions, I cannot see anything with would indicate whether C-, for example is supported or not. I know of no convenient and consistent way to determine if the terminal emulator being used will support things like C-, or not. For the Linux console, I think we can use the TERM environment variable to know when we are running under the Linux console if we want to provide different key bindings for some commands under the Linux console. There is also the possibility you could create a keymap for the Linux console which would configure some of the 'missing' modifier combinations to issue escape sequences which can be used to emulate the modifier behaviour under GUI environment - for example, I think you can create a keymap which will allow C-up/C-dwon/C-left/C-right etc. The question is, how useful will alternative key bindings actually be for the Linux console. I imagine the user base for people who only work under the Linux console is pretty small. For occasional use, the alternative bindings are unlikely to be that useful as it is too hard to change finger memory for occasional use and you probably won't remember the different bindings anyway (I would probably just use M-x command in these situations). For the terminal emulator situation, I believe we should do nothing except provide documentation on how to find or identify an appropriate terminal emulator which will support the key bindings used by orc, such as C-c C-,.