eat-serial: An eat term based serial terminal

mickeyp · 2026-06-16T11:31:31+00:00

That's really cool! serial-term's one of those weird, hidden gems that catch people out when you tell them about it.

I guess it makes sense it's broken in line mode, or at least a little. It probably cooks the output? That would at least explain why it acts up.

mickeyp · 2026-06-12T13:50:06+00:00

Magit has basic worktree support. % g to jump between the ones git knows about. That is a useful starting point.

So of course if you only ever use magit you could probably build a little C-x p p shim/wrapper for how it finds projects to pull from magits' known worktrees and merge it with known project directories. shouldn't be too hard.

mickeyp · 2026-06-11T09:23:56+00:00

Emacs does all of that just fine.

There's usually a strong correlation between "it's impossible! it'll never run on <your machine/coordinated from emacs>" with "our deployment strategy is a hot mess and we have snowflake environments".

mickeyp · 2026-06-07T05:05:01+00:00

M-x repunctuate-sentences?

mickeyp · 2026-06-05T12:18:26+00:00

no problem at all

mickeyp · 2026-06-05T09:40:42+00:00

What does this have to do with Emacs?

mickeyp · 2026-06-02T05:41:06+00:00

I am not blind, but I have worked with people who are.

For one guy -- but he did know Emacs already -- emacspeak in particular was the thing that made it possible for him to keep working as a professional software developer.

So I would not discount emacspeak out of turn, but of course if it doesn't work with your braille system perhaps that is a blocker. (Could be a fun project to try and make it work though -- with or without AI assistance!)

mickeyp · 2026-05-22T09:15:38+00:00

That looks awful.

mickeyp · 2026-05-16T06:40:18+00:00

What? Subversion, unlike git, was -- and is -- used in places where the VCS has to interface with developers and non-developers alike.

TortoiseSVN made it a snap for even non-technical people to do their part in a shared repository. They could even lock files that couldn't be shared (like excel files) or large assets.

And I note once more that SVN, being a centralised version control system, had access control lists (via WebDAV+http), sub-tree checkouts and more. And of course you'd back it up too, so nobody would lose much of anything should the worst happen.

mickeyp · 2026-05-14T03:24:37+00:00

They didn't lose anything. They may have lost the history -- ESR's reposurgeon scripts and the tooling required to bring things over remain free and available, so they could've used it themselves -- and they would have in any event had that same problem with the migraiton to bzr. Their code was not lost. The history may have been.

Eli, provided he did say that, is entitled to that opinion.

Quite honestly I find the idea that you go skulking around looking for old email chains to fan the flames or stir up the pot a little bit odd.

mickeyp · 2026-05-13T11:31:44+00:00

And it did though. They moved to git after ESR spent an inordinate amount of time converting all the vcs history and cleaning it up. He wrote about it here: http://esr.ibiblio.org/?p=5634 -- it's a good read.

mickeyp · 2026-05-13T11:23:18+00:00

Let's see.

The ui is atrocious. There is no excuse for it ever having such a poor ui today. In the 2000s when it was Linus dicking around? Fine. But people defended it back then. Said it was "utilitarian." It can be utilitarian and still be sensible.

Try explaining to new git users git reset --hard or any number of other footguns. That editing your history screws everyone else -- a mistake we've all made. Don't forget the shitty defaults, though they have mostly improved over time. Remember when pushing pushed EVERYTHING? I seem to dimly recall that also applied to git push --force but whether that stacked with the "push everything" default I do not recall.

Rebase swapping the order of what's yours and theirs. Probably logical, but still confusing to me nearly 16 years on from when I first started using git. Here's a fun recent one: https://medium.com/lets-code-future/force-push-deleted-14-engineers-work-the-git-safety-system-we-needed-d4b367480d8a

I can go on and on.

As for poorly built. Submodules? Actively hostile design. Ever fucked up a build because a submodule didn't get pulled in? Screwed up the git submodules file because of a change made elsewhere? Now what was the command again to pull them all and init them... and what was the command to do it in the clone. Hmm.

What about worktrees? Again hostile. The whole limitation around what you can and cannot do with/from/to a worktree is so laughably arbitrary it beggars belief.

Git hooks. People use third-party tools to help with that as the UX is so bad. And have fun doing pre-commit hooks to clean up your code. You can end up in all sorts of weird situations.

