Is there a way to navigate to the physical line in a file? It seems somewhat inconvenient to translate compilet errors to locations in Code Browser otherwise.
When a tool is run, its output is parsed. If a line is recognized as an error or warning message, it will appear in the output window as a link. By default, the editor recognizes two patterns:
filename:line:message
filename(line):message
but it can be customized with the error-pattern properties.
If the file is not an absolute path, the directory specified in tool is used. If there is no directory specified, the current working directory of the editor is used instead.
This article smells a bit AI-generated. The AI-generated image up top really doesn't help sell it to me.
I will proceed to engage with the concept, though, because I find it interesting.
I'm not quite convinced this type of code editor would be very good for anything other than object oriented programming, which I personally find a bit inefficient (both for humans and for machines…)
I actually really like the idea of organising code into files as independent modules of functionality (which are composed of data structures, and functions operating on that data). Looking at single data structures or functions would just make the whole module more difficult to understand, rather than having the whole thing open and listed in front of your eyes. I already find OOP's conflation of objects and modules a bit strange, and this would likely just exemplify it by having you look at tiny fragments of code, rather than the wider context of the entire unit of functionality.
For that reason I would actually prefer to see more of the module, rather than less. I've written about this on my blog; I think having an editor which can split the code into multiple columns, and keep their scrolling interlocked, would be nice. Sort of like having your display be 2x taller, but the lower part be folded back onto the right side of your screen. Or more simply, imagine if reading your code would be more like reading a newspaper with multiple columns and word wrapping.
That idea feels orthogonal to having a System Browser-like outline (which many editors have, though not in that multi-column style, and only for jumping in a file)—but with my more module-oriented approach to code, I think I prefer fuzzy-searching through files instead.
The "investigation trails" idea reminds me of the "Code Bubbles" experiment/prototype from some time ago (see e.g. https://cs.brown.edu/~spr/codebubbles or https://cs.brown.edu/people/spr/codebubbles/indexold.html at the bottom for screenshots). I'm not really sure why it didn't stick; though admittedly I also never tried it, so not sure what are the drawbacks. Or - did it? I'll need to look around. From time to time I keep thinking I wish I could use tech like that, esp. when diving into some codebase - in meantime, I tend to write the breadcrumb path manually in a paper or digital notebook...
Edit: I now remembered that I think there are some disassemblers which use this approach - e.g. famously IDA Pro, but I think maybe I saw glimpses of some FOSS remakes too at some point? Edit2: after asking an llm (sorry! I'm trying to learn this tech a bit...) some additional trails that look potentially interesting based off IDA Pro include Ghidra and x64dbg (debuggers/disasm), and Sourcetrail (archived in Sep 2021) for some high-level languages. Though I'm not sure if they allow navigating only along a callstack, or also more freely?
Edit3: browsing the fork tree of Sourcetrail on github, one fork seems still maintained! See:
lorddimwit | a day ago
This gives me an opportunity to remind everyone of the absolutely beautiful Code Browser folding editor: https://tibleiz.net/code-browser/index.html
theblacklounge | 8 hours ago
Does it solve any of the issues mentioned in the article, or does it just reproduce them for all other languages?
alexmu | 13 hours ago
Is there a way to navigate to the physical line in a file? It seems somewhat inconvenient to translate compilet errors to locations in Code Browser otherwise.
lcapaldo | 7 hours ago
I have never used this but the rewrite supports line numbers: https://tibleiz.net/clade/
riki | 8 hours ago
This article smells a bit AI-generated. The AI-generated image up top really doesn't help sell it to me.
I will proceed to engage with the concept, though, because I find it interesting.
I'm not quite convinced this type of code editor would be very good for anything other than object oriented programming, which I personally find a bit inefficient (both for humans and for machines…)
I actually really like the idea of organising code into files as independent modules of functionality (which are composed of data structures, and functions operating on that data). Looking at single data structures or functions would just make the whole module more difficult to understand, rather than having the whole thing open and listed in front of your eyes. I already find OOP's conflation of objects and modules a bit strange, and this would likely just exemplify it by having you look at tiny fragments of code, rather than the wider context of the entire unit of functionality.
For that reason I would actually prefer to see more of the module, rather than less. I've written about this on my blog; I think having an editor which can split the code into multiple columns, and keep their scrolling interlocked, would be nice. Sort of like having your display be 2x taller, but the lower part be folded back onto the right side of your screen. Or more simply, imagine if reading your code would be more like reading a newspaper with multiple columns and word wrapping.
That idea feels orthogonal to having a System Browser-like outline (which many editors have, though not in that multi-column style, and only for jumping in a file)—but with my more module-oriented approach to code, I think I prefer fuzzy-searching through files instead.
akavel | 7 hours ago
The "investigation trails" idea reminds me of the "Code Bubbles" experiment/prototype from some time ago (see e.g. https://cs.brown.edu/~spr/codebubbles or https://cs.brown.edu/people/spr/codebubbles/indexold.html at the bottom for screenshots). I'm not really sure why it didn't stick; though admittedly I also never tried it, so not sure what are the drawbacks. Or - did it? I'll need to look around. From time to time I keep thinking I wish I could use tech like that, esp. when diving into some codebase - in meantime, I tend to write the breadcrumb path manually in a paper or digital notebook...
Edit: I now remembered that I think there are some disassemblers which use this approach - e.g. famously IDA Pro, but I think maybe I saw glimpses of some FOSS remakes too at some point? Edit2: after asking an llm (sorry! I'm trying to learn this tech a bit...) some additional trails that look potentially interesting based off IDA Pro include Ghidra and x64dbg (debuggers/disasm), and Sourcetrail (archived in Sep 2021) for some high-level languages. Though I'm not sure if they allow navigating only along a callstack, or also more freely?
Edit3: browsing the fork tree of Sourcetrail on github, one fork seems still maintained! See:
https://github.com/OpenSourceSourceTrail/Sourcetrail
sugaryboa | 16 hours ago
Not the browser you expect.
theblacklounge | 8 hours ago
No tabs and a 'go to previous' button? What about breadcrumbs?
Sanity | 8 hours ago
Is there anything that emulates this in Emacs, so one could browse through modules/classes/methods/docstrings for other languages?