dtach VS micro-editor

ssh from your favourite terminal to your workstation works fine. (I spent two COVID years working that way.) If you use multiple terminals, look up ssh multiplexing to improve performance a bit. If you want to keep remote sessions alive without mucking up your preferred terminal, try dtach.

Not the same, but I really dig using vim (neovim) as my terminal multiplexer. Vim has tools for managing windows, splits, all the things, and it felt redundant having two separate tools.

The one thing I needed was a way to attach/detach it, and have it survive across ssh disconnects. I struggled for a while trying to use things like reptyr or others. Eventually I remembered/rediscovered dtach, which is a very thin very simple proxy, as opposed to a full on terminal emulator / multiplexer. https://github.com/crigler/dtach

Not really, and for what TRAMP + vterm doesn't cover such as unexpected disconnects, there's dtach and detached.el.

GNU Screen, tmux and dtach (with convenient Emacs interface) all serve to limit that problem.

> What's an opinion you have that most people don't agree with?

> Haha. I specialize in having opinions people don’t agree with :) In kitty, the most controversial is probably that terminal multiplexers are the devils’ gift to mankind.

I cannot agree strongly enough that the virtualized rendering done by programs like screen & tmux is a curse. Trying to get truecolor tmux+ssh+tmux+vim working in truecolor mode is a disaster. Terminal-multiplexers emulate a screen and then render their buffered session to whomever is attached, and it's a frustrating, bad, lossy process. Often the original session and what attaches don't match, and there's not much one can really do. I am not a terminal expert but the situation seems awful, & is one of the highest elder crafts of computing, far more subtle & deranged than one could ever imagine.

Kitty tries to re-build a lot of these terminal multiplexer functionalities itself. It has tabs, it has splits. Generally kitty is a pretty do-all terminal system. Afaik there's not really any way presently to solve the root of these mismatch problems, which is basically that programs generally don't reevaluate their TERM environment variable, even though these environs are technically editable at runtime (by the process, or outsiders).

Kovid (Kitty author) talks about being a vim user. I too am a vim user. In fact, one of my favorite techniques has been to just live inside vim, to use it's terminal emulator, to get ok (i'm still pretty not good) at using it's splits and windows to lay stuff out. The one missing agent for me was that I wanted a way to be able to detach my vim session & come back latter. I spent considerable time trying reptyr & other ways to reattach processes. After much failure at getting vim to detach/reattach, to persist across sessions, I eventually re-encountered a program dtach[1] I'd run into years ago, which works great. Unlike tmux and screen, it's not a terminal emulator. It's just a dumb pipe that a program can render into, and a way to reattach to that pipe again latter. It can run in detached mode so that if your session exits, the program stays open. This way, I can just open vim & have my entire workspace inside vim, with whatever terminals I need, and detach/reattach the vim session at my leisure.

[1] https://github.com/crigler/dtach

So now whenever you execute that command, it will update the channel with the current price. You can then run it on a loop, crontab, whatever you want. One of my favorite things to do is to use while $true loops, and applications like dtach.

i prefer to use dtach for that if I only need this feature

To see more screenshots of micro, showcasing some of the default color schemes, see here.

Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow:

- gdu: a NCDU clone, much faster on SSD mounts [1]

- duf: a `df` clone with a nicer interface [2]

- massren: a `vidir` clone (simpler to use but with fewer options) [3]

- gotop: a `top` clone [4]

- micro: a nice TUI editor [5]

Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers.

[1]: https://github.com/dundee/gdu

[2]: https://github.com/muesli/duf

[3]: https://github.com/laurent22/massren

[4]: https://github.com/xxxserxxx/gotop

[5]: https://github.com/zyedidia/micro

> The worst way to store and manipulate text is to use an array.

Claim made from theoretical considerations, without any actual reference to real-world editors. The popular Micro[1] text editor uses a simple line array[2], and performs fantastically well on real-world editing tasks.

Meanwhile, ropes are so complicated that even high-quality implementations have extremely subtle bugs[3] that can lead to state or content corruption.

Which data structure is "best" is not just a function of its asymptotic performance. Practical considerations are equally important (arguably more so).

[1] https://github.com/zyedidia/micro

[2] https://github.com/zyedidia/micro/blob/master/internal/buffe...

[3] https://github.com/cessen/ropey/pull/67

There are two main ways to configure sudo.The first one is using the sudoers file.It is located at /etc/sudoers for Linux,and /usr/local/etc/sudoers for FreeBSD respectively.The paths are different,but the configuration works in the same way. A typical sudoers file looks like this. The sudoers file must be edited with the visudo command,which ensures the config is free of errors.Running this command as the root user will result in opening vi by default.If you want to use a different editor you can set the VISUAL environment varaible to the editor you want. For example,if you want to use micro as the text editor run:

found that micro has dedicated info page for copy paste

micro: winget install zyedidia.micro