From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Shukaev Newsgroups: gmane.emacs.devel Subject: Re: Daemon/Client, Multiple Terminals, and `tty-erase-char' Date: Mon, 16 Dec 2019 15:51:10 +0000 Message-ID: <8D9B8C19-3DF8-4D21-9778-B1E50AFED0F4@Alexander.Shukaev.name> References: <8962B7D8-DE8B-48C0-A461-DA2C9ACB67C7@gnu.org> <5E9EBFBF-4784-46E6-BD42-793CA41FBC98@Alexander.Shukaev.name> <83eex45lvh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----K7CAW28841V5OJYDQ455IP8TPXK0Z6" Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="215098"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 16 16:51:45 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1igseq-000tjA-MD for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2019 16:51:40 +0100 Original-Received: from localhost ([::1]:55994 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igsep-0006Gp-FZ for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2019 10:51:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39996) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igseV-0006GO-2y for emacs-devel@gnu.org; Mon, 16 Dec 2019 10:51:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1igseT-0001ta-Nf for emacs-devel@gnu.org; Mon, 16 Dec 2019 10:51:18 -0500 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]:45901) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1igseQ-0001cX-Fz; Mon, 16 Dec 2019 10:51:14 -0500 X-Originating-IP: 46.114.5.194 Original-Received: from [10.140.181.194] (unknown [46.114.5.194]) (Authenticated sender: forum@alexander.shukaev.name) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id DB498C0005; Mon, 16 Dec 2019 15:51:11 +0000 (UTC) In-Reply-To: <83eex45lvh.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 217.70.183.198 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243412 Archived-At: ------K7CAW28841V5OJYDQ455IP8TPXK0Z6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I don't think this can be deprecated. That logic to determine the behavior of backspace and delete keys is important. I saw 'terminal-parameter' being used there, plus there are variables like 'local-function-key-map', which is supposed to be per-frame as that is it's purpose in the first place, and it even seems to have been introduced exactly for this 'normal-erase-is-backspace' use case because it's only directly mapped in that function. So I expected 'tty-erase-char' to also be frame-specific, otherwise, this is indeed unfinished and won't work even in the simple case of having both one GUI and one terminal clients at the same time.

On December 16, 2019 4:30:10 PM GMT+01:00, Eli Zaretskii <eliz@gnu.org> wrote:
 Date: Mon, 16 Dec 2019 05:57:59 +0000
 From: Alexander Shukaev <emacs@Alexander.Shukaev.name>
 
 The expectation is that 'normal-erase-is-backspace' does the right thing in different terminal of course. But
 that's just an example, and aside from it, this variable seems to be terminal-specific due to its nature.

Do you have a real-life situation where it is important to have
'normal-erase-is-backspace' to be different on different terminals?

We have some infrastructure to record the value in a terminal
parameter, but I don't see the mode function called when we switch
frames.  A
 nd a mode cannot be terminal- or frame-specific.

So it looks like if someone intended to make this work differently on
different terminals, they didn't finish the job.  Or maybe I
missing
something; but if not, the question is whether we really need this
stuff nowadays, or is it obsolete and should be removed at some future
point.
------K7CAW28841V5OJYDQ455IP8TPXK0Z6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I don't think this can be deprecated. That logic to determine the behavior of backspace and delete keys is important. I saw 'terminal-parameter' being used there, plus there are variables like 'local-function-key-map', which is supposed to be per-frame as that is it's purpose in the first place, and it even seems to have been introduced exactly for this 'normal-erase-is-backspace' use case because it's only directly mapped in that function. So I expected 'tty-erase-char' to also be frame-specific, otherwise, this is indeed unfinished and won't work even in the simple case of having both one GUI and one terminal clients at the same time. On December 16, 2019 4:30:10 PM GMT+01:00, Eli Zaretskii wrote: >> Date: Mon, 16 Dec 2019 05:57:59 +0000 >> From: Alexander Shukaev >> >> The expectation is that 'normal-erase-is-backspace' does the right >thing in different terminal of course. But >> that's just an example, and aside from it, this variable seems to be >terminal-specific due to its nature. > >Do you have a real-life situation where it is important to have >'normal-erase-is-backspace' to be different on different terminals? > >We have some infrastructure to record the value in a terminal >parameter, but I don't see the mode function called when we switch >frames. And a mode cannot be terminal- or frame-specific. > >So it looks like if someone intended to make this work differently on >different terminals, they didn't finish the job. Or maybe I missing >something; but if not, the question is whether we really need this >stuff nowadays, or is it obsolete and should be removed at some future >point. ------K7CAW28841V5OJYDQ455IP8TPXK0Z6--