ocaml / tuareg

Emacs OCaml mode
GNU General Public License v3.0
360 stars 79 forks source link

Target newer Emacs version #295

Closed bbatsov closed 1 year ago

bbatsov commented 2 years ago

Currently tuareg-mode targets the ancient Emacs 24.4 that was released way back in 2014 and pretty much no one uses these days. Even the most conservative Emacs distros like Debian and RHEL have Emacs 27 these days, so I'd propose bumping the required Emacs to 26.1. (I like the idea of supporting the last 3 major Emacs releases in general)

Any objections?

monnier commented 1 year ago

Currently tuareg-mode targets the ancient Emacs 24.4 that was released way back in 2014 and pretty much no one uses these days. Even the most conservative Emacs distros like Debian and RHEL have Emacs 27 these days, so I'd propose bumping the required Emacs to 26.1. (I like the idea of supporting the last 3 major Emacs releases in general)

I'll let Christophe make such a decision, but I think the discussion would be more meaningful if we talked about the corresponding impact on our code. e.g. what could we simplify, which new features could we use, ...

    Stefan
bbatsov commented 1 year ago

@monnier That's already done, btw. (in Tuareg 3.0)

As for the things to leverage from newer versions - I was mostly thinking of things like newer core APIs (seq, map, etc). We can create a separate ticket for this to discuss specifics.

mattiase commented 1 year ago

newer core APIs (seq, map, etc)

I doubt seq and map bring us more than slower code but there may be other things to make use of. There is some low-hanging fruit for someone who wants to clean up compatibility code for Emacs 25 or earlier.

monnier commented 1 year ago

As for the things to leverage from newer versions - I was mostly thinking of things like newer core APIs (seq, map, etc). We can create a separate ticket for this to discuss specifics.

This sounds a hammer looking for a nail. It should be the need for a specific functionality/simplification that should drive the motivation to bump up the required Emacs version, not the other way around.

bbatsov commented 1 year ago

No argument from me. I just didn't have time to compile the list of concrete proposals that's why I mentioned the typical type of cleanup/facelift work I do when I adopt newer Emacs versions.

I doubt seq and map bring us more than slower code but there may be other things to make use of.

They bring more consistent API and eliminate the need for using libraries like cl-lib. For me that's a win, but obviously opinions on the subject vary.

There is some low-hanging fruit for someone who wants to clean up compatibility code for Emacs 25 or earlier.

Yeah, certainly. That's one area I plan to look into when I have a bit of time.

mattiase commented 1 year ago

They bring more consistent API and eliminate the need for using libraries like cl-lib.

cl-lib is an Emacs built-in package just like seq and map. The main difference is that cl-lib is generally richer and faster, especially the macros. No user will thank us for using either, and I rarely touch them when performance is even slightly important.

Maybe SMIE has features in more recent Emacs versions that could benefit us (Stefan would know). The number one complaint about Tuareg must be the maddening indentation, especially of comments, in some cases; doing something about that would be most welcome.

The Xref API has seen some improvement since Emacs 24 but perhaps it's more naturally to have it interface with Merlin.

bbatsov commented 1 year ago

The Xref API has seen some improvement since Emacs 24 but perhaps it's more naturally to have it interface with Merlin.

Merlin has been using xref for a while now (see https://github.com/ocaml/merlin/blob/master/emacs/merlin-xref.el). Note that xref didn't even exist before Emacs 25.1.

mattiase commented 1 year ago

Merlin has been using xref for a while now

Looks like there's an Xref-related PR gathering dust there – Merlin seems short-handed with respect to Emacs these days.