Re: c-ts-mode

[João Távora]

On Tue, Sep 12, 2023 at 9:01 AM Po Lu <luangruo@yahoo.com> wrote:
>

> But Custom itself fails to support EIEIO and defgenerics, so we should
> only introduce such defgenerics as user options when it is clear that
> the only users with reason to set them are already adept in Emacs Lisp.

That's why I specifically wrote: "if users are asked to go to Elisp...".

And, AFAIU, they _are_ being asked to go to Elisp in this particular
case.

And that's because treesitter-simple-indent-rules isn't a defcustom.

Could it ever be a defcustom?  Maybe.  But I'd say that's hard
because the ts indent rules DSL is complex and hard to express
in that manner.

And even if it were possible to do that (it probably is), it's
another question entirely if using that UI for that particular
purpose is more comfortable to the mythical "average user" than
using Elisp directly.

Furthermore, it's arguable that teaching multiple different complex
DSLs for customizing different parts of Emacs is a worse investment
than the practice of teaching basic reusable Lisp concepts that
are particularly useful for customization like user init files,
setq, eval-after-load, hooks, etc.  And why not `cl-defmethod`?
After all, people using Emacs are presumably using it as a file
editor to some capacity.

The super-popular frameworks such as Doom, Spacemacs (possibly
the natural habitat of the aforementioned mythical creature)
don't have any problems with teach their users Elisp naturally.

If we were to take a cue from these systems (and get over the some
of the CL allergies) we could -- on a case by case basis -- make
better decisions as to how to provide good customization APIs.

In summary, even though I personally don't like Custom for my
own customization I'm _not_ proposing to "get rid of it" or stop
providing defcustom specs, but to weigh the pros and cons when
considering it for a given customization point.  And of course
not use this as an argument against CL stuff, because Custom
can't express a lot of non-CL Lisp stuff either.

João