bug#60443: 29.0.60; c-ts-mode: Consider re-using c-file-style and c-basic-offset

bug#60443: 29.0.60; c-ts-mode: Consider re-using c-file-style and c-basic-offset

[Mohammed Sadiq]

It would be nice if c-ts-mode respects c-file-style and c-basic-offset
instead of its own variables.  Also I wish c-ts-mode respects other 
c-mode
variables (ie, cc-styles.el) so that I could use the same c-mode conf 
for
c-ts-mode too, eg., I could use:

/* -*- c-file-style: "gnu"; c-basic-offset: 4; -*- */

as file variables which would work both in c-mode and c-ts-mode, or the
following in dir-locals:

((nil . ((fill-column . 80)))
   (c-ts-mode . ((c-file-style . "GNU")
                 (c-file-offsets
                 (brace-list-intro . +)))))

Whether the mode used for C source file is c-ts-mode or c-mode is an
implementation detail as far as the settings are concerned (because I
don't want different styles for my code depending on the mode used).

I'm not asking about implementing the spacing and indentation rules, but
when they do, it would be nice if they re-use the same c-mode variable
names.


cheers,
Mohammed Sadiq


In GNU Emacs 29.0.60 (build 3, x86_64-pc-linux-gnu, GTK+ Version
  3.24.35, cairo version 1.16.0) of 2022-12-30 built on purism
Repository revision: 4922de626f05f0c26bc732b082c30c5c18a88416
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 
11.0.12101004
System Description: Debian GNU/Linux bookworm/sid

Configured using:
  'configure --prefix=/usr'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
   value of $LANG: en_IN.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 36077 7352)
  (symbols 48 5148 0)
  (strings 32 13069 1377)
  (string-bytes 1 368001)
  (vectors 16 9289)
  (vector-slots 8 147664 13259)
  (floats 8 21 24)
  (intervals 56 236 0)
  (buffers 984 11))

bug#60443: 29.0.60; c-ts-mode: Consider re-using c-file-style and c-basic-offset

[Yuan Fu]