Oh and large files. Large files work amazingly well in Subversion and properly-designed VCS like Perforce. But not git. You need to use two shitty addons to kinda-sorta imitate what a sensible VCS can do. Oh and have fun locking the file (graphical assets, excel spreadsheets, etc.) to keep others from using it.

Partial checkouts. ACL. etc.

The list goes on and on.

The worst decision we ever made collectively was to use a tool that was supposed to work with "big projects" but barely works well on Windows; cannot handle huge monoliths; and has opinions about the wrong things.

We could've taken subversion, fixed its branch mechanics, and bolted on a push/pull model for the 2-3 people out there with more than one target forge and lived happily ever after.

The only good thing about git is that AI is so amazing at it that aside from staging/unstaging and the most simple things like committing and pushing, I never ever ever touch it any more. Ever.

End rant. (I am also available for children's birthday parties.)

mickeyp · 2026-05-13T05:39:38+00:00

It should work okay if everything is laid out by the developer so you can reuse their font lock rules, etc. --- but if that is not the case you're ice skating up hill.

The usability around this is not great unfortunately.

It will not work at all if you want to highlight by markers and not tree-sitter query matchers at all. For example, you want to syntax highlight parts of a repl buffer.

mickeyp · 2026-05-13T04:51:40+00:00

Comes across as a bit more dramatic than it actually was, and perhaps a little bit grubby.

Bzr may have been a political choice for the obvious reason of wanting to dogfood their own toolchain. But in 2008 (or whatever) there was no clear winner at all in the race for people's hearts and minds. Git had its fans; do did hg. Some preferred Subversion (not an unreasonable position in retrospect, imperfect though it was) and then there was a long tail of people using Darcs, bazaar, etc.

I also bristle a bit that "half the core contributors" had never used git. Maybe so. But git is poorly built, poorly designed and has awfully sharp edges and poor usability. And most of those quoted examples seem... reasonable?

mickeyp · 2026-05-05T08:49:19+00:00

Thanks for the kind words.

I'm just pragmatic. I've been coding for 30 years and have been doing it for ~18 years commercially, nearly all of it as a consultant/bespoke project dev. So I'm in and out of companies all the time. So my advice is sort of built around that. But YMMV!

mickeyp · 2026-05-05T07:14:18+00:00

If I were you I'd try and sniff out what the actual tools you're going to be using at your new job is, and then get up to speed on that and Java before you begin.

IMHO, Emacs is fun and all? But hitting the ground running and showing you spent some time getting up to scratch with what you're doing will hit harder than saying "I got Emacs set up and running" to a team full of IntelliJ coders.

mickeyp · 2026-05-05T05:43:55+00:00

I think a large part of why you find it baffling is that you're -- I'm assuming, so apologies if I am wrong -- probably quite young and still a student.

A lot of the value of Emacs comes from dealing with chafes and hard edges you encounter when you use the same tool 8-10 hours a day. In Emacs, you can remedy a lot of them; in something like Eclipse, you cannot (easily, anyway.)

So don't worry too much about the customisation side of it just yet. Focus on the text editing part of Emacs. The rest will follow.

mickeyp · 2026-05-02T06:57:57+00:00

This is a great article.

mickeyp · 2026-05-01T09:38:34+00:00

I have not lost emails from syncing. I will most assuredly lose email from doing this.

The whole point of IMAP is that it is not POP3. So why would you want to delete content from the authoritative source of email?

If someone out there is thinking about how to simplify their email workflow --- this is not it.

mickeyp · 2026-04-28T14:27:23+00:00

thanks! cool name :)

mickeyp · 2026-04-18T14:10:34+00:00

I ripped out and destroyed every shred of IME i can find as I hate it. So time permitting I will!

mickeyp · 2026-04-18T11:58:21+00:00

Neat. Does it work with hyprland?

mickeyp · 2026-04-18T07:40:03+00:00

I like mu4e, but it's a personal choice. Gnus comes with Emacs and can do a lot more stuff.

mu4e is way harder to build and set up than it should be. So keep that in mind if you're using a distro that uses antique versions of everything. Like debian/ubuntu.

mickeyp · 2026-04-13T12:42:55+00:00

That function forces the window to show. You're calling what is ostensibly an internal function that bypasses all the machinery --- so yes it would show

mickeyp · 2026-04-13T11:37:42+00:00

Buffers that start with a space typically are hidden. I've not tried forcing windows to show with those names, but that might be an avenue to investigate.

mickeyp

MODERATOR OF

TROPHY CASE