Language Modules

[mgmarlow]

What do you think about introducing programming language-specific modules to help new users get started with popular languages? For example, a crafted-js-package/module might include:

• auto-mode-alist bindings for common extensions (js, ts, mjs, jsx, etc.)
• Install the prettier-js package with a keybinding on the js/ts-mode keymaps
• Some minor customizations to code style, like js-indent-level

The idea would be to provide a good starting place for those looking to extend crafted-emacs for a particular programming language, or an out-of-the-box solution so they can just install the module and start working. Here's an equivalent module from doomemacs for comparison.

There's some crossover with this idea and the tree-sitter language parsers installed via crafted-ide, since the configuration would be easier if we could make assumptions about what tree-sitter parsers/languages are installed by a user.

[jvdydev]

Thank you for the suggestion 😄
I like the idea in theory, we had something like that in v1 (crafted-python, crafted-erlang, ...).

I think the main problem (hence I think we moved away from it) is that you end up introducing one of a few things:

• duplication, 'cause most languages want eglot, tree-sitter, etc.
• inter-module dependencies (when e.g. a set of common configuration would reside in crafted-ide and crafted-js,crafted-python etc. would depend on crafted-ide)

Writing modules for tools that support multiple languages (like eglot, dape, ...) without imposing a load-order is quite complicated and not everything can be pulled out into the crafted-ide module either.
In any case this results in quite a large number of modules which all have to be maintained and work together well.

Not to mention currently all modules are two separate files (packages and config), so in the case of e.g. porting the old crafted-erlang module, you get two files with each only two lines of code (where only one per file was actually erlang-specific, the others were eglot).

There is also the question of where to draw the line and even what ecosystem to use if multiple are available (like LLVM vs. GNU in C/C++).
One could argue this already is somewhat a problem in the crafted-lisp module where we use sly over slime.

@jeffbowman probably has a better answer regarding why we moved away from it.

[jvdydev]

I wonder if there would be value in providing example custom modules in the documentation, like "Building a custom module for (JavaScript | TypeScript | Python | ...)" or similar to the examples/ directory.
Currently the process for custom modules is not that well documented.
I still need to get around to making the examples loadable (#383), so I may experiment a little with that soon.

[mgmarlow]

Appreciate the detailed responses, the theory makes sense. Dealing with the inter-module dependencies (particularly thinking about tree-sitter in its relation to language modules) would probably be more trouble than it's worth.

[ajxn]

I would love to have examples of different user provided set up for different languages.

About different settings, if the user have an set up to change, then it is much easier to change to another settings/tool for another set of tools/languages.

If those are in an examples directory or in the documentation (or both) shouldn't be a problem. Maybe set some variable in the beginning of the example to select a tested setting for a programming language/set of tools that work, if there are not a suitable selection.

[mgmarlow]

One nice thing about crafted-ide is that tree sitter takes care of most of the heavy lifting for language modes, provided you have the grammars installed. For example, with the typescript and tsx grammars installed via treesit-auto you're basically good to go for editing ts/js/tsx/jsx. This replaces something like web-mode and works as you'd expect with eglot and the typescript-language-server.

What's missing from the tree sitter major modes are extra utilities on top of syntax highlighting, like task automation and formatting. rust-mode is a great example, the equivalent rust-ts-mode is missing compilation/testing commands, rustfmt, and so on.

Generally this means the language-specific stuff ends up being a small amount of configuration. Here's what my JS/TS mostly looks like as an example:

(load (expand-file-name "modules/crafted-init-config" crafted-emacs-home))

(cl-defun crafted-init (&key modules packages)
  (dolist (m modules)
    (require (intern (format "crafted-%s-packages" m)) nil :noerror))
  (dolist (p packages)
    (add-to-list 'package-selected-packages p))
  (package-install-selected-packages :noconfirm)
  (dolist (m modules)
    (require (intern (format "crafted-%s-config" m)) nil :noerror)))

;;;; Packages and crafted emacs modules

(crafted-init
 :modules  '(defaults completion ui ide org writing)
 :packages '(ef-themes
             magit
             prettier-js
             exec-path-from-shell))

(crafted-ide-configure-tree-sitter)

(when (memq window-system '(mac ns x))
  (exec-path-from-shell-initialize))

;; JavaScript/TypeScript

(require 'prettier-js) ;; prettier-js command is not autoloaded, only the major mode
(customize-set-variable 'js-indent-level 2)

(with-eval-after-load 'js-ts-mode
  (define-key js-ts-mode-map (kbd "C-c C-f") #'prettier-js))

(with-eval-after-load 'typescript-ts-mode
  (define-key typescript-ts-mode-map (kbd "C-c C-f") #'prettier-js)
  (define-key tsx-ts-mode-map (kbd "C-c C-f") #'prettier-js))

(add-to-list 'auto-mode-alist '("\\.mjs\\'" . js-ts-mode))

[jeffbowman]

Yeah, that's an unfortunate situation, one over which we don't have much control. Hopefully the maintainers of language modes will be working toward more feature parity over time.

Clever bit of code, thanks for that!

On a separate note:

    (dolist (p packages)
      (add-to-list 'package-selected-packages p))

    ;; this could be replaced with the following, which may be more efficient:
    (customize-set-variable 'package-selected-packages
                            (delete-dups (append package-selected-packages packages))