Feature Request: Thoughts on views & buffers, search & navigation

Hey all,

thanks to the reddit hype around direct AST editing these past couple weeks, I've been thinking. That's a lot of time to spend thinking, so let me first apologize for the incoming wall of text. I promise it's going to make some sort of sense by the end.

The feature request
Essentially, I came up with a feature I didn't know I wanted until thinking about how to implement something like Stride for Go (that's a whole other can of worms I am not going to touch on today). The idea evolved kind of like this:
  1. Since we're working with ASTs, we don't need to address code snippets by file_name:line_number anymore.
  2. When opening file_name:function, we don't really need to show the entirety of the file, just visualize that one function node.
  3. Many IDEs have a window showing all files, and, hierarchically, all top-level code elements inside them. You rarely ever need to view that and the code at the same time, but something like that should be accessible quickly, as a means of navigation.
  4. Since we have an AST in memory, we can perform intelligent searches, like 'list all functions that call this function', or 'all functions that take this type as an argument', ...
  5. As an implementation detail, you can probably reuse a lot of code between the project explorer and the search results.
  6. Why not just combine those two with the actual code view? Just use code folding to make search results easier to skim.
At this point, we have a powerful navigation feature, that is similar to what we see in Eve, where we're only viewing the code we care about at the moment. You can dream up lots of use cases here, e.g. a documentation-like view that lists a struct at the top, and functions taking a pointer to that struct after that, with only the functions folded by default. An AST-query language, so you can do arbitrary searches without having to code them up and restart the editor. A browsing history that treats queries like URLs.

Obviously, this wouldn't really work for 4coder - except you could simply replace top-level AST nodes with partial views into a buffer and multiple views concatenated in each window (hopefully with some sort of separator to make this obvious).

I realize this is a pretty involved feature request, as it probably touches a lot of existing code in 4coder, but I believe there previously was talk about code folding, as well as "zooming in" on a scope, only leaving multiple snippets per view. I also realize that this probably isn't quite as useful as I imagine it, as long as 4coder lacks the language-awareness to easily make context sensitive key-bindings and intelligent search possible.

Any thoughts?

On a related note...
With 4coder becoming more and more language-aware (and generally awesome!) these past releases, I dread the day Jonathan Blow's JAI is released, because I will almost certainly switch immediately. 4coder is awesome, and I would love utilizing all of its power when working with a better language.

Have you ever considered splitting the language-specific code into its own dll, so that we can have a separate one for JAI? To me, that seems like the easiest way to allow support for another language.
Few years ago there was Light Table editor on Kickstarter: https://www.kickstarter.com/projects/ibdknox/light-table

As one of features it promoted that smallest unit that could be open and manipulated separately should not be a file (like most editors do). It should be a function, so you can open each function in separate window/"tab". Not sure how well it is implemented.

Here's a video demonstrating it: https://vimeo.com/40281991

Edited by Mārtiņš Možeiko on
Thanks for the feature request. That's actually more like a 'paradigm request'. My plan is to keep building in that direction incrementally and hopefully discover the best way to leverage code intelligence by a 'survival of the most useful' selection system. Your suggestion may very well resemble where it ends up but for now the future of code intelligence is still a bit of an amorphous blob of possibilities, not all of which go together.


I'm also concerned about the potential, coming JAI transition. The real issue there is that I'm not making a language agnostic code intelligence system. It is not clear to me that if I really want to go all the way with C/C++ intelligence, that I can allow myself to think 'would this same operation apply to <arbitrary language>?' I do think I need to organize sometime soon though, so that at the very least I can maintain multiple code intelligence systems. I'll be taking a look at this particular issue in the not too distant future.

Thanks for your post!


Thanks for the quick reply!

The video linked by mmozeiko (around the 3:00 mark) is actually pretty close to what I imagined. But I guess I rambled on for so long I missed my own point. What I'm really asking for is the ability to have multiple buffers below each other in the same view. Once code folding and other code intelligence is there, this paradigm shouldn't be too hard to implement in the customization layer.

Still, thanks for considering this.


As for language support, I'm glad to hear that you plan on doing that!

I tend to agree that having language-specific code intelligence will provide more powerful options, but I haven't giving this topic as much thought, so I'll refrain from making suggestions here.
I have been thinking that perhaps an interesting way to go about these sorts of things is to make the "file" API in 4coder be something that goes through the custom layer (optionally). Eg., the box where you type filenames in would actually call through to a user-defined function, and the resulting options that match that search are provided back to 4coder by the function. Then open/save/revert all go through the API.

This way, if someone _did_ want to make a database-like function server, they could write one themselves and 4coder would work with it, without actually having any new functionality in 4coder at all.

Eventually, 4coder probably wants to get into more of this sort of thing itself, but in the short term, having these things be customizable would probably allow anyone who wanted function-level editing to start down that road themselves inside 4coder.

Similarly, if the API had a "buffer changed" hook, then you could equivalently implement the "show the evaluation of this thing" feature as well, entirely in the custom API.

- Casey
I rather like the idea of having an editor that understands scope.
So that it would display scope and enable the user to navigate and modify at the scope level.

MockUp:


Edited by PassiveCoder on Reason: Removed comment about broken image
PassiveCoder
I rather like the idea of having an editor that understands scope.
So that it would display scope and enable the user to navigate and modify at the scope level.

MockUp:



I love your mock up. Something like that is definitely coming at some point. I have some ideas on how I can take scope intelligence to a really interesting new level. What font i that by the way?
That's a font called Dina,

https://www.donationcoder.com/Software/Jibz/Dina/