From nobody Wed Apr 5 00:26:10 2023 X-Original-To: users-jp@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PrlmZ5mMnz43T9F for ; Wed, 5 Apr 2023 00:26:22 +0000 (UTC) (envelope-from amogha@www2797.sakura.ne.jp) Received: from www2797.sakura.ne.jp (www2797.sakura.ne.jp [49.212.180.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PrlmX6fnZz3LK8 for ; Wed, 5 Apr 2023 00:26:20 +0000 (UTC) (envelope-from amogha@www2797.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of amogha@www2797.sakura.ne.jp has no SPF policy when checking 49.212.180.237) smtp.mailfrom=amogha@www2797.sakura.ne.jp; dmarc=none Received: from www2797.sakura.ne.jp (localhost [127.0.0.1]) by www2797.sakura.ne.jp (8.16.1/8.16.1) with ESMTP id 3350QAUE062091; Wed, 5 Apr 2023 09:26:10 +0900 (JST) (envelope-from amogha@www2797.sakura.ne.jp) Received: (from amogha@localhost) by www2797.sakura.ne.jp (8.16.1/8.16.1/Submit) id 3350QAed062090; Wed, 5 Apr 2023 09:26:10 +0900 (JST) (envelope-from amogha) X-Mailer: emacs 24.5.1 (via feedmail 11-beta-1 I) From: masa@amogha.jp (=?iso-2022-jp?B?GyRCNF07M0Q+PjsbKEI=?=) To: Takashi SHIRAI Cc: users-jp@freebsd.org Subject: Re: screen and emacs In-Reply-To: <20230401172716.6B16E2006660B@mx1.unixusers.net> (message from Takashi SHIRAI on Sun, 02 Apr 2023 02:27:16 +0900) Organization: =?iso-2022-jp?B?GyRCNF07M0Q+PjskTjtkRSo7SE1RJSIlSSVsJTkbKEI=?= Reply-To: masa@amogha.jp Date: Wed, 05 Apr 2023 09:26:10 +0900 Message-ID: List-Id: Discussion relevant to FreeBSD communities in Japan List-Archive: https://lists.freebsd.org/archives/freebsd-users-jp List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-users-jp@freebsd.org X-BeenThere: freebsd-users-jp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Spamd-Result: default: False [-1.51 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; NEURAL_HAM_LONG(-0.92)[-0.916]; NEURAL_HAM_SHORT(-0.81)[-0.810]; FORGED_SENDER(0.30)[masa@amogha.jp,amogha@www2797.sakura.ne.jp]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[users-jp@freebsd.org]; R_DKIM_NA(0.00)[]; HAS_REPLYTO(0.00)[masa@amogha.jp]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:9371, ipnet:49.212.0.0/16, country:JP]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; DMARC_NA(0.00)[amogha.jp]; REPLYTO_ADDR_EQ_FROM(0.00)[]; HAS_ORG_HEADER(0.00)[]; FROM_NEQ_ENVFROM(0.00)[masa@amogha.jp,amogha@www2797.sakura.ne.jp] X-Rspamd-Queue-Id: 4PrlmX6fnZz3LK8 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N 丸山です。 しらいさん、梅本さん、有難う。 そもそも環境変数 COLORTERM の意味・役割、その値 truecolor の意味は何なの でしょうか。 環境変数は、カーネルレベルで見れば、プロセスから子プロセスへ伝達される変 数に過ぎません。各プロセスは環境変数を自由に定義できるし、値の設定、変更 も自由です。ただしいくつかの環境変数、例えば LANG とか TERM とかは、その 意味・役割が「グローバルに」定められていて、皆それに従って使っています。 COLORTERM についてはそのような共通の意味付け・役割が定められているのでしょ うか。それはどこに書いてあるのでしょうか。 今回の事例について言うと、端末エミュレーター(konsole とか xfce-terminal など)と screen と emacs の三者の間で COLORTERM=truecolorの意味について、 もし共通認識がなければ当然問題が発生するでしょう。 ここまでは UNIX の初歩知識だと思いますが、それをもう一度頭に置いて考えて みると、梅本さんの「screenが消化不良を起こしている」とか、以下のしらいさ んの記述が実に適切に現状を言い表していることがわかります。 環境変数は通常親プロセスから引き継いだものをそのまま子プロセスに伝えるわ けですが、screenについては、TERM と TERMCAP をそのまま子プロセスに引き継 ぐわけにはゆきません。何故ならば screen が親プロセス(konsole とか xfce-terminal などの端末エミュレーター)から与えられるキャラクター画面を そのまま子プロセスに渡すわけではなくて、最下行(これをman screenでは "message line"と呼んでいます)を除いた部分を子プロセスに貸し与えるためで、 そのため、例えば子プロセスが TERMCAP の TCapCode cl (clear_screen, clear screen and home cursor)を発したとしても、 screen は message line 以外の 部分を clear する、という動作をする必要があります。つまりscreen は子プロ セスから受け取った画面制御コードを適宜翻訳して親プロセスに渡す、という動 作をしているはずで、その過程で COLORTERM=truecolor に対応するコードをう まく処理できていない、というのが、梅本さん、しらいさんの分析でしょう。な るほど。納得できました。 で、もし emacs の COLORTERM=truecolor に対する対処が適切であるのならば、 screen の方は「俺は COLORTERM=truecolor には対応していないぞ」と宣言する 意味で環境変数 COLORTERM は値を空にして子プロセスに渡すのが正しい態度だ ろうと思います。その意味で >　ソリューションとしては、下記 URL にあるように、~/.screenrc >に「setenv COLORTERM ""」の一行追記 は最も筋が通った対処策であると思いますが、私はどうもしらいさんの >termcap >を適切に記述すれば COLORTERM=truecolor のままでも対応出来そ >うに思えるんですが。 に一票入れたくなります。つまり emacs の方も何かおかしい。 以上 TERMCAP も 環境変数 COLORTERM も理解していない人間のまとめでした。 Sun, 02 Apr 2023 02:27:16 +0900 Takashi SHIRAI writes: >　しらいです。 > >In Message-Id <86cz4q86bh.wl-ume@mahoroba.org> > Hajimu UMEMOTO さんwrites: >> 梅本です。 > >> 環境変数 COLORTERM に truecolor が設定されていると screen 上で emacs >> の挙動が変になるというのを教えてもらいました。 > >　ふむ、Konsole は true color に対応しているので環境変数にて >その旨の設定をしていて、emacs はそれに従って true color 用の >シーケンスを吐いているのに、screen がそれを解釈して Konsole >に渡すことが出来ていないんですね。 >　そこまではいいですが、それだけだと TERM=xterm にした場合に >症状が治まる理由が説明出来ないんじゃないでしょうか。termcap >を適切に記述すれば COLORTERM=truecolor のままでも対応出来そ >うに思えるんですが。 >　emacs 側のソースも確認してみたんですが、TERM の値を文字列 >「xterm」と比較しているような気配もなさそうです。 > >　ソリューションとしては、下記 URL にあるように、~/.screenrc >に「setenv COLORTERM ""」の一行追記でいいんでしょうけど、な >んか釈然としませんね。 >https://www.reddit.com/r/emacs/comments/y9b8cd/emacs_running_under_screen_on_a_mac_going/ > > しらい たかし -------- 丸山 直昌 まるやま なおまさ メールアドレス： masa@amogha.jp