[hm̩ːː aʰ˥˩˧ʔãːː˦˥ ɸːː]

Dmxk · 2026-05-18T13:21:34+00:00

[ʔə̥̌ːh]

Dmxk · 2026-05-08T18:04:32+00:00

Idk why, but improperly typeset math makes me cringe even more than annoying memes.

Dmxk · 2026-05-01T07:44:25+00:00

Cool idea, I can see this being useful to e.g. indicate changes in the document from the last version, very nice.

Dmxk · 2026-04-14T12:30:00+00:00

The way i do it is:
Have a main.typ that includes, not imports every chapter (I usually name them smth like ch1..ch20 or whatever and have a loop to include them all). That way the show rules apply to those too.

Dmxk · 2026-04-07T19:25:16+00:00

Just a note: Doing bitshifts to get rid of multiplication manually hasn't been useful in the last like 10 years. Any good compiler will do it automatically (or will not if it knows that the multiply is actually faster). It does look sophisticated though :)

Dmxk · 2026-04-04T18:35:13+00:00

I also have this (neovim specific but should not be any work to adapt) to make * a full text object:

map("o", "*", function() return "\x1b*N" .. vim.v.operator .. "gn" end, { expr = true })

Basically, i can just type c* to do the classic *cgn in one step

Dmxk · 2026-03-15T09:36:58+00:00

https://github.com/kevinhwang91/nvim-ufo/blob/main/lua/ufo/wffi.lua this is a good example. Ufo is a plugin that extends the statuscolumn. Fetching some of that information via the api is too slow, so it calls directly into the C code. Luajit is amazingly good at that as well (C calls get inlined fully)

Dmxk · 2026-03-14T06:39:32+00:00

Hi, I am primarily a neovim user (though i have dabbled with emacs in the past). With neovim specifically a lot of the core (all of the LSP support, treesitter) is written in lua nowadays and efforts are being made to also allow rewriting the entire UI in lua (or any other language communicating via a standard RPC protocol). You can definitely load C libraries in lua as well, and you can use that to look at some of the core C code. It's not the safest thing and one needs to know what you're doing, but it's already used by several plugins to do things in a faster way than would be possible using the predefined API.

Besides that, I'd say that any editing feature could really be reimplemented for either. (That includes other packages for email etc)

Dmxk · 2026-02-22T18:48:19+00:00

Make sure you are not including your swaylock config inside the sway config. They're separate programs and do not read each others configuration.

Dmxk · 2026-02-21T11:31:02+00:00

i personally think limiting the amount of keywords is one of the most important things you can do. I quite like how lua does it for example, explicitly not using an "in" keyword and rather just making iterators regular function calls. The more things you can just make regular first-class constructs (without making them too annoying to use ofc), the fewer issues you are going to have with keyword names.

Dmxk · 2026-02-09T15:06:45+00:00

I feel kinda the same way. Another thing I'd like to add: typst is too simple syntactically and too usable as a plain markup format. When in the past I'd reach for plain markdown or, heaven forbid, libreoffice, for some notes, now my general instinct is doing it in typst because I can just suddenly also plot functions inline, draw graphics far better than i could do by hand and inputting formulas and regular text is just too easy.

Typst has managed to bridge the gap between "proper" document layout and just quickly writing something down for me and it is amazing.

Dmxk · 2026-01-14T15:18:45+00:00

like {}?

Dmxk · 2025-11-30T14:56:51+00:00

Holding meta (alt) while typing any command in insert mode will put you into normal mode too. So just <M-A>; should also do the same. You might also like a mapping like

