emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs-29 b18754bb179: Minor improvements in c-ts-mode and docs


From: Dmitry Gutov
Subject: Re: emacs-29 b18754bb179: Minor improvements in c-ts-mode and docs
Date: Thu, 16 Feb 2023 14:51:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 16/02/2023 14:03, Eli Zaretskii wrote:
Date: Thu, 16 Feb 2023 13:17:41 +0200
Cc: emacs-devel@gnu.org
From: Dmitry Gutov <dgutov@yandex.ru>

On 16/02/2023 09:32, Eli Zaretskii wrote:
I consider it confusing and sub-optimal
to have some C-related feature described in the Emacs user manual that
works only in CC Mode.  We have a couple of other keybindings in
c-ts-mode.el, for the same reasons.

I'm not going to chime in about every such keybinding, but this could be
our chance to reduce inconsistency between C mode and other language modes.

We could at least discuss that, sure.  Is there a list of
inconsistencies between those modes available anywhere?

From past discussions and looking at 'C-h m':

- "electric" behaviors: CC Mode's commands vs. electric-indent-mode and electric-pair-mode.
- c-subword-mode vs subword-mode
- c-display-defun-name vs which-function-mode
- c-indent-exp vs prog-indent-sexp
- c-indent-defun/c-fill-paragraph vs prog-fill-reindent-defun
- c-indent-line-or-region vs indent-for-tab-command and indent-region.

Curious how c-indent-line-or-region doesn't mind depending on transient-mark-mode being on.

The next question, of course, is how to go about reducing the
inconsistencies.  What you proposed here is simply drop the
keybinding,

I also suggested, alternatively, that transient-mark-mode, when turned off, creates a global binding for comment-region (also with 'C-c C-c'). I'm guessing (almost?) all of the users who turn it off simply started with Emacs when that was the default behavior. If they haven't reported the lack of this binding in various modes, they aren't going to mind the shadowing of it as well.

but that might not be a good idea for other
inconsistencies, even if we finally decide that for this one it is
okay.

The general plan could be:

- Wait for a complaint or a bug report.
- See if there is a generic feature which could be used instead. Or whether it could be tweaked. - Or whether a new feature would benefit most/all programming modes and can be added to prog-mode instead, and it's easy enough to do.
- Add stuff to c-ts-mode otherwise.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]