frontmacs 2.0

[cowboyd]

Frontmacs was created to make long-term usage of Emacs joyfully low-friction. In practice this means four things

1. Easy onboarding With a functioning Emacs installation, it should be as simple as running a single command to get boostrapped, whether you're starting from scratch, or hopping aboard with an already established configuration.
2. Easy evolution Once aboard, upgrading Frontmacs should be as low friction as installation. Instead of a pull-and-merge strategy
3. Awesome by default Advanced features that a expert user would expect in any other modern IDE are enabled out of the box. In other words, it should compare favorably to a VSCode or a Jetbrains product, and it works well on MacOS, Windows, and Linux.
4. Emacs by default Favor enhancment of existing functionality, conventions, and community solutions over the introduction of new ones.

It's been about 6 years that we set out on this mission, and while there has been much notable success, there are certain critical areas where we fall short of realizing the points of that core mission. The biggest reason for this is that we are currently maintaining our own ELPA server in order to host packages. The reason for this was that our packages were originally rejected from MELPA, the most popular community host, for not meeting their guidelines. Rather than spending more development cycles on our editor and re-thinking its package architecture which was difficult to justify at the time having already invested so much time into something not directly billable, the decision was made to set up a CI/CD pipeline to push frontside packages directly to MELPA.

Now however, this has proven to be a major blocker to the evolution of the platform. The frontside elpa server elpa.frontside.io is a rinky dink node.js app, that does not get frequent security patches, and is only set up to host a single ELPA package. As a result, the entire distribution has to be distributed as a lump, with a gigantic amount of elisp code that is completely useless to anybody that is not using the entire thing.

Revamping the package architecture

Instead of making frontmacs a single "configuration ball" of a package, we need to make it a collection of packages that can be installed publicly from community infrastructure, and that can be consumed independently of whethere you are using the frontside distribution or not. This will have several key consequences: packages can be upgraded and installed independently, and maintainance of hosting infrastructure can be completely deprecated.

In order to execute this, we need to take current functionality and package it in a way that meets MELPA guidelines, publish it on MELPA, and then require it from an init script that points to MELPA and requires the different frontside packages with use-package.

Finally, there was a custom configuration system that the old frontmacs used which will be abandoned. Emacs already has a configuration system, and where appropriate we should use it.

For each package that we extract, consolidate and submit, it has to have the following aspects.

1. A well thought out README that explains the motivation for this package, the approach taken in implementing it, and how it can be used. Note that this should take into account that this package should be usable without consuming all of the other frontside packages. It should also contain a link to the main Frontmacs README. Any keybindings and interactive functions should be documented.
2. A reasonably complete unit test suite testing the functions of this package. If it can't be tested, then maybe it shouldn't be its own package?
3. Follows MELPA guidelines, and passes all elisp linting checks. The linting should be part of the CI checks.

Packages

The individual packages to be extracted are:

• frontside-javascript
  • html (html support should be added to frontside javascript)
  • css (css support should be added to frontside javascript)
  • json (you can't do javascript without JSON)
• frontside-windowing functions to make splitting windows eaiser
• frontside-editing make editing
• frontside-completion In the same way that JavaScript "just
  works". Make completion work too.
• frontside-project When you open up a project that contains a
  git repo, or an npm project, or a ruby project, or whatever, it
  should "just work"
  • projectile
  • editorconfig
  • LSP there are some project level configurations for
    language server, so whenever that is installed we should set
    them, but not when it isn't.
• frontside-macos Things that are specifically tuned to
  running on MacOS. These are GC settings and key bindings. This
  may include the implementing vendor frames ourselves.
• frontside-dart
• frontside-yaml
• frontside-ruby

Deprecations

The following packages are deprecated, and will have no replacement in the next version of Frontmacs.

• frontmacs-config this was just a bad idea.
• frontmacs-style themeing is not necessary and can be handled by
  normal emacs, other functionality is subsumed into
  frontside-modeline, frontside-editing
• frontmacs-ui subsumed by editing.
• frontmacs-modeline any package that piles on minor modes is
  responsible for diminishing them if it needs to.
• frontmacs-vcs we'll just use magit with a use-package
  declaration in the init script.

On-boarding

Getting bootstrapped onto Frontmacs should be a single command.

from a package manager:

$ brew install frontmacs

via curl one-liner:

$ curl emacs.frontside.com | bash

This will set up a new frontmacs install by creating an .emacs.d/init.el that sets up MELPA, and then brings in key frontmacs packages using use-package. It will contain a README.md explaining how the init.el works, and the init.el will contain a link to that readme. The location of this readme should be logged to the console as part of the installation process.

In the event that there is already something in the .emacs.d directory, it will be moved to a backup location, and the README will contain a reference to this location.

Git integration

If the system onto which it is being installed has git, it will initialize the .emacs.d repository as a git repo, so that it can be pushed and checked out later.

In order to make installation on remote machines a snap in the event that you have customizations, all of the one-line installers will support installing the .emacs.d directory from a set location. That way, you can push your repository with your customizations to github, and whatever machine you're on, you can pull in your custom configuration just by mentioning it in the install.

via package manager:

$ brew install frontmacs --with-source cowboyd/.emacs.d

or via curl:

$ curl emacs.frontside.com | bash -- cowboyd/.emacs.d

If that is the case, then instead of generating a new configuration and creating a repository in which to store it, the installer will just clone the specified repository and use that instead.

Evolution

One of the key goals of Frontmacs is to make upgrading and evolving your editor platform as easy as it was to install it. That means that with a single command you can bring your installation up to date. One of the advantages of having all of the packages be MELPA is that most of the time, this just entails running a normal package update. In fact, that will work just fine to update your packages. However, in order to make things as convenient as possible,

CLI

The frontmacs CLI will make sure that you have simple access to upgrading your editor platform. You can run the frontmacs command in place not only to upgrade your ELPA packages, but also to try to bring in a new static configuration template for .emacs.d. For example, if your boilerplate is up to date, but you have some packages that could be upgraded:

$ frontmacs status
frontmacs version 1.0.1
.emacs.d configuration is up to date (v14)
12 packages can be updated.

On the other hand, if your boiler plate could be updatetd, but your packages are in sync

$ frontmacs status
frontmacs version 1.0.1
.emacs.d can be updated from v12 -> v14. Run `frontmacs update` to update

OS Package managers

• MacOS (homebrew)
• Windows
• Linux