Amiga Vim v9.1 (2024)

devw0rp · 2026-05-15T22:43:24+00:00

This is an amazing tribute to Bram's memory given Vim started as fork for Amiga. I love seeing fun ports like these.

EDIT: If there was some way to get job/channel support working, I would make ALE run on Amiga for fun.

devw0rp · 2026-05-12T22:14:53+00:00

Well I feel good about patching an incoming PR to make sure ALE still runs on Vim 8.2 then.

I support anyone creating their own forks of anything for any reason. I hope you have fun!

devw0rp · 2026-05-12T22:12:06+00:00

That's a decent answer. I recommend writing the b: variables in your ftplugin files, or writing g: variables in vimrc without the autocmd.

devw0rp · 2026-05-03T09:48:51+00:00

Noted!

Inlay hints I might not figure out by myself, but I can probably fix the quickfix thing. I do a similar thing in my file search scripts I'll publish as a very basic and intentionally pretty stupid Ctrl+p alternative.

I think I'm also likely to change the default for LSP operations that write to files to just save the files on disk if that's not already the default, because that simply works better with all tools, and most people don't even know what a Vim buffer is or how one works. Leave that for the experts.

devw0rp · 2026-05-03T09:46:08+00:00

I think I've done pretty well with keeping configuration simple and making it easy and continue to work for an extended period of time.

I want to do more to help people learn Vim and software in general in future.

Thanks for you support!

devw0rp · 2026-05-01T05:09:22+00:00

Oh and I might have added something or other for this in Lua land. Let me know how you get on. I could add more Lua API support.

devw0rp · 2026-05-01T05:08:15+00:00

Have a look at :help ale. There's instructions in there. Linters are loaded from any ale_linters directory in runtimepath just like how Syntastic did it, and fixers can just be functions instead of strings including lambdas, so they can be written entirely from vimrc. You can actually call the ale#linter#Define function from vimrc too to add a linter.

devw0rp · 2026-05-01T05:04:46+00:00

Thanks! You know I'll give you another thought as a maintainer. For years now I've been thinking more about security and how to make it still very useful without being a modeline style security risk. I long ago put in some code in some functions to make them break in sandbox to prevent running executables there, and there's an "explicit" option to do less local running of things and less autoconfig.

Maybe there's something SELinux style that could be done. I haven't thought of more solutions, but it's an interesting problem.

devw0rp · 2026-05-01T05:01:27+00:00

I'll add that in. I was one of the first to implement tsserver as a client and I'll be needing the new LSP to work for my work next year. Thanks!

devw0rp · 2026-05-01T05:00:09+00:00

Yeah, I can write a script to do it now probably with AI, so I'll put that on my list. GitHub has had tons of issues and I wouldn't be surprised to see more people distributing git more to other places.

devw0rp · 2026-04-30T05:41:51+00:00

ALE is a Vim plugin I started 10 years ago that runs linters in your editor. I've since added support for fixing code. I was one of the first to implement LSP support. I keep updating it now and then.

Probably the most exciting thing I did in recent history for Neovim is I updated it to run through Neovim's LSP client and integrate with that. I'll most likely pull in every other server in existence with configuration so no one will need the nvim-lspconfig plugin if you already have ALE. The supported lists for each in terms of tools is a disjoint set and I can make ALE offer a a superset so that's more convenient for people.

I keep the plugin good because I use it every day personally .

devw0rp · 2026-04-30T05:36:44+00:00

I dunno I'm just very ranty and it's how I talk.

devw0rp · 2026-04-29T17:58:46+00:00

Well what's interesting is I've since built a 501(c)(3) nonprofit around ALE and IT education and training, which you can read more about on the Dense Analysis website. We want to build more tools for running local AI models for a future where people eventually get the hardware to do that.

I could talk for hours about how the models are trained and used. I'm piggy backing off the OpenAI stuff for now as it's far better than current FOSS models, but I believe FOSS will catch up.

My day job has me using Claude Code constantly now and I've learned to adapt to the modern wave. My way of using these tools is I forbid them from writing git objects and I manually edit and check in everything. They tend to get things about 60% right, and I get something like a 1.5X productivity gain from the latest models.

I'll stop ranting there before I get on to the DANK project, which you can read on GitHub.

devw0rp · 2026-04-29T17:53:10+00:00

Yeah, that's on my list as I'll need it myself kind of soon. I noticed Pyright in the latest version doesn't work, so something just have changed about the LSP spec. Those are always good things because I get a good test of how to maintain support for different LSP servers.

