What is the easiest and most accessible editor?
Linux for blind general discussion
blinux-list at redhat.com
Tue Nov 30 20:36:24 UTC 2021
As I think I've already said, Emacs has a nice tutorial available to you once you install Emacs. It also has pretty extensive documentation that you can get to multiple ways.
As for Emacspeak, all I can do is apologize for not spending the time to create a getting started guide for the new user, even though I am an Emacs fan boy.
Christopher (AKA CJ)
Chaltain at Outlook
From: blinux-list-bounces at redhat.com <blinux-list-bounces at redhat.com> On Behalf Of Linux for blind general discussion
Sent: Tuesday, November 30, 2021 2:32 PM
To: Linux for blind general discussion <blinux-list at redhat.com>
Subject: Re: What is the easiest and most accessible editor?
I have been following this discussion for a bit and was wondering, and have been doing so for a while, where do you go to learn Emacs?
Even worse is Emacsspeak, the user guide I can find out there is more
than 10 years old.
Isn't there a concise, easy to follow step-by-step guide out there some
I'd think those, so passionate about their chosen choice would make it
possible for the newbie to learn, Gentoo and Arch did it, why not Emacs
Sent from the Fedora machine, using Thunderbird
On 2021/11/30 19:45, Linux for blind general discussion wrote:
> Interesting. The problem is that email itself has several components
> that don't fit well into an editor window. Reading and writing emails
> for example fits into an editor style window just fine, but setting up
> email accounts, moving through folders and lists of messages,
> expanding and collapsing threads, etc just don't fit into that box
> very well.
> I also had a look at one point at the shell terminal. Whereas it's
> good to be able to edit the current command line, I found that
> pressing the up arrow key to put the previous command back on the
> screen to either repeat or modify didn't bring up the previous
> command, but instead put my cursor on the last line of the previous
> command's output. Shells need to be line edited, not screen edited,
> and that's where the whole thing fell flat, especially since as I
> recall, I was even able to accidentally overwrite command output
> because the whole screen is in an editable ... buffer I think they
> call it.
> Regarding the key sequences, x is a way to cross something out, x it
> out, cut it. C stands for copy, and I guess v got its paste
> functionality because it's right next to cut and copy. Not sure about
> that one. Still, it's better than some of the key combinations I find
> even in nano, control+w to find something for example, or even better
> is control+q, which is supposed to quit, but instead performs a
> backward search. What the ...? Emacs keys are even worse, since as I
> recall, finding something requires two key combinations, and if I
> remember correctly, neither includes an f for find or even an s for
> search. Emacs puts me in mind of the old days of a little program I
> used in school called Turbo Pascal. That horrible thing ... if I
> wanted to compile the program I had just written,- I still remember
> it - I had to press control+k and then d. Again, what the ...? I don't
> know ... I just did it ... because that's what the teacher told me I
> had to do in order to compile my program. Nothing in that key sequence
> could be thought of as compile or even build, well, maybe the d on the
> end of build. But that sure was a nightmare to have to remember that
> that's what that crazy combination of keys did. I can only imagine
> everything working that way, which was the experience I had when I
> looked at some Emacs documentation. But then I could be wrong, since
> the last time I even opened the application was probably 15 years ago,
> and I didn't even see the nice little help thingy at the bottom of the
> screen like what I got from Nano and Pico that I had used before it.
> At least in vim I was able to use the :help command to get me started,
> but even that was much more complicated than it needed to be,
> especially when I just wanted to cut something and paste it somewhere
> else in the same file. I do like its search and replace functionality
> though. %s/something/else/g if I remember correctly, just like in the
> sed command, will replace every occurrence of something with else.
> That said, I can just as easily run a find and replace, put something
> in the search field and else in the replace field, then tick the box
> that says replace all, and it's just as good, and doesn't even use
> more fingers, since the tab key is replacing the / key in this use case.
> Blinux-list mailing list
> Blinux-list at redhat.com
Blinux-list mailing list
Blinux-list at redhat.com
More information about the Blinux-list