not OP, but i tried eat for about 2 seconds and immediately gave up. The backspace key produces spaces.
Then I tried vterm. The backspace key works! OK the basics are out of the way. Let’s try my basic git workflow, using ncurses program tig to view a log. Nope, lots of random jumpy scrolling.
Maybe these issues have work arounds. But iterm2 + tmux + Emacs already work flawlessly. Years of use with 0 issues.
philosophy of Unix
emacs -nw loads pretty fast if you defer loading your packages until first use. It can easily fit into a vim-like command line workflow on modern computers. The emacs demon is an option if you have a slow init.
Although traditionally you treat Emacs as a giant program you never quit. Stay inside and open files within Emacs.
tmux
Emacs + tmux works great too. Most people are GUI Emacs users, but the TUI is first class.
but I feel that I will find some difficulties and I am afraid
You need to try Emacs at least once in your life. It gives a glimpse at what lisp development feels like. In lisp you develop your program while it runs. The code is more than dead text in a file. It’s alive. The software is alive and you develop it by interacting with it. The relationship between source and image is more seamless. Emacs embodies this.
No one knows what they don’t know. Emacs is the first step to knowing. Emacs is god.
The lisp environment of Emacs makes it unique. Also it’s support for dynamic modules gives you a TON of extra power for certain cases where lisp is not appropriate; integrating 3rd party software like web browsers in a performant way.
If your goal is to simply use the editor then the lisp environment doesn’t give you an advantage. But if you want to treat the editor as a tool you mold like clay to your tiniest yak shaving need then it gives you a LOT.
For comparison, let’s look at Netbeans. A stereotypical traditional IDE. . If you try to write a plugin Netbeans you are first met with boilerplate. Menus, a bunch of strange plugin related code generated. You have to learn the plugin boilerplate system to get started. Now you wrote a little code and are ready to test/observe it’s behavior! how do you do that? you build/run and spawn YET-ANOTHER-NETBEANS which may take a few minutes. The write/observe feedback loop is painfully slow. (FYI I love and use Netbeans. I’m dunking on it but it has some advantages even over modern IDEs like Jetbrains).
Now let’s look at Emacs. We start by writing a function. Then immediately observing/testing their behavior. There is no boiler plate. We are not cordoned off to a special “plugins” area. We just straight to the good stuff, the functionality. Instead of waiting 5 minutes to build/observe what we wrote, it happens IMMEDIATELY as we write it using lisp’s EVAL-loop. It affects our running Emacs instance, no need to spawn another.
I lied a little bit. Emacs packages DO have boiler plate that you should conform to before publishing. But it’s not required, and not where you start. For your personal stuff, it may simply be a collection of functions. Then bind appropriate functions to keys.
An anecdote. Just yesterday I was writing some Go (lang) code and running the linter. Most of the time I like to run the linter at the project root folder. But at that moment I only care about the package I’m working on in the current folder or maybe 1 level up. I whipped up a little helper function where I can select 1 of 3 options: current folder, project-root folder, Custom folder. The project root folder is detected by heuristics using Emacs project library. If I choose Custom, then i input a folder via completing read. This little fn scratches MY itch. A tiny little inconvenience solved in 5 minutes. If i tried to solve that in Netbeans… it would take 5 minutes just to build it and spawn another Netbeans instance.