all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Eshel Yaron <me@eshelyaron.com>
Cc: rudalics@gmx.at, 70622@debbugs.gnu.org
Subject: bug#70622: [PATCH] New window parameter 'cursor-type'
Date: Mon, 29 Apr 2024 12:08:08 +0300	[thread overview]
Message-ID: <86cyq8sfif.fsf@gnu.org> (raw)
In-Reply-To: <m1jzkg60py.fsf@dazzs-mbp.kpn> (message from Eshel Yaron on Mon,  29 Apr 2024 10:18:33 +0200)

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: rudalics@gmx.at,  70622@debbugs.gnu.org
> Date: Mon, 29 Apr 2024 10:18:33 +0200
> 
> Eli Zaretskii <eliz@gnu.org> 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.





  reply	other threads:[~2024-04-29  9:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-28  6:27 bug#70622: [PATCH] New window parameter 'cursor-type' Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-28  7:22 ` Eli Zaretskii
2024-04-28 15:00   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-28 15:29     ` Eli Zaretskii
2024-04-28 19:05       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-29  6:31         ` Eli Zaretskii
2024-04-29  8:18           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-29  9:08             ` Eli Zaretskii [this message]
2024-04-29  9:48               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-29 11:10                 ` Eli Zaretskii
2024-04-30  9:03                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-30 12:12                     ` Eli Zaretskii
2024-05-09  7:44                       ` Eli Zaretskii
2024-05-09 10:56                         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-09 11:25                           ` Eli Zaretskii
2024-05-09 14:19                             ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-10  8:58                               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-10 16:20                                 ` Eli Zaretskii
2024-05-11  7:35                                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-11  8:34                                     ` Eli Zaretskii
2024-05-12  8:29                                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-12  9:39                                         ` Eli Zaretskii
2024-05-12 12:33                                           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-13  8:05                                             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-13 12:13                                               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-18  9:43                                                 ` Eli Zaretskii
2024-05-18 13:45                                                   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-10 16:19                               ` Eli Zaretskii
2024-04-29  9:48       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86cyq8sfif.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=70622@debbugs.gnu.org \
    --cc=me@eshelyaron.com \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.