That's probably not going to happen as part of the core editor (there's a long discussion about this somewhere on the bug tracker) but should be easy to add using the now work-in-progress plugin system. Scroll down to the Examples section.
Funny how the maintainers preferred to build a plugin system instead of just the tree explorer, I suspect Helix will lose its biggest feature: no plugins and easy configuration :(
I used to use tree explorers all the time, but once I discovered fuzzy-search file explorers, I never used a tree explorer again. It’s been too long for me to remember why I liked tree explorers before or why I stopped using them, so I’m curious, what are the benefits of a tree explorer over a fuzzy-search file explorer?
I’m not questioning the usefulness or validity of tree explorers. I’m just trying to see things from a different perspective.
Tree-based finders allow you to explore a project.
Fuzzy finders only work when you already know what files exist.
Without a tree-based finder, you have no way to know which files exist in an unfamiliar project. Imagine being asked to change something in a project (e.g. add some extra space between two things on screen) without knowing what files existed. If you only rely on searching for names/terms that come to mind, you're probably going to miss the best way to accomplish the task at hand.
For discovering files in an unknown codebase I use the grep feature in Helix (or just ripgrep CLI). Way faster than going through a tree in most cases.
Tbh, I like having both, I find a fuzzy search is faster at finding what I want but a file tree is really helpful for building a mental model of directory relationships in a complex project.
I agree, these things seem to do okish on trivial web projects. I've never seen them do anything more than that.
I still use ChatGPT for some coding tasks, e.g. I asked it to write C code to do some annoying fork/execve stuff (can't remember the details) and it did a decentish job, but it's like 90% right. Great for figuring out a rough shape and what functions to search for, but you definitely can't just take the code and expect it to work.
Same when I asked it to write a device driver for some simple peripheral. It had the shape of an answer but with random hallucinated numbers.
I've also noticed that because there is a ton of noob-level code on the internet it will tend to do noob-level things too, like for the device driver it inserted fixed delays to wait for the device to perform an operation rather than monitoring for when it had actually finished.
I wonder if coding AIs would benefit from fine tuning on programming best practices so they don't copy beginner mistakes.
I used a web project in the demo because I figured it would be familiar to a wide range of developers, but actually many nontrivial pieces of Plandex have been built with the help of Plandex itself.
That's not to say it's perfect or will never make "noob-level" mistakes. That can definitely happen and is ultimately a function of the underlying model's intelligence. But I can at least assure you that it's quite capable of going far beyond a trivial web project.
It's also on me to show more indepth examples, so thanks for calling it out. I'd love it if you would try some of the projects you mention and let me know how it goes.
It seems like more examples demonstrating relatively complex tasks would be helpful, so I'll work on those.
I'm certainly not trying to claim that it can handle any task. The underlying model's intelligence and context size do place limits on what it can do. And it can definitely struggle with code that uses a lot of abstraction or indirection. But I've also been amazed by what it can accomplish on many occasions.
I do plan on having a "flow of a packet on a simple node". Working on an ingress and egress packet flow posts. These are rather large undertakings tho that require a post of their own IMO. Stay tuned for those :)
Yes, you are right here. It's always difficult to know how far down the tree of topics you should go to provide a end-to-end explanation. I tried to call this out in the start of the article. These are the "hard parts" of technical writing IMO.
I sometimes put a list at the top, like "This article assumes that you have a working familiarity with Linux namespaces (link to 3rd party intro to that), veth interfaces (link to 3rd party intro to that), [...]."
Not a bad suggestion, may even make the "pwru" analysis a bit simpler. Definitely worth playing with. You can even give it a try in the lab and lmk how it fares :).
The reason laid out in the article was for "jumping over the default linux network stack" to move a packet closer to its destination. I provide that just to hopefully help, ill have to read thru the article again to see how I can improve on making that clearer or defining more practical wording :).
And yeah, I understand your comments on all the naming spaghetti. I throw together these things so often that the convention used here are ones from my own head sprinkled with a bit of "iproute2" output format. Ill see if I can improve on this a bit moving forward. The explanation by another reply is correct :).
"jumping over the default linux network stack". What are the use cases. What are typical reasons to want to do that, what are benefits and downsides? What are the alternatives.
I really don't know, but the first thing that occurred to me was implementing a "bump in the wire" type firewall. IE, one that sits on the network transparently and can filter and log traffic without affecting layer 2 or 3 headers.
I have no idea if this is an effective and performant approach, but it sounds feasible. Same with implementing switching or routing functionality.