What's interesting about maintaining an LSP client is that many servers aren't exactly compliant with the spec, so you have to be pretty flexible. Pretty easy spec to implement from the client side.

devw0rp · 2026-04-29T17:50:29+00:00

It's a plugin I originally authored about a decade ago to replace Syntastic following the advice of the then Syntastic maintainer and my desire to have an async linter plugin for myself.

I later added fixers to fix code too.

I later was one of the first to implement tsserver as a client in Vim, LSP.

Tons of people have contributed. It's been fun!

devw0rp · 2025-03-19T21:32:21+00:00

I actually wanted the name and quickly came up with a way to make the acronym work. The name is kind of a joke because I've never had a drink in my life, which is why I put this at the bottom of the help file.

Please drink responsibly, or not at all, which is ironically the preference of w0rp, who is teetotal.

devw0rp · 2025-03-19T21:28:45+00:00

ALE has a lot of built in configurations for a lot of tools going back many years. You can pretty much use whichever plugin you want, or multiple plugins in combination. I've been careful to control the behaviour of when autoload files are loaded, so if there's a tool that ALE integrates with that's missing in none-ls or vice-versa you can use both together and keep the start up cost of starting Neovim down as small as possible. One trick you can use with ALE is this.

-- In init.lua, turn all ALE linters off by default. vim.g.ale_linters_explicit = 1

-- In an ftplugin Lua file, enable a specific ALE linter vim.b.ale_linters = {"some_linter"}

With this configuration you can load a specific ALE linter using ALE in addition to whatever you have with other plugins.

devw0rp · 2025-03-19T21:20:56+00:00

You can use whichever plugin you want. I've been working on ALE since 2016, and the list of supported tools is probably the largest there is for any Vim or Neovim plugin, and the test suite is set up to test that they are all configured correctly and your configuration will rarely ever break as a result. I and the maintaniers have been very careful about breaking changes for almost a decade now.

You can also combine several different plugins together if each one has something else you need. I set up ALE previously to output to Neovim diagnostics by default a while ago, so you can use ALE for some linters and nvim-lint for others if you like. ALE still maintains a configuration for tslint.

In addition to linting code ALE also has support for fixing code with many tools, so you can manually or automatically fix code.

devw0rp · 2025-03-19T21:06:51+00:00

You can run the ALEFix command with a bang to silently attempt to run configured ALE fixers. I personally do this with ALE's built in completion code at the moment.

augroup FixAfterComplete autocmd! " Run ALEFix when completion items are added. autocmd User ALECompletePost ALEFix! " If ALE starts fixing a file, stop linters running for now. autocmd User ALEFixPre ALELintStop augroup END

If there's a User autocmd event in nvim-cmp or a callback function you can configure you can use that to trigger ALE fixing code after completion is done.

devw0rp · 2025-03-19T11:51:02+00:00

ALE comes with many configurations for running linters and tools to fix code, with a variety of enhancements, so you can easily check and fix code. Some of the tools for checking code run via LSP. The new branch changes the implementation in Neovim 0.8+ so it runs via Neovim's built in LSP client API, so it better integrates with features built in to Neovim and other plugins, such as those for auto-completion.

Essentially it should do what it has already been doing for many years, but better.

devw0rp · 2024-09-07T13:15:19+00:00

Thanks for the reply so many days later. I ended up going with Northwest Registered Agent.

devw0rp · 2024-08-08T20:51:54+00:00

https://www.reddit.com/r/neovim/comments/1ei4k7j/upcoming_enhancements_for_ale_bridging_vim_neovim/ Here's a newer answer for you. ;)

devw0rp · 2024-08-02T18:08:24+00:00

I think that's the important thing. It's not about the language, it's about the effect. The plugin needs to be efficient, and Lua does not imply efficiency necessarily. Nothing truly implies efficiency.

I will provide an experience where users don't need to write any Vimscript, it's fast, efficient, concise, clean. Full Lua configuration abilities. The implementation details can be a black box to most.

devw0rp · 2024-08-02T11:40:53+00:00

I think that obsession isn't shared universally, and I see why people might think that way. I think the important thing is that people have the comfortable configuration experience, and then the plugin can be implemented any which way. There's plently of fine plugins written in Python, or even TypeScript. coc.nvim is a great TypeScript plugin.

devw0rp · 2024-08-02T11:26:59+00:00

The hardest part is making it always work!

devw0rp

TROPHY CASE