From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70622: [PATCH] New window parameter 'cursor-type' Date: Mon, 29 Apr 2024 12:08:08 +0300 Message-ID: <86cyq8sfif.fsf@gnu.org> References: <864jbmuf39.fsf@gnu.org> <8634r5tsit.fsf@gnu.org> <86y18wsmqy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13982"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, 70622@debbugs.gnu.org To: Eshel Yaron Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 29 11:08:56 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s1N0J-0003LY-P0 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Apr 2024 11:08:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1N09-0000v7-Pr; Mon, 29 Apr 2024 05:08:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1N07-0000uo-DL for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 05:08:43 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s1N06-0001Gi-Dm for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 05:08:42 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s1N0Q-0005CX-8J for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 05:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Apr 2024 09:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70622 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70622-submit@debbugs.gnu.org id=B70622.171438173019987 (code B ref 70622); Mon, 29 Apr 2024 09:09:02 +0000 Original-Received: (at 70622) by debbugs.gnu.org; 29 Apr 2024 09:08:50 +0000 Original-Received: from localhost ([127.0.0.1]:56069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1N0E-0005CJ-5k for submit@debbugs.gnu.org; Mon, 29 Apr 2024 05:08:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1N0C-0005CD-1Z for 70622@debbugs.gnu.org; Mon, 29 Apr 2024 05:08:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1Mzm-0001FN-3Y; Mon, 29 Apr 2024 05:08:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Q5J5Bf5cqq4/cmARKJ6elQYBErdf10/WkHoau9sCvWE=; b=jqJwSJsmGpRX12cAsgtT 6w6CoIMeTvlX7xnSKiVQptE66g2rgXkDWgcCHD6CwBc5w1ab5At401F2qgte9wRTgNzZTVhvqbzFY PCucbXs/60gGNUHK4fFYk25qAbVz/o6cCBSVEIWP825mfIhkCD35iCzZ5MqpcNEilVEmZ5tL9W4Ke XK5qmbPRMGHcn7jgNbdltctr28lSp/MnMEpHKyjRfRzLOznmYPD5+dkkxQiiJx1+wfqCJxvMk3gVM PHzCMulFdEwTbFmzdxGHFqIaojId/2wWgOlHe8MrEhSY6jDZRe97cLW/sV+hw824Bd59jvWeh4T6m 9UizGK3KD4wUxw==; In-Reply-To: (message from Eshel Yaron on Mon, 29 Apr 2024 10:18:33 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284130 Archived-At: > From: Eshel Yaron > Cc: rudalics@gmx.at, 70622@debbugs.gnu.org > Date: Mon, 29 Apr 2024 10:18:33 +0200 > > Eli Zaretskii writes: > > > I still don't think I understand the difficultly. The "window > > parameter not set" can be detected by testing whether cursor-type is > > an element in the alist returned by window-parameters, couldn't it? > > Perhaps I'm missing something, but I think it's not so simple. We > can't/shouldn't interpret a value of nil differently from no alist entry > at all, since there's no way to remove alist entries (in order to unset > the window parameter) from lisp, right? Why is the ability to remove important? > > It is confusing to have several parameters and variables with a > > similar semantics that each require special quirks to get the same > > effect. We should try to make the forms of the values of such > > variables and parameters be uniform. > > Agreed. If we could use exactly the same format for the values of the > variable and window parameter that would be best. But AFAIU we need > some encoding (special quirk) when translating from variable values (VV) > to window parameter values (WPV), due to the competing interpretations > for nil. The first encoding I proposed is simple and uniform: cons to > go from VV to WPV, car to go the other way. The alternative encoding I > proposed below, following mode-line-format, is trivial for most VV, but > not uniform, because one needs to translate nil to 'none when going from > VV to WPV. > > >> Alternatively, we can use the exact same format for the window > >> parameter as we do for the variable, except we interpret a window > >> parameter nil value as "window parameter unset", not "no cursor", and > >> instead add another value for the window parameter, 'none, that'll > >> correspond to the nil value of the variable (so window parameter 'none > >> would say not to show the cursor). > > > > That's possible, but doesn't the absence of cursor-type parameter from > > window-parameters already allow to solve that? > > See above. Please let me know if I'm mistaken about the possibility of > differentiating a value of nil from the absence of an alist entry. > > >> This is in line with what we have > >> for the mode-line-format variable and window parameter, for example. > > > > Where do we use this convention for window parameters? > > See "(elisp) Window Parameters": > > ‘mode-line-format’ > This parameter replaces the value of the buffer-local variable > ‘mode-line-format’ (*note Mode Line Basics::) of this window's > buffer whenever this window is displayed. The symbol ‘none’ means > to suppress display of a mode line for this window. > > Here the window parameter has the same set of possible values as the > variable, except the window parameter also has the value 'none, which > corresponds to the variable's nil value. The nil value of the window > parameter means "window parameter not set". If this is unavoidable (which I'm not yet sure), we can use this. But let's first hear from Martin, maybe there are better ideas.