Emacs on manuel uberti

I don’t know why I haven’t shared this little helper before, but here it is.

I make a lot of mistakes when I write prose, because I usually write down everything that comes to mind and then edit sentences and paragraphs over and over again until I get what I want.

Usually when I start writing a new document I am not immediately interested about the output layout.

Another year, another recap. 2023 has been a strange bunch of months for different reasons.

When I wrote about using Ugrep with Consult I hinted at the chance of having my custom command available in Embark as well.

I have already discussed how one can leverage ugrep and consult-xref to make a completing-read variant of project-find-regexp.

By now Emacs users are well aware of Tree-sitter and the built-in integration that comes with Emacs 29.

After having adapted vertico--format-candidate to behave like I want in my Marginalia-less setup, I noticed I still had undesired documentation during completion.

One of the Emacs packages I do not seem to get used to is Marginalia.

When I wrote about formatting Clojure buffers I also mentioned that Clojure LSP can take care of this among other things.

More than a month after my commitment to the default built-in completion system I can say that everything has been going smoothly.

Despite me doing my best to track Emacs development and build the latest master regularly, I forgot to check out the improvements on the default *Completions* buffer that are going to be available on the next official release of our favourite text editor.

For those who remember, the combination of AUCTeX and Eglot makes me happy.

This year I am going to approach my usual recap in a different way.

Contrary to my experience with free or open source projects, when it comes to the proprietary software I have been developing for work since late 2004, code formatting has never been matter of discussion.

Ages ago I did the minimally required amount of work to get Chris Done’s goto-last-point to MELPA.

This is just a quick update on the status of Eclipse JDT Language Server support in Eglot.

One Emacs package that has been with me for a very long time is diff-hl, and the reason is not its on-the-fly coloured fringe markers, but the fact that colours stay there when I visit the same buffer later.

While reading the nice Straightforward Emacs: Automatically Highlight Buffer Text, I kept wondering whether I could get a similar solution with Emacs built-in facilities.

This is going to be a small correction to my previous post about Ugrep and project navigation.

When I described how I use Ugrep in Emacs I forgot to mention something.

When thanks to its developers I added support for jdtls in Eglot, I did it by removing a lot of boilerplate in the package devised to accommodate the complex setup needed for Eclipse JDT to start the language server.

Almost a year ago I wrote about my handy mu-recursive-grep, an easy way to combine rgrep and vc-git-grep.

Tracking Emacs development is always nice, because I get to explore new things as soon as they are made available.

Last time I mentioned that I helped making it possible for Eglot to use jdtls, the Python helper script packaged with Eclipse JDT to start the language server with sane defaults.

I don’t think I have enough words to express my admiration for Eglot.

As you may already know, I take buffer switching seriously.

My recent experiments with Eglot and Java led me to figure out how to speed up the connection to Eclipse JDT Language Server.

The more I move to VC,1 the more I end up relying on M-!

Two weeks without Magit1 have forced me to rethink how I use Git in my projects.

Following my previous article on VC, I felt like proposing a key binding for vc-git-stash to the Emacs developers was something that could turn out to be useful for other VC users.

Some days ago I briefly wrote about my willingness to give Emacs built-in VC system a try for real.

I have been pretty busy since my last update here, but that does not mean I haven’t had the time to explore a couple of things for my everyday Emacs usage.

Look around this blog and you will find nice words about ripgrep.

I don’t know about you, but I like to monitor my Emacs configuration to see if it is growing out of control due to my penchant for experimenting with ELisp and new packages.

The more I remove code from my init.el to rely on Emacs defaults, the more I am getting used to it.

Not too long ago I wrote about my pleasant experience with icomplete-vertical-mode, a recent addition on Emacs master which gives a vertical spin to the good old Icomplete.

I explained my need for an English dictionary when I wrote about my own [helm-wordnut]({% post_url 2020-06-13-helm-wordnut %}).

This is going to be a real quick one, mainly a “thank you!”

Tracking the Emacs development by building its master branch may not be a smooth experience for everyone, but for the average enthusiast is the perfect way to see their favourite tool evolve, trying experimental things, and reporting back to the core deve…

First you have to excuse the awful title, but a cinephile cannot resist the temptation of an easy reference when the Emacs package he is going to write about is called Vertico.

Last time I left straight for the built-in package.el, a choice I have not had the pleasure to regret so far.

After more than a year with straight as my package manager, recently I have decided to sit down and look closely at how I handle my Emacs packages.

What a year this 2020.

My recent move from Flycheck to Flymake has proven to be a solid choice because the Emacs built-in syntax checker has yet to let me down.

In my first appreciation of project.el I wrote about a patch for project--files-in-directory.

The recently available Emacs User Survey made me think, once again, about the status of the technological world around me.

As a Clojure developer one of the most important packages in my everyday Emacs usage is CIDER.

There was a time when I just didn’t trust Emacs.

In his article What’s new in Emacs 27.1?