Customizable face for numbers

[jsmestad]

Background

I had made a patch to doom-emacs (see doomemacs/doomemacs#3613) to highlight 10_000 correctly after the Elixir formatter had run. As a next step, I wanted to have this functionality built into emacs-elixir mode for those who want to customize how numbers show up.

While I was in there, I did some general cleanup based on best practices and the Emacs Lisp docs.

Changes

• Expose all variables as customizable
• Increment version to 2.4.0
• Expose font faces under the elixir group rather than font-lock-faces
• Add elixir-numbers-face
  • Set to default so it does not conflict with today's functionality
• Move elixir-format variables under the same elixir group.
• Add lexical-binding: t to top of the file (from style guide)

Discussion

Is default appropriate?

[jsmestad]

I changed up the test matrix as it was failing on Emacs 24.5 (same with master).

Looking around at other major modes, most have moved up to a minimum support of Emacs 26.3, so I did the same. I wanted to test Emacs 27.1 and Emacs 28.0.50, but EVM lacks support for these releases at the moment.

[jsmestad]

@Trevoke and @victorolinasc I rolled back all the attempted CI fixes. Please take a look when you get the time 👍

[victorolinasc]

I think this is too naive for parsing numbers in Elixir. I propose the following:

Suggested change

	(numbers . ,(rx (and symbol-start
	(? "-")
	(+ digit)
	(0+ (and "_" (= 3 digit)))
	symbol-end)))
	(numbers . ,(rx (and symbol-start
	(zero-or-one "-")
	(one-or-more digit)
	(zero-or-more (or digit (seq ?_ digit)))
	(zero-or-one ".")
	(zero-or-more (or digit (seq ?_ digit)))
	symbol-end)))

This will match things like:

0
-0
0_0
-0_0.0_0

I know they are not what the formatter will typically do but I see no reason why we should bind this face to only what the formatter does.

Not sure how this will behave inside comments, heredocs and so on though.

Also I am trying to follow the use of zero-or-more and friends because of what the rest of the file is using.

Tests would be good here too if possible.

[jsmestad]

If you prefer that, that's fine. I'll leave it your capable hands to get this across the finish line 🙏

[axelson]

I think this has some good changes (and I really like the documentation improvements for variables).

I think any future work to more flexibly support more number formats can be made as a followup PR.