Terminal-Based Linux as a Practical Platform for Blind Programmers

I have a very strong Linux background dating all the way back to early 1998 when I had the crazy idea of downloading the RedHat Linux 5.1 CD image (currently known as Fedora) over a dial-up connection, got involved in kernel development in the early and mid-2000s during the days of Linux 2.4 and 2.6, and with the exception of gaming, which I had a dedicated PC with Windows for, all my computer use was on Linux. I was one of the first people to join the compositor craze in 2006 with Compiz, used Gentoo for most of my sighted days, and only switched to macOS in 2011 when my vision began to deteriorate. Since then I kept using Linux on VPS hosts, containers, Raspberry Pis, you name it, but never again on the desktop, because the days in which I had fun recompiling the kernel to add support for a Wi-Fi driver, or patching power management code to make some buggy drivers wake back up from suspension, are long gone. Also and since I'm not congenitally blind and lost my sight well into my adulthood, I never felt much need to use Braille, which I did learn in rehabilitation but never actually practiced, and I don't think Braille is particularly useful for coding.

As a speech synthesizer screen-reader user, while I agree that command-line interfaces are vastly superior to graphical interfaces, my opinion flips completely when it comes to other kinds of text user interfaces with graphical user interfaces, so I run from console editors like the devil, and whenever I want to edit something on a remote machine, I just install rmate on it, which is a Ruby script that makes it possible to use TextMate over an ssh tunnel to edit remote files from the command-line as if they were local, and always try to learn about available command-line invocations that can help me avoid all kinds of ncurses interfaces.

Try some of those fancy TUI's, with animated spinners, or those Python Terminal prettifyer libs, and you'll see why the Terminal still isn't safe from the sighted's need to visualize, verb, everything. That being said, it is still, at it's core, the most accessible input output system. And that's also why AI's work so well too.

This is really interesting.

Please forgive my foolishness. I'm assuming I can use something like parallels to set this up? What you've created is like an overlay for the linux OS, is that right?

Seems that virtually all code editors from cot editor, text mate , vscode, getbrains... when we do command left / right arrow on an indented line (which would be the case most of the time :) ) vo unreliably speaks either half the line above or below it. I think this does not happen in xcode. This drives me insane and isthe reason why I am trying so hard to learn emacspeak . How have you overcome that? Habbit (like all macos accessibility issues? :) )? You hinted many times that all these are due to nstextview... From a user side it seems that no work around is possible? I tend to actually use my braille display for coding on mac only for this, or I just switch on my windows laptop or vm inside parallels.
VIM doesn't work at all on most macs I have tried but for this one guy who is lucky, there is an old thread of mine on this topic here about a year or two ago.
Stormux and arch linux is the only low friction way I've found on my raspberry pi to use vim, and the sad thing is that I loove vim so much. I guess this thing can work on all arm chips so maybe could try to virtualize it on mac? But a linux vm on top of an almost linux ish os just for accessibility is disgusting for me.
As much as I dislike it, my computer science program is completely into microsoft and code/text editing is uncomfortable in guis on mac, at least as a daily driver for me despite three years of experience with the mac.
Terminal itself is great though and I am happy each time I use it!!!
And to @onetrickpony
I haven't tried this yet, but 11/10 on the idea! I was hard of hearing before so can completely relate to this more than most probably.

Seems that virtually all code editors from cot editor, text mate , vscode, getbrains... when we do command left / right arrow on an indented line (which would be the case most of the time :) ) vo unreliably speaks either half the line above or below it. I think this does not happen in xcode. This drives me insane and isthe reason why I am trying so hard to learn emacspeak . How have you overcome that? Habbit (like all macos accessibility issues? :) )? You hinted many times that all these are due to nstextview... From a user side it seems that no work around is possible? I tend to actually use my braille display for coding on mac only for this, or I just switch on my windows laptop or vm inside parallels.

I've read your complaints about that specific quirk quite a few times, yes, but while I know what you're talking about, it's not something that interferes even mildly in my workflow, so honestly I never found it to be an issue, not even a minor one. Usually whenever I want to move to the first non-whitespace character in TextMate, I just press Home or Command+Left followed by Option+Right, with the latter not being required in Xcode since it already assumes that you want to move to the first non-whitespace character by default.

I don't even think that the problem is NSTextView in this case, even if I said something different at any point in the past, my current opinion is that it's related to TextMate snapping the character to tab stops matching your indentation preferences on the left most side of every line, and that ends up confusing VoiceOver as it tries to figure out what kind of caret movement you triggered. The reason why it doesn't happen in Xcode is likely because Xcode doesn't do this snapping.

Thanks you :) as always.