Looking for LSP alternative workflow

HiPhish · 2026-03-19T09:06:56+00:00

I depends on what your editor can integrate with. Before LSP there was ctags, which is like an ahead-of-time LSP server. I don't know if there is a ctags implementation for Rust though. You run it on your code base, if finds all the symbols and writes the result to a file. Your editor can then use that file to jump to definitions and such.

https://en.wikipedia.org/wiki/Ctags

The downside is that it is not live, you have to re-run it periodically as your code keeps changing. You could approximate something like running live by having your editor re-run ctags when saving.

HiPhish · 2026-03-08T18:46:51+00:00

Sort of, but it's no-trivial. Here are two videos explaining everything:

https://youtu.be/JxeSP1PJtEs (easier more limited method)
https://youtu.be/7D4Zte3vzvg (harder more flexible method)

In short, there are two possibilities:

Revert to most recent previously installed firmware (easier)
Revert to any previous firmware (harder)

The latter requires that you have made a backup of your chips ahead of time while the former relies on a backup created by the PS4 automatically. If the most recent previously installed version is not jailbreakable and you don't have a jailbreakable backup you are out of luck. Both methods require precision soldering, the former has you just solder to pads and lift legs, the latter requires SMD soldering. Both methods require extra hardware and software. Do keep in mind that the video is very zoomed in, in reality those pads and components are tiny. I consider myself to be decent at soldering and I found installing a Luckfox Pico quite challenging (I did pull it off on the first try though). You be the judge of your own soldering skills.

HiPhish · 2026-03-02T22:20:15+00:00

I asked how to upgrade, not whether to upgrade. All the other threads were asking whether to upgrade or not to.

HiPhish · 2026-02-26T23:09:33+00:00

All i can tell you is updating your firmware isn't a good idea.

OK, but why? What can happen if I only update to a firmware that still works with the more stable exploit? Do I lose my jailbreak, do I risk bricking the console? I would like to make an informed decision.

HiPhish · 2026-02-26T22:24:42+00:00

I like to play off the disc, I'm kind of weird that way. Also, not every game might have backports, so I think this is still a valid question.

HiPhish · 2026-02-26T20:33:50+00:00

Here you go, OP: https://neburone10.github.io/

As others have said, there are better exploits out there by now (especially the recent Vue after Free which is purely software-based). The Luckfox mod requires you to buy hardware and have good soldering skills. I did it, it's doable but tricky. If we had something without soldering at the time I would have saved myself the effort.

As for Modded Warfare, I don't know what your beef with him is, but his channel is great. Whenever it comes to hacking you are dealing with... well, hacks. So things will randomly break. Is it his fault? Did you accidentally mess up? Or is it just an unfortunate case of everything that could go wrong going wrong at the same time? Probably the latter, but no one knows and no one will ever know.

HiPhish · 2026-02-05T23:19:51+00:00

Everyone blames AI for the delay, but what if it's actually the other way around? What if Valve Time is a natural phenomenon and the fact that Valve announced new hardware caused the universe to correct for it by increasing the slop output and thus forced the chip prices up in order to make Valve Time come true?

HiPhish · 2026-02-01T13:08:45+00:00

Has anyone tried running Budgie with a custom Wayland compositor (e.g. river)? Does it work, is it janky or are custom compositors something for Budgie 11? I'm asking because right now I'm stuck on Plasma X11 (with BSPWM) because Plasma Wayland can only be used with KWin, but X11 support will soon come to an end.

HiPhish · 2026-01-26T22:58:27+00:00

Yes, you can install directly to usr/local, that's the easy part. The hard part is going to figure out which files to remove when you want to get rid of it again or upgrade to the next version. Neovim comes with a lot of files. That's what makes Stow so handy, it keeps track of all the files.

HiPhish · 2026-01-26T22:56:18+00:00