> On Dec 30, 2022, at 7:17 PM, Mohammed Sadiq <sadiq@sadiqpk.org> wrote:
> 
> It would be nice if c-ts-mode respects c-file-style and c-basic-offset
> instead of its own variables.  Also I wish c-ts-mode respects other c-mode
> variables (ie, cc-styles.el) so that I could use the same c-mode conf for
> c-ts-mode too, eg., I could use:
> 
> /* -*- c-file-style: "gnu"; c-basic-offset: 4; -*- */
> 
> as file variables which would work both in c-mode and c-ts-mode, or the
> following in dir-locals:
> 
> ((nil . ((fill-column . 80)))
>  (c-ts-mode . ((c-file-style . "GNU")
>                (c-file-offsets
>                (brace-list-intro . +)))))
> 
> Whether the mode used for C source file is c-ts-mode or c-mode is an
> implementation detail as far as the settings are concerned (because I
> don't want different styles for my code depending on the mode used).
> 
> I'm not asking about implementing the spacing and indentation rules, but
> when they do, it would be nice if they re-use the same c-mode variable
> names.

IIUC part of the reason why we created separate major modes is that we don’t want to share configuration variables between the tree-sitter and elisp implementation. If they share some of the configuration variable but not all, it would be very confusing; it they share all variables, well that’s not possible because c-ts-mode doesn’t support all of c-mode’s features. Also, since c-ts-mode and c-mode’s implementation differs greatly, some of c-mode’s configuration wouldn’t make sense, or is hard to recreate, in c-ts-mode.

I’m sorry that there will inevitably be differences between c-ts-mode and c-mode. We’ll try to minimize the annoyance but it won’t be perfect.

Yuan

bug#60443: 29.0.60; c-ts-mode: Consider re-using c-file-style and c-basic-offset

[Dmitry Gutov]

On 31/12/2022 06:02, Yuan Fu wrote:
> IIUC part of the reason why we created separate major modes is that we don’t want to share configuration variables between the tree-sitter and elisp implementation. If they share some of the configuration variable but not all, it would be very confusing; it they share all variables, well that’s not possible because c-ts-mode doesn’t support all of c-mode’s features.

js-ts-mode uses js-indent-level. css-ts-mode uses css-indent-offset. 
python-ts-mode and bash-ts-mode don't have their own indentation 
settings, so I suppose they reuse the "regular" indentation code.

There are a lot of other ts modes which don't have anything to reuse 
("regular" mode is not in Emacs).

FWIW, that's my plan for ruby-ts-mode: to share those options where it's 
feasible, to avoid random duplication, and to make comparing and 
switching easier. The test suite can be shared more easily too.

> Also, since c-ts-mode and c-mode’s implementation differs greatly, some of c-mode’s configuration wouldn’t make sense, or is hard to recreate, in c-ts-mode.

I suppose the CC styles might be trickier to implement exactly the same.

bug#60443: 29.0.60; c-ts-mode: Consider re-using c-file-style and c-basic-offset

[Yuan Fu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 31/12/2022 06:02, Yuan Fu wrote:
>> IIUC part of the reason why we created separate major modes is that
>> we don’t want to share configuration variables between the
>> tree-sitter and elisp implementation. If they share some of the
>> configuration variable but not all, it would be very confusing; it
>> they share all variables, well that’s not possible because c-ts-mode
>> doesn’t support all of c-mode’s features.
>
> js-ts-mode uses js-indent-level. css-ts-mode uses css-indent-offset.
> python-ts-mode and bash-ts-mode don't have their own indentation
> settings, so I suppose they reuse the "regular" indentation code.
>
> There are a lot of other ts modes which don't have anything to reuse
> ("regular" mode is not in Emacs).
>
> FWIW, that's my plan for ruby-ts-mode: to share those options where
> it's feasible, to avoid random duplication, and to make comparing and
> switching easier. The test suite can be shared more easily too.

Hmm, yes, those modes live in the same file, and can be considered the
same package. c-ts-mode.el is separate from cc-mode.el so it makes less
sense to share variables.  Maybe we can say "same package, share vars,
different package, different vars", to avoid confusion?


Yuan

bug#60443: 29.0.60; c-ts-mode: Consider re-using c-file-style and c-basic-offset

[Dmitry Gutov]

On 02/01/2023 02:24, Yuan Fu wrote:
> Maybe we can say "same package, share vars,
> different package, different vars", to avoid confusion?

That would make sense.

Though ruby-ts-mode would break that convention too. :)

I suppose it might depend on whether the modes are considered to be 
interrelated anyway, even if not residing in the same file.

bug#60443: 29.0.60; c-ts-mode: Consider re-using c-file-style and c-basic-offset

[Yuan Fu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 02/01/2023 02:24, Yuan Fu wrote:
>> Maybe we can say "same package, share vars,
>> different package, different vars", to avoid confusion?
>
> That would make sense.
>
> Though ruby-ts-mode would break that convention too. :)
>
> I suppose it might depend on whether the modes are considered to be
> interrelated anyway, even if not residing in the same file.

Right. It probably helps if "independent" modes mention this in their
docstring. I added some text in c-ts-mode and c++-ts-mode’s docstring.

Yuan

bug#60443: 29.0.60; c-ts-mode: Consider re-using c-file-style and c-basic-offset

[Mohammed Sadiq]

On 2023-01-08 06:12, Yuan Fu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 02/01/2023 02:24, Yuan Fu wrote:
>>> Maybe we can say "same package, share vars,
>>> different package, different vars", to avoid confusion?
>> 
>> That would make sense.
>> 
>> Though ruby-ts-mode would break that convention too. :)
>> 
>> I suppose it might depend on whether the modes are considered to be
>> interrelated anyway, even if not residing in the same file.
> 
> Right. It probably helps if "independent" modes mention this in their
> docstring. I added some text in c-ts-mode and c++-ts-mode’s docstring.
> 

I personally (as a user) prefers to have single variable for both modes,
but if using different variables helps it maintain better, that
might be a better choice