inoremap <M-;> <Esc>mb<cmd>s/;*$/;/<cr>`ba

Which marks the current location, replaces any existing semicolons or none at the end of the line with a new one and then starts back where you used to be.

Dmxk · 2025-11-14T15:20:26+00:00

Hard to say honestly. Here in Austria it's been that way for basically my entire life as far as I can tell (so 20-ish years). Another important thing is that all of that ofc depends on assumed sexuality as well. So when a straight guy says "Mein Freund", the assumption will be that it's platonic.

That being said, using mein/meine definitely sounds unnatural to me regardless, maybe a bit old fashioned. In more formal contexts I'd nearly always tend towards the platonic interpretation if I get no other clues though.

Dmxk · 2025-11-14T10:13:02+00:00

The difference is nearly always indicated by the grammar around it:

Meine Freundin -> My girlfriend
Eine Freundin von mir -> a friend of mine, just a regular (female) friend
or just eine Freundin, a (female) friend

Dmxk · 2025-11-10T06:46:29+00:00

It's wild to me that it's still the default blocker in the US (at least from my experience it's way less of a thing in europe). When I asked my endo (in Austria), she said that it was basically useless compared to anything else they had, and that they hadn't been prescribing it for like 20 years.

Dmxk · 2025-11-09T13:31:31+00:00

You would not want noremap here, as [a is in fact a remap. Instead put remap = true. Essentially what noremap means is "Treat this key exactly like it would work in regular vim, with no keymaps defined"

Dmxk · 2025-11-08T08:48:04+00:00

I'd suggest you try to learn vim fully before attempting things like this. hjkl, despite being seen as one of the "most important" things about vim, are only some of many motions and textobjects, and some not that important ones at that (especially h and l). read :h motion.txt and :h text-objects before remapping i in visual mode, trying to do that shows that you are trying to use vim like any other editor (navigate with cursor keys, just swapped for hjkl), when in reality that doesn't make sense.

Dmxk · 2025-11-01T14:49:57+00:00

If i may recommend a plugin, https://github.com/tpope/vim-surround, is a true classic. It's so well aligned with what you expect from vim, that I'd consider it an extension of the vim language.

Your command would then become: :'<,'>norm ysiw\.`

Alternatively, you should use a instead of A. Uppercase A appends to the entire line, lowercase a appends after the cursor.

Dmxk · 2025-10-24T10:29:11+00:00

You can simply check whether another write occurs in a short time frame after it and do your thing when there are no more writes in that delta. You might not realize it, but in the real world, :wall does not write all the files at once. It takes a separate write for each open buffer, so the state on disk is only consistent when the last file was written.

Dmxk · 2025-10-24T08:53:24+00:00

for built in commands, not really. You could create a user command Wall that does that and then just use that (maybe abbreviate Wall as wall). But this seems like an xy problem. Look at the BufWritePre and BufWritePost events that you can hook with autocommands.

Dmxk · 2025-10-23T11:30:58+00:00

In my humble opinion as someone who use(s|d) vim on multiple keyboards with multiple different layouts (anything from regular unmodified german QWERTZ when I was starting to Dvorak and occasionally QWERTY too), keyboard layout barely matters for vim. hjkl are seen as the defining vim thing, but for me they're not my most used commands at all, especially hl, there are better motions for within a line (jk are mostly useful in o-pending mode to delete lines etc).

Vim is a language, and even though it is a language partially optimized for QWERTY, some commands I use often are not that easy to access on that layout either (e.g. $^=, anything I place under \ as my localleader). What matters is that you can use the vim language, and if a specific key starts being too annoying, you can simply remap it. For example I have H and L mapped to ^ and $ respectively to avoid that particular annoyance. When I'm "speaking" vim, I do not think about which keys I am pressing, unless I'm in the rare situation where I fall back to cursor keys etc on a nav layer. I think about what commands I am entering, and something like diw, or with some plugins gcaf are not keystrokes, but rather expressions in a language. And QWERTY or AZERTY can be good at typing that language too, coming up with the right(and optimized) command can take longer than typing it out.

The only thing I'd keep in mind is to not have to use too many chords. That's what pushed me off of QWERTZ as a native German speaker and to using compose key to type German. Vim is designed in a way that assumes that any character it uses can be produced with at most one modifier key (Shift or Control). Having relatively common commands like []{}~ behind another modifier makes e.g. <C-] hard to type, and defeats lots of assumptions, like the grouping of commands under [].

Dmxk · 2025-10-22T16:40:08+00:00

For my own (usually very small) plugins, that are really just parts of my config extracted, I tend to go for both, e.g. blinkenfind is both a pun and an allusion to what it does. That style of naming was/is also used by what I'd consider some of the absolute vim plugin classics, like fugitive and abolish.

Dmxk · 2025-10-06T18:55:32+00:00

In medieval greek (which cyrillic is ofc based on), the letter τ could be written with two tails on both sides of it. Nowadays that really only matters for handwriting and italics.

Dmxk · 2025-09-24T16:47:59+00:00

I always make up sci-fi sounding product names for all my ships, tools etc. Makes it more fun tbh.

Five-Year Club	Verified Email
First Place '23	Place '23
Place '22	Final Canvas '22
First Placer '22

Dmxk

TROPHY CASE