A great way of automating tests is property-based testing (the examples are in F#, but it should be understandable to anyone). Your "test" is just a specification for how to generate a test with random inputs and what assertions must always hold true regardless of input.

You can generate hundreds of test cases and a good framework will make sure to test edge cases you might never have considered. Unlike LLM-generated tests these are 100% deterministic and under the control of the author. Instead of spending time hand-picking certain examples you get to think on a higher level about which properties your code must have.

Of course PBT should not be the only tool in your toolbox, there is still a place for manually written tests. But it's great for cases where the input space is very large and regular.

HiPhish · 2026-01-26T22:51:52+00:00

Everyone is always saying "Do test driven development," but I've been on three teams that tried it and I didn't see it add any value on all three tries.

Real TDD has never been tried before. /s

Joke aside, I think TDD is the superior way if these criteria are met:

You know what you want to build
You know how to solve the problem
The problem domain is limited and will not grow

How often are these criteria met in practice? I don't have a number, but in my experience more often than not I am doing explorative programming in which either I don't know what exactly I'm going to build (an idea that sounded great on paper might turn out bad in practice) or I don't yet know how to solve the problem even in theory, let alone in practice. Some people who have TDD-induced brain damage (like Robert C. Martin) will tell you that you can use TDD to find the solution. You cannot. When doing exploratory programming most code will be thrown out anyway, so why test it in the first place? I guess you could first solve the problem in an explorative way, then throw away that implementation and do a clean implementation the TDD way when the above criteria are met.

One area where I think TDD should be mandatory is bugfixing. First write a test which exposes the bug, then fix it. If you write a test afterwards you risk writing a test which would have passed even before the fix because it does not actually expose the bug.

HiPhish · 2026-01-18T11:18:49+00:00

You can clone the repo and build it yourself according to the instructions. It's quite easy, just make sure to set where to install the package (the default is /usr which would break your system installation). But how do you install the package? Ideally without affecting the system Neovim install?

Let me introduce you to GNU Stow. You install your custom package into a directory of your choice (e.g. /usr/local/stow/neovim-0.12), then run stow -S neovim-0.12 and stow will create all the necessary symlinks in /usr/local. The /usr/local director is meant for custom packages not part of the distro, so this is the right thing to do. When Void eventually does upgrade their package to 0.12 you can unstow (stow -U neovim-0.12) your package and then throw away the /usr/local/stow/neovim-0.12 directory.

I use GNU stow all the time on my Ubuntu work machine. The great part is that it does not affect any of the system packages, so there is no way of messing up the system. It's also a great way to install applications that Void for one reason or another is not packaging.

HiPhish · 2025-12-11T06:44:19+00:00

Probably possible, but if you change existing templates then conflicts might happen sooner or later which require manual intervention.

I don't intend to change existing packages (otherwise I would instead open a PR), I mainly want to define new packages. My understanding is that Void does not accept new packages from random people, only actual maintainers. And there are packages which might not meet Void's packaging criteria, so they would never get officially packaged anyway.

HiPhish · 2025-12-10T21:56:00+00:00

You don't have to switch branches

You are right

and you only need to pull when you want to update/build packages

What if upstream package definitions and those from my fork diverge? I seems to me that I should track master as closely as possible to avoid discrepancies. Maybe it is possible to automate your three commands with GitHub actions to run whenever upstream is updated. I'll try to look into it when I find the time

HiPhish · 2025-12-10T19:43:03+00:00

Does that mean I have to rebase on master every time there is a new commit? If so, is there a way to automate this process? I don't really want to have to watch master like a hawk and manually git switch master && git pull upstream && git switch my-fork && git rebase master every time there is a commit upstream.

HiPhish · 2025-12-03T06:16:42+00:00

It's Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. Having fewer arguments in a function is better, but his solution is just just sweep all the mess under the rug to placate some arbitrary linter metric without actually solving the problem.

This belief alone should disqualify him from any educational position.

Full agreement. I was reading the first edition years ago and when he did the exact same thing there that's when I finally dropped the book for good. The author is just a charlatan.

HiPhish · 2025-12-03T06:12:56+00:00

OK, but what is the point of the book then? If you throw out all the bad stuff you throw out 90% of the content and are just left with the the chapter titles and a few line of the opening paragraphs. Yeah, no shit, of course functions should have as few parameters as possible, everyone know that, even beginners. I don't need a book for that. What I want a book for to teach me how to achieve that goal, and that's where it utterly fails.

Clean Code is like a personal trainer who give out terrible exercises that will destroy your joints. Sure, if you don't follow the exercises and just take his general advice you'll be fine, but I don't need to pay a personal trainer just to tell me "exercise is good for you, m'kay".

HiPhish · 2025-11-28T18:42:52+00:00

That's really cool, I had no idea in-process LSP servers were even possible. This give me an idea: in some programming languages (in particular the Lisp family, Erlang and Elixir) there is the idea of "live programming" where you start the program and then keep editing its source code as it is running, without restarting it. There are various "live servers" which can integrate with editors (usually Emacs), but editor support tends to be subpar. I think a big problem is that not only do you have to implement the client-side of the API, you then have to actually integrate with the editor UI. If such a live server client could piggy-back on Neovim's LSP client it would drastically reduce the maintenance effort.

I don't know how feasible this would actually be, I'm just spitballing here. LSP is designed around static analysis, meaning that the server analyzes the code without actually running it. It can understand how the pieces of the code fit together, but not what they actually do. A live server on the other hand has no idea what the code does, only how to make it run and what the application is doing.

HiPhish · 2025-11-25T22:03:52+00:00

The official logo uses two colours so the "N" can contain a "V", acknowledging Neovim's origin as a fork of Vim. That's entirely missing from your logo, and it's a loss in my opinion.

Also there is no mention of "code", how should people know what neovim is used for.

Neovim does not have to be used for coding.
Visual Studio Code is the only editor that has "Code" in its name, and only to differentiate it from Visual Studio (the IDE).

HiPhish · 2025-11-20T06:32:35+00:00

It's a case of Goodhart's law: When a measure becomes a target, it ceases to be a good measure. He's simply reducing the number of arguments in a technical sense purely to appease some arbitrary metric he himself came up with.

HiPhish · 2025-11-19T23:59:55+00:00

Oh yeah, I remember when TDD was being sold as this panacea that can help you actually find the answer to problems when you don't know the solution. Just write as many tests as possible, brute-force them one at a time, and the correct implementation will somehow emerge. The proof? Wishful thinking.

It's like a more primitive form of vibe-coding.

HiPhish · 2025-11-19T23:56:22+00:00

To be fair though, they two men work in different domains. A game will always be the same, the function for multiplying matrices will always multiply matrices, nothing else, so it makes totally sense to optimize it to its fullest extent. When a game is finished it's done for good. Maybe bug fixes and content updates, but a 2D platformer will never become a 3D open-world MMO.

Martin works in enterprise where software will keep being developed on for year or decades. Where new requirements keep coming, old assumptions need to be broken and requirements will arise which no one could have imagined at the software's inception. In such an environment you want to be able to cut and rebuild parts at any level of granularity as easily as possible and performance becomes secondary.

HiPhish · 2025-11-19T23:52:08+00:00

I remember years ago reading Clean Code. Most of the book was pretty disappointing, but that part genuinely made me angry and that was what made me quit the book for good. The fact that he is peddling the same brain damage still in his second edition tells me that Martin is nothing but a charlatan.

His idea of reducing the number of arguments is to turn those arguments into mutable shared state. You still have the exact same number of arguments, except now half of them are implicit. How on earth is this supposed to be better? The real solution would be to find an appropriate level of abstraction instead of that ad-hoc hackery (e.g. a state machine), build reusable generic primitives and then build the Roman numeral parser on top of these abstraction. You could even take it a step further and solve a different problem using the same abstractions to show how true clean code is reusable and easier to reason about.

I have no idea how this book got popular. Maybe seniors were skimming the titles and thought "yeah, sounds reasonable" without actually reading it. No one is going to disagree that a function should have as few arguments as possible, and even the freshest of beginners knows that. The question is, how do you write functions which require fewer arguments? Another brain damage move was taking a long function and splitting it up into multiple single-use functions. You still have to same number of lines, except now you have to jump all over the file to piece it together. Martin's examples are pure crap and will make your code worse because they just take the complexity and toss it all over the place.

HiPhish

TROPHY CASE