Module proposal: crafted-contrib

[mgmarlow]

I had an idea for a new module that is centered around Emacs Lisp best practices for package development/Emacs core contribution. It's not quite the same as crafted-lisp (though there is some overlap) since the idea isn't to provide an environment for multiple Lisp languages, but to lower the barrier of entry just for for Emacs Lisp.

Some things I was thinking could go in this module:

• Flymake
  • elisp-flymake-checkdoc
  • elisp-flymake-byte-compile
  • package-lint-flymake
• agressive-indent-mode (overlaps w/ crafted-lisp)
• M-x autofill templates
• The documentation generation tools for crafted-emacs contribution

What do ya'll think? There's probably other things that could go in here w/ regards to finding bug reports, submitting patches, and so on. Curious to hear your thoughts.

[jvdydev]

I like the general idea, especially since the current code for building docs feels somewhat misplaced in the docs/ directory ...
However I do wonder if this would end up being quite a big file.
I was wondering if we should pull out tools/contrib into a separate directory (e.g. a contrib/ or tools/)?

I also could see a split solution with a tools/contrib directory for the Crafted Emacs specific things (docs-builder, docs-linter, ...) and a general "contrib" module for writing Emacs Lisp/packages (package-lint, ...).

[mgmarlow]

I see what you mean, a directory is probably needed for the crafted emacs tooling. Part of my original thinking was that someone contributing to emacs would also likely contribute to crafted-emacs. Could the contrib module load submodules from the contrib directory? crafted-docs and crafted-lint, etc, could be features in the contrib directory loaded via the contrib module.

[jeffbowman]

Initial thoughts:

We might end up with a web of things all of a sudden. For example, aggressive-indent is in the crafted-ide-packages module currently, and crafted-lisp-config checks to see if that package is available before adding it as a hook to the various lisp modes.

Linting is a great idea, but why not just add some configuration for emacs-lisp inside the crafted-lisp-config module and keep all of it together? Some of those other modes could probably benefit from linting as well. Same with flymake, although sly and geiser do some of that work already.

More autofill templates would be nice to have, we currently have one for Crafted Emacs modules, others which are more generic might be interesting to explore. I'm curious what you think would make sense. Emacs also provides an autofill template for a lot of file types, including lisp. Currently Crafted Emacs doesn't provide more because we cover the base of our own modules and allow the default built-in templates to handle the rest.

So, my opinion would be to add this stuff to the crafted-lisp-config module and keep it more general. Some people may benefit from this kind of configuration even when writing their own packages (like ement.el or something along those lines, or even their own internal packages or modules). So writing to target a single use-case (like contributing to Emacs) seems a bit more narrow than what we are trying to provide with Crafted Emacs... which is a "good enough" general approach that can be easily extended or overwritten by the end user.

[mgmarlow]

Sure, I see your points. The reason I went for contrib instead of adding these items to the lisp module were:

1. I don't personally use the lisp module because I don't code in CL, Scheme, Clojure
2. After seeing Stefan's Q&A at EmacsConf I became more interested in contributing directly to Emacs core, but didn't know where to start (hence the debbugs package, which he recommended)--I was interested in other people's workflows in this space
3. I was interested in integrating the crafted-emacs tooling into contrib since it seemed a natural fit
4. I wasn't totally sure on the viability of package-lint in crafted-lisp. It seemed questionable to recommend turning on Flymake for a beginner who might be confused by the various documentation/file headers/global variable warnings that apply to package situations not necessarily relevant to a personal init.el

So I think altogether perhaps there's not enough value in the contrib module as-is for it to be a thing. Adding package-lint to crafted-lisp could definitely make sense, but I still think point 4 is a compelling reason to think it through, as it might be confusing for beginners.

[jeffbowman]

I appreciate the time you put into thinking about this.

Responses to your list:

1. That's okay, they only turn on when you do use CL, Scheme, or Clojure. We could take a similar approach with Emacs Lisp.
2. I need to go watch that, but I like the idea of including debbugs. As I haven't contributed to Emacs core in a while, I might need to review requirements in that space. Also, keep in mind, Emacs core includes C - may not be completely relevant in this context. But if someone wanted to contribute to a package, shouldn't the same configuration be used as for contributing to Emacs core?
3. No additional response, see previous comments, but I do appreciate your perspective on this.
4. You probably thought about this, but Crafted Emacs as a project is about the configuration of Emacs as a tool, while individual modules are about the configuration to use this tool (Emacs) to do useful things. So, adding linting and flymake configuration to assist a user developing in Emacs Lisp for package contributions or Emacs core contributions, seems to be aligned with the project in general. We'd want to make sure any configuration provided was "reversible" by the end user, thus opting in via defun, hooks, defcustom or other mechanisms would be appropriate.

In general, I'd probably agree with you (for the moment), but with the caveat that we should continue to explore the possibilities and how we might provide the best experience we can for the users of Crafted Emacs. There are some good ideas and good thinking on this thread, and it's a minor dissension as to where those ideas would eventually reside and why.