I guess if the AI is good enough, your point makes some sense.
It's a good programming habit to doc your code as you write it.
If you do this in a structured way and code folding is used
the comments should get out of the way from the main code.
Why could you not create a comment block above the code section in question and fold it. All IDE's nowadays support folding, including comment block folding.
To see what a section of code does, you unfold the comment block above it, read it, then fold it back.
Emacs is a great editor if you don't want to have to use the mouse
and once you get familiar with its command set.
What I'm working on is creating a keyboard-input only GUI SDK
that enables you to build something like Emacs easily.
A keyboard based IDE for a keyboard based GUI for PCs.
Common PC GUIs are WIMP based (Windows, Icons, Menus, Pointers).
They require the usage of a mouse and are pretty complicated.
I find the usage of the mouse in a PC GUI "unnatural".
So I set out designing a keyboard-input only based GUI.
It turned out, that wasn't as difficult as I initially thought.
Then I started writing an IDE for designing apps using this new GUI approach.
I call it EngageUI, since it is user activity based.
https://github.com/Rohit-Agarwal-Khitchdee/EngageUI/
FWIW,
A sitar also has a 12 note scale, but the frets are moveable so you can tune by ear. The drawback is, you only play melodies on the top string and there are no chords.
It's possible to design a guitar where the frets are spaced at harmonic intervals
and not equal tempered, but then, you can only play in one key, the key of E and you can't capo or play barre chords. However, if you do play such a redesigned guitar in the key of E, it will sound sweeter because all your notes will be harmonic and you could play chords.
I'm thinking more in terms of what you put into that interface.
Do you add features that you might need later?
My approach would be no.
You design your first interface with only what you need right now.
And if you don't need an interface to do that, you bring in the interface later.
Generality leads to bloat in software systems
and increases complexity unnecessarily.
As a general rule of thumb,
software should be designed with the specific use-case in mind
that applies to the current needs of the user.
Generalisation should be delayed as long as possible
in the design process.
This is because the process itself reveals what would benefit
from generalisation.
Here is an editor for C I'm in the process of writing with a Modal, keyboard-only interface.
It features a 3 column source code display format which is different from the traditional single column format.
Also, there are on-screen controls such as menus, toolbars, navigation windows etc.
The entire screen is used to display source code and
keystroke sequences are used for navigation.
In particular code folding is very efficient.
https://github.com/Rohit-Agarwal-Khitchdee/Modal-GUIs
I've defined a couple of source code navigation constructs above the language level that are embedded inside comment blocks.
While I've written this editor for my own use, I've made it available as an open-source repository Github.
It is experimental. The source code is well documented and easy to modify for your own purposes.