After posting this article to Reddit, I was asked about my motivation for using Forge over the GitLab UI. This section attempts to outline why I wanted to switch and what my impressions are after having used it actively for work for a couple of days.

As for Emacs Application Framework, I'd never heard of it before. It looks super cool, but I'm a bit scared that if I go down that road, I'll never make it out alive. Further, this post by u/DarkNightened has some really good points on why the EAF might not be the right fit for this use case (as well as some pretty 🔥 Surfingkeys tips).

I tried Edit with Emacs, and while it's a really neat way to interact with text, it wasn't for me (for GitLab). I still had to activate it using my mouse, and it didn't relieve me from using the mouse to interact with the label and assignment menus either.

I'm already a heavy user of Surfingkeys (though I realize I still have a lot of key bindings to internalize), and it's great for navigating your average website, but GitLab has so many things you can click on and interact with that it gets quite messy.

As was pointed out in the Reddit thread, there are a number of ways to deal with the web UI issue. Notable contenders are the /Edit with Emacs/ extension for Chrome and Firefox, Emacs Application Framework ( EAF ) and it's browser, and Vimium and Surfingkeys .

This means writing and editing text in plain HTML text areas (without your favorite key bindings) and then having to use your mouse to navigate a UI, find multiple searchable lists of elements and filter and find the items you're looking for.

What doesn't work very well, however, is creating issues or merge requests. Not only do you need to write fairly long-form content, but you will also frequently want to add 'labels' or assign someone to a task. GitLab does have so-called /quick actions/ , but they don't seem to work when used in the web UI.

Because of this, I have bookmarked various projects' merge request overviews and issue boards, and use the bookmarks for navigating. It's not ideal, but it works tolerably well.

I use GitLab for work, and while I think it's great in a lot of respects, it also has its share of issues, especially with the user interface. In general, navigating between projects, issue boards, and merge requests is very clunky and takes far too many clicks for it to be a good experience.

Early impressions

After having used Forge for a few more days, my impression is overwhelmingly positive. There are a few things it doesn't do, but I imagine some of that may be limited by the API that GitLab exposes. It also seems like GitHub receives more attention than GitLab, so it's quite possible that that integration has more features.

In the following sections, I'll be referring to issues and merge requests (MRs) collectively as topics, which is what Forge calls them.

The good parts Issues and MRs in the Magit status buffer :: This is the most basic thing that Forge gives you. In addition to just displaying these topics, it also displays labels (correctly color-coded) and whether a topic is open or not. If you expand an MR it'll list the commits it is made of. Viewing one of these items (by pressing <RET> ) will also display assignees, all related comments and actions that have been taken. Easy creation of issues and MRs from within Emacs :: Of all the things that Forge does, this is what I wanted more than anything. I'm pleased to say that it works incredibly well. There are a few things that you can't do from Emacs (see the next section), but these are minor issues. Autocomplete on typing when referencing issues and MRs, assigning users and labels :: This one took me by surprise, but when you start typing out a topic ID (prefixed with # for issues or ! for MRs) you get auto-completion on topics in the project. The completion candidates show not only the ID, but also the topic title. This is super handy if you're adding related topics or otherwise want to reference them. This applies to seemingly all Magit buffers, including buffers for topic creation and for commit messages. You'll also gain tab completion when assigning users to a topic or adding labels. Quick copy a link to any topic, or open the topic in your browser :: Opening a topic in your browser comes with a default key binding, and there is a function for adding the URL of the topic at point to your kill ring ( forge-copy-url-at-point-as-kill ). The latter wasn't bound to a key by default, but it's a very useful command when you need to share the link to a topic with a coworker or the like. Viewing and checking out MRs is a breeze :: It is incredibly easy to check out and create a branch from a merge request. Not much more to say about this, really. See the section on branching in the manual for more information.