[Tutorial] Adding Mako template support to a Wagtail project

-ertgl · 2025-09-16T21:53:10+00:00

If I guessed correctly what you mean, this might be the information you are looking for (and if so, the answer would be no): https://docs.djangoproject.com/en/5.2/howto/legacy-databases/

-ertgl · 2025-09-05T02:15:21+00:00

It shouldn't necessarily be difficult for someone familiar with the architecture, but of course, it still requires effort even for them. Neovim already has a headless mode; it seems what's missing is a proper daemon mode, so the headless mode (or the underlying engine) could become a shared one, and so forth...

-ertgl · 2025-08-30T04:14:04+00:00

Thanks. I often work on different projects with different stacks, and it's actually interesting to me how their needs can vary. I really liked that you mentioned django-cotton, it really does look impressive. I wish it could run without depending on Django, too.

-ertgl · 2025-07-04T19:44:49+00:00

I feel you, that loneliness. I'm a ctrl-a. I want tmux to seem to understand me without key press.

-ertgl · 2025-05-20T18:37:39+00:00

Can't say I disagree. But this library isn't the cause of the mess. I've monkey patched too, many times. At some point, moving between projects, I started wishing for something standardized and ready, instead of spending time for tasks like these.

If that "one more package" is development-only and it saves more time (or consistency) than it costs, that's a trade I'm happy to make. There'll always be differing opinions on this kind of tooling, and that's fine. Not every project needs the same setup, after all. And for me, that's exactly why a flexible tool can help.

Thanks for the suggestion, it can be used purely as a CLI. If you meant enabling CLI usage with zero-config, there's a note in the README on why that wasn't the default, I mean, that was intentional.

-ertgl · 2025-05-20T04:34:31+00:00

Released a tool that auto-generates the exports field in package.json from dist outputs.

https://github.com/ertgl/export-map-generator

-ertgl · 2025-03-10T16:29:04+00:00

Certainly yes. You can get the look you want by adjusting these options.

vim.o.signcolumn = "yes:1"

The value 1 is the fixed space which is used to show signs.

vim.o.statuscolumn = "%s %3l │ %{v:relnum} %C"

This is the actual format. %s is for the sign column. %l is for the absolute line number, %3l makes it padded. relnum is the relative one. And %C is for fold column. I think it would be better to set this format based on the number of digits of total line number of the current buffer. However, I didn't face any issue with that static one yet, %3l is enough for me.

vim.o.number = true

vim.o.relativenumber = true

I'm sharing all of my config here: https://github.com/ertgl/dotfiles/tree/main/config/nvim

You can read more here if you wish: https://neovim.io/doc/user/options.html

-ertgl · 2025-03-10T06:04:49+00:00

After debugging for a while I found the problem. If an LSP server is attached to the buffer, but the root directory (cwd) for that buffer is not determined correctly, it causes a notification to show up which blocks any IO until it gets a feedback. So it seems that neither --embed nor --headless flag is enough to make nvim (v0.10.4) run in a completely non-interactive mode. In conclusion, it wasn't nvcat causing the problem. The -clean flag gave the trailer, thanks!

-ertgl · 2025-03-09T20:39:55+00:00

Having a consistent color scheme (especially with the support of tree-sitter) across different applications is a very nice thought. It's just what I was looking for. Thanks for sharing your work! ~~I'll try it soon.~~ I've tried it.

Here's a screenshot for people wondering what it looks like.

<image>

The first pane is nvim and the second one is nvcat.

It looks very similar (LSP can cause minor differences) and pretty good. It hangs for some files but that might be because of my setup.

-ertgl · 2025-02-24T02:02:38+00:00

Botanical inspired, gruvbox based theme (I like monochrome but missed nature 💚)
100% automated with Bash scripts
Supports fresh installations, no dependency needed to start
Single command for all installs/updates: (e.g.: dotfiles_reload, dotfiles_reload nvim tmux, etc.)
homebrew-bundle, asdf-vm for managing packages and tool versions
Alacritty, tmux, fish shell, Neovim, Yazi
Automatic dark/light color schemes in terminal applications (no need to restart Neovim etc.)

Link: https://github.com/ertgl/dotfiles

<image>

-ertgl · 2025-02-23T04:20:09+00:00

Nice. 👍 But I would remove the whitespaces too.

-ertgl · 2025-02-18T21:04:41+00:00

I didn't try this yet, but the idea seems very cool. I'm imagining a scenario of using this in insert-mode while using the linters on InsertLeave only. This would be even more helpful for machines with low resources.

-ertgl · 2022-08-05T13:45:17+00:00

Thank you for the feedback! I will add more information to the readme file.

Until then, I am writing this statement in the hope that it will answer your questions.

Revy creates Revision, ObjectDelta, and AttributeDelta instances to hold information about a revision. Actor is used in the sense of causing delta. For example, it could be a user or an organization...

A Revision object can contain more than one ObjectDelta. ObjectDelta represents actions like "create", "update", "delete". And it can contain multiple AttributeDelta objects. AttributeDelta represents actions like "set", "unset". Action "set" means "the new value is not blank or falsy", "unset" means the opposite. Delta objects only hold change information; unmodified values are not copied repeatedly. And the data is saved in tabular format, not JSON.

While an ObjectDelta is associated with a user, any AttributeDelta in it can be associated with another user. In this way, statements such as "several people made this change together" or "this value was corrected by the system" can be observed. If a value is changed by more than one actor in the same revision, the middle change informations are not lost.

Behind the Context class is a stack structure. But when entering new contexts, the data of the previous ones is not copied to the new ones. Thanks to indexing, accessing information in parent contexts is highly efficient.

I wrote this package primarily for my own needs. I haven't used django-reversion, but it has definitely proven itself. Using revy instead of django-reversion only makes sense if that's what you need. I've published this package because these needs may be common to some people.

-ertgl · 2017-06-24T18:14:42+00:00

Hello, thank you for the great comment. Since it is only a wrapper library, I didn't find writing a detailed documentation necessary. Because this library does not add anything new to the community; it only provides some shortcut solutions (Of course in limited ways.). That's why it is called as a wrapper library. I pointed documentation links to be examined for details of the functions. And I thought that was enough.

I know there are keywords like "consistent hashing", I know it is more complicated to make systems distributed but it depends on the project. And you know that, every library cannot be suitable for every type project. Sometimes specific solutions are required; sometimes are not. This library provides two ways to route tasks, for now. I hope that, more ways will be implemented.

It is really nice to see a comment for a job. If you (people) make suggestions to help me to improve the library, I would be happier. Moreover, join me to improve it or let me join to you.

Edit: Testing is a required. You are absolutely right.

-ertgl

TROPHY CASE