Monthly Archives: October 2025

Configure Tmux to support true color and italics in Alacritty and Neovim

Leave a reply

I know there are many blog posts about configuring Tmux to support true color and italics in Alacritty, but many of them miss a crucial detail that breaks Neovim’s diagnostic undercurl (wavy underlines).
Many of them suggest overriding the TERM variable in Alacritty to xterm-256color, which causes Neovim to lose the ability to display undercurl correctly.
Many of them are also outdated or incomplete.

This is how I configured Tmux and Alacritty to work perfectly together, supporting true color, italics, and Neovim’s undercurl diagnostics.

The Problem

When using Tmux inside Alacritty, you may encounter several issues:

  1. No True Color Support: Colors may appear washed out or limited to 256 colors instead of the full 24-bit RGB spectrum
  2. Italics Not Working: Italic fonts don’t render correctly, or reverse video appears instead
  3. Neovim Diagnostic Undercurl: Neovim’s diagnostic undercurl (wavy underlines) shows as simple underlines instead

These issues stem from incorrect TERM environment variable configuration and missing terminal capability overrides.

For example, using the shell script linked below to check true color support, when it’s not working, you get (left: Tmux inside Alacritty, right: Alacritty by itself):

When it works, you get:

The Solution

1. Alacritty Configuration

DO NOT override the TERM variable in Alacritty. Leave it at the default value alacritty.

Why? Alacritty’s default TERM=alacritty includes the terminfo capabilities for undercurl, which Neovim needs to display diagnostic wavy underlines. Setting it to xterm-256color breaks this feature.

2. Tmux Configuration

Add the following lines to your ~/.tmux.conf:

Explanation:
– default-terminal "tmux-256color": Sets tmux to use a terminal type that supports 256 colors and italics
– terminal-overrides ",*:Tc": Tells tmux to enable true-color (24-bit RGB) support for all terminal types that support it

3. Why This Works

When you start tmux inside Alacritty:
– Alacritty sets TERM=alacritty (which supports true color and undercurl)
– Tmux creates a new environment with TERM=tmux-256color (which supports italics)
– The terminal-overrides setting tells tmux to pass through true-color escape sequences from the outer terminal (Alacritty)

This combination gives you:
– True color (24-bit RGB) support
– Italic fonts working correctly
– Neovim undercurl diagnostics rendering properly

Verification

To verify everything works:

Check true color support:

Check italics:

Check in Neovim:

  • Open a file with syntax errors or any diagnostics (including spelling errors)
  • You should see wavy underlines (undercurl) for diagnostics, not simple underlines

References

How we used Maven relocation for Xtend

Leave a reply

In Xtext release 2.40.0, we adopted Maven relocation to move Xtend Maven artifacts’ groupIds from org.eclipse.xtend to org.eclipse.xtext without breaking existing consumers.

References:

Rationale

Xtend’s Maven coordinates were relocated to comply with Maven Central’s new publishing requirements after the OSSRH sunset.

The new Maven Central publishing portal enforces namespace consistency: all artifacts in a single deployment must share the same groupId prefix (namespace). We were getting this error when trying to deploy:

Xtend Maven artifacts historically had groupId org.eclipse.xtend, while all other Xtext Maven artifacts use org.eclipse.xtext. This mismatch prevented us from publishing both in a single deployment to Maven Central.

See the detailed rationale in issue #3398 and specifically this comment.

Why relocation instead of just renaming

  • Backwards compatibility: Existing builds continue to resolve, emitting a clear warning rather than failing.
  • Gradual migration: Library and plugin maintainers can update on their own schedule.
  • Single source of truth: Only the new artifact publishes real content; the old coordinate becomes a lightweight stub POM.
  • Clear deprecation signal: A relocation message is more explicit than a silent artifact disappearance.
  • No breaking changes: Consumers don’t need to update immediately; their builds keep working.

Maven relocation basics (summary)

Maven relocation allows you to redirect artifact coordinates without breaking existing consumers.

The process involves:

  1. Real artifacts with the new groupId that contain actual JARs, source, and javadoc
  2. Relocation artifacts with the old groupId that are minimal POMs pointing to the new coordinates

A relocation artifact is a simple POM project with this structure:

At resolution time, Maven automatically replaces the old coordinates with the new ones and displays a warning to the user.

Our goals

  1. Preserve build stability for all existing Xtend consumers
  2. Minimize maintenance by publishing only one real artifact per logical module
  3. Provide a clear migration path with visible warnings
  4. Avoid transitive duplication (both old + new coordinates ending up on classpath)
  5. Comply with Maven Central’s namespace requirements

Implementation outline

Our implementation involved several steps (see PR #3461 for details):

Identify artifacts to relocate: All Xtend artifacts published to Maven Central under org.eclipse.xtend: org.eclipse.xtend.lib, org.eclipse.xtend.lib.gwt,org.eclipse.xtend.lib.macro, etc.

Create relocation parent POM: Created org.eclipse.xtend.relocated.parent to organize all relocation artifacts.

For each artifact, create a relocation POM module with:
– Packaging: pom
– Old groupId: org.eclipse.xtend
– Same artifactId and version as the original
– Relocation block pointing to org.eclipse.xtext

Separate publishing workflow: Since Maven Central requires same-namespace deployments, we had to:
– Build relocation artifacts separately
– Archive deployment bundles for manual upload
– Publish relocation artifacts in a separate step from main artifacts

Update CI/CD scripts: Modified Jenkins deployment scripts to handle both artifact sets.

Example relocation POM

Here’s a real example from our implementation:

When a consumer uses the old coordinates, Maven shows:

Ensuring no duplicate classes

Because the relocation artifact is only a stub POM with no JAR attached, the classpath will contain only the new artifact. This prevents:

  • Duplicate classes on the classpath
  • Class shadowing issues
  • Version conflicts between old and new coordinates

Maven and Gradle both handle this correctly by fetching only the relocated target.

Publishing workflow

The key challenge was Maven Central’s namespace requirement. Our solution:

  1. Main build: Publishes all org.eclipse.xtext artifacts (including the real Xtend artifacts with new groupId)
  2. Separate relocation build: Publishes all org.eclipse.xtend relocation POMs
  3. Validation: We performed dry-run deployments to verify Maven Central would accept the artifacts
  4. Manual upload: For milestone releases, we archived bundles and manually uploaded them to Maven Central

As noted in the PR discussion, we had to update version-bumping scripts to include the new relocation parent directory.

Migration guidance for consumers

Search your builds for the old groupId:
– Maven: mvn dependency:tree | grep org.eclipse.xtend
– Gradle: ./gradlew dependencies --configuration compileClasspath | grep org.eclipse.xtend

Replace org.eclipse.xtend with org.eclipse.xtext in your POMs or build.gradle files:

Run your build and verify the relocation warning disappears

Update any BOM or dependencyManagement entries

Tooling considerations

  • IDEs: Eclipse, IntelliJ IDEA, and other IDEs honor Maven relocation. Refresh your project after migration.
  • Gradle: Fully supports Maven relocation when resolving from Maven repositories.
  • Reproducibility: The relocation POMs are stable and don’t affect build reproducibility.
  • CI/CD: No changes needed; relocation works transparently in CI environments.

Lessons learned

  1. Maven Central namespace enforcement is strict: You cannot publish artifacts with different groupId namespaces in a single deployment, even if they’re in the same monorepo.

  2. Relocation is low-effort and highly effective: Once set up, relocation artifacts are trivial to maintain across versions.

  3. Separate publishing is required: Relocation artifacts must be published in a completely separate Maven deployment due to namespace restrictions.

  4. Testing is crucial: We performed dry-run deployments first to ensure Maven Central would validate the artifacts correctly.

  5. Scripts need updates: Don’t forget to update version-bumping and release automation scripts to include relocation modules.

  6. Communication is important: Clear documentation and release notes help consumers understand and adopt the changes smoothly.

  7. It works across ecosystems: Both Maven and Gradle consumers benefit from relocation automatically, as do IDE integrations.

FAQ

Q: Do I need to change anything immediately?
A: No; builds continue to work with the old coordinates, but you’ll see warnings. Update when convenient to eliminate warnings.

Q: Does relocation affect checksums or reproducible builds?
A: No; the new artifact is authoritative. The stub POM exists only for resolution redirection and contains no actual code.

Q: Can Gradle consumers rely on this?
A: Yes; Gradle honors Maven relocation information when resolving from Maven repositories.

Q: What about IDEs?
A: IDEs (tested with Eclipse and IntelliJ) honor Maven relocation when resolving from Maven repositories. You may need to refresh your project after migration.

Q: What if I use dependencyManagement or BOM entries?
A: Update them to reference the new groupId. Transitive relocation continues working in the meantime.

Q: Will this affect my transitive dependencies?
A: No; if your direct dependencies haven’t migrated yet, their use of old coordinates will be automatically relocated, and you’ll see warnings for those too.

Q: What happens if I have both old and new coordinates in my dependency tree?
A: Maven/Gradle will resolve both to the same artifact (the new one), so you won’t have duplicates on the classpath.

Install Ubuntu on Apple Silicon Macs Using UTM

Leave a reply

Let’s install Ubuntu 25.04 on Apple Silicon (M1) in a virtual machine using UTM.

We must first download an Ubuntu ISO for ARM. Go to https://ubuntu.com/download/desktop and search for “ARM 64-bit architecture”; if not available for the specific version you want to install, then you’ll have to install the Ubuntu Server and then install the “ubuntu-desktop” package. Before downloading the server edition, you might want to search deeper in the Ubuntu release download site and look for the ARM ISO, which is not advertised in the above download site. For example, for 25.04, you get the link for the ARM version from the download site, but not for 24.04. However, by looking at the releases web directory, you’ll also find the ARM ISO for 24.04 (for example, https://cdimage.ubuntu.com/releases/24.04.3/release/ubuntu-24.04.3-desktop-arm64.iso).

You can install UTM in several ways. I installed with Homebrew: “brew install utm”.

Let’s start it and create a new Virtual Machine:

Choose Virtualize (we want to use an ARM Linux distribution):

Then, of course, choose “Linux”

Here we use QEMU, not Apple Virtualization. We select the ISO we downloaded before:

Let’s change Memory and Cores to allocate to the VM (I also enable hardware acceleration to have nice visual effects in the VM; As specified in the checkbox’s documentation, this might give you troubles in some configurations):

And the storage of the VM disk. Remember that by default, not all the specified GiB will be used by the file of the disk image: the disk image file will occupy only the effectively used data by the filesystem.

For the moment, I won’t use a shared directory.

Here’s the summary, where you can also give a custom name to the VM:

OK, let’s start the VM; the first time, this will start the installation ISO:

Here we are in the VM. From now on, the installation procedure is basically the standard Ubuntu one. Here’s the list of screenshots:

Since that’s a VM, I select to erase the entire (virtual) disk; alternatively, you might want to specify your custom partitioning scheme, possibly with a different file system than the default one, i.e., EXT4.

The installation starts with the usual slide show:

Remember that by clicking on the small icon on the bottom-right, you’ll get the log of the installation:

After installation has finished, shut down the machine (instead of “restart now”) and “Clear” CD to avoid booting from the installation ISO again:

Now, start the installed VM.

As usual, you’ll almost immediately get updates:

If not already installed, you might want to install spice-vdagent and spice-webdavd for better integration with the host system (for example, shared clipboard and folder sharing).

Let’s see a few screenshots of the installed system:

Note the SWAP file created by the installer and the filesystem layout.

I’ve installed fastfetch to show the typical output:

Note the graphics (remember we selected above the Hardware OpenGL Acceleration):

Concerning the resolution of the VM, let’s consider the “Display” setting of the virtual machine:

Note the selected “Resize display to window size automatically”; that’s useful, especially when setting the VM window to full screen.

Concerning the display settings: “Retina mode” (optimize resolution for HDPI displays). Then you have to adjust the resolution in the VM.
The documentation https://docs.getutm.app/settings-qemu/devices/display/ suggests NOT to enable “Retina mode” because it increases memory usage and processing (and the host operating system can use efficient hardware scaling, while the guest uses software scaling).

Without this setting, the display will be presented at the current resolution and scale that the operating system uses. For example, here’s my macOS setting:

And in fact, as you see from one of the screenshots above, the Ubuntu desktop, when the UTM VM is full-screen, has the same 1280×800 resolution.

You might want to have a look at the special input settings:

The “Command+Option” is important to easily switch between the VM and the host OS concerning keyboard inputs.

First impressions

In general, the VM usage is very pleasant. Everything runs smoothly, including the visual effect. Indeed, it all seems to run at native speed.

WARNING: You’re running an ARM Linux distribution, so packages must be available for this architecture. Sad news: a few programs are NOT available for Linux ARM, notably Google Chrome and Dropbox. Please, consider that.

That’s all for this initial UTM post.

Stay tuned for other posts related to Linux virtual machines in UTM.

Switch SSD mode from RAID to AHCI (for Windows and Linux dual boot)

Leave a reply

On some computers, like the new Dell Pro Max Tower T2 and the old XPS 13, the SATA operation mode for the SSD is set to RAID by default.
Linux will not be able to see the SSD in RAID mode: you need to change it to AHCI.
If you just change it to AHCI in BIOS, Windows will not boot.

The idea is to boot Windows in Safe Mode once, then change the SATA mode to AHCI in BIOS, then boot Windows normally (it will automatically load the AHCI drivers).

WARNING: Do the procedure at your own risk!

The procedure can be found in many places online.
However, I decided to put the steps that worked for me here:

  1. Click the Start Button and type cmd; Right-click the result and select Run as administrator
  2. Type this command and press ENTER: bcdedit /set {current} safeboot minimal (If it does not work, use this alternative: bcdedit /set safeboot minimal)
  3. Restart the computer and enter BIOS Setup (in Dell, it is F2)
  4. Change the SATA Operation mode to AHCI from RAID
  5. Save changes and exit Setup, and Windows will automatically boot to Safe Mode.
  6. Do as in the first step to open an elevated command prompt.
  7. Type this command and press ENTER: bcdedit /deletevalue {current} safeboot (If it does not work, use this alternative: bcdedit /deletevalue safeboot)
  8. Reboot once more, and Windows will automatically start with AHCI drivers enabled.

Note that in the Dell Pro Max Tower T2 BIOS, you must enable the “Advanced Setup” (see the top-left corner) to be able to change the operation mode in the “Storage” section:

Here are the sources I used: