search

noctuid / general.el

More convenient key definitions in emacs
GNU General Public License v3.0
997 stars 44 forks source link

Semantic versioning and splitting general.el #144

Open noctuid opened 5 years ago

noctuid commented 5 years ago

This change will not have a huge impact on users but would make general better I think. It is low priority.

I want to make a 1.0 release with all obsolete functionality (mentioned at the top of the readme for at least a year) removed. I'll tag the last commit containing the obsolete functionality (though it won't help anyone who updates and is using obsolete functions). After this releases will be regular. Some benefits include a helpful, automatically generated changelog to make progress clear and the ability to lock to a specific tag of general (using an alternative package manager).

I still want to avoid breaking changes in the future (primarily because Emacs has no good builtin way to lock to a major version and the default way of installing a package is to just get the latest package).

The "public API" will be all non-internal functions (i.e. those with -- in the name). There are some functions like general--getf and general--extended-def-p that would be useful to anyone implementing their own extended definition keyword. It would make sense for these to be public, but I'd prefer all public functions in the general package to be geared towards use in Emacs configuration. If I decide to do this, I'd put these helpers public in a separate package (tentatively named usul.el). Variables like general-extended-def-keywords would probably be moved to usul but remain as aliases.

I wouldn't be surprised if no one has made a custom extended definition keyword, so I'll probably only do this if I find a good reason to move most of general's internals to a separate package (or if I have time and really want to). For example, this might be useful in order to add an alternative version of general.el for use in packages not in user configs (tentatively named consul.el). There has been some discussion on the evil-collection repo about this. I have mostly been opposed to using general.el in packages, but there is clearly some functionality in general.el that something like evil-collection could benefit from. It might make sense to have a stripped down version with only functionality that would make sense for packages. Given that many packages already use custom helpers to make defining keybindings more convenient, I think it would actually be less confusing if they all used the same helper. On the other hand, I don't want to make things too convoluted for something that wouldn't be that useful. I think it is definitely worth considering though. There is some relevant discussion in emacs-evil/evil-collection#48 and here.

If there were three separate packages, another question would be whether they are in separate repos and versioned separately.

noctuid commented 4 years ago

Also, helpers not related to keybindings should probably be put in a separate package completely (and loading it should not be required).