While the LSP protocol is useful for completion or access to symbol definitions, some of its features are less appealing. In #Emacs, you can instruct Eglot to ignore any feature you dislike.
E.g. (setq eglot-ignored-server-capabilities '(:inlayHintProvider)) to remove annoying hints mixed with the code in c-mode with clangd.
Today I learned something new: don't edit "authorized_keys" file in an ssh tramp session when remote disk is full. The moment you (try to) store the new version, Emacs will backup (rename) existing file and try to write a new file. If that fails because of disk full and the file happens to be "authorized_keys" you immediately will lose ssh access to that remote machine.
@holgerschurig I wish this were true. In reality already creation of "authorized_keys~" will fail. You will end up with both files, "authorized_keys" and "authorized_keys~" having a size of 0.
In "Messages" I have this:
Copying /ssh:example.com:/home/someuser/.ssh/authorized_keys to /ssh:example.com:/home/someuser/.ssh/authorized_keys~...failed
File error: Copying directly failed, see buffer ‘tramp/ssh someuser’ for details
Cannot write backup file; backing up in /.emacs.d/%backup%
Copying /ssh:example.com:/home/someuser/.ssh/authorized_keys to /home/someuser/.emacs.d/%backup%~...done
So you will have a backup of the original file content in "%bakcup%~" on your local machine but not on remote machine.
@fox@ecadre Oh, I meant a different backup: ecternal packages.
From time to time it happens that I update the external packages, i.E. consult, notmuch, etc etc
And it could now be the case that one of these packages introduce an error.
If I don't have time right now to debug this, I can use git to revert this one external package to its previous stage... and pull again in 2 weeks and hoping that someone wiser in ELisp than I fixed the problem in the meantime.
Since my in own config didn't change, backing it up would have made no change. But then again ... my Emacs config is in git, too. So it's automatically backed up the moment I stage a changeset.
I passively read the #Emacs subreddit but I have zero desire to be on reddit. Often I come across questions I think I know the answer to and can only hope someone else answers it (and most of the time someone does it).
#dired is a tool that seems super powerful, but I don't use it often enough to stay familiar with the features. This sounds like a great fix to that issue!
The original announcement from the package author:
How would you run create a long process (rsync for example), create a temporary buffer in split for it, tail the output to the buffer so it’s up to date; then if the process exists success close the buffer? Preferably the emacs should not lock the whole time.
@mms On Linux I wouldn't do this in Emacs, but from systemd. One can create transient services in it (via api, not via foo.service file).
If needed, I could then run "journalctl --unit foo" in some Emacs buffer, but I don't really see the benefit: I am using Emacs mostly with just one window and frame. So having some process output clutter my spartanic display setup ... naah.
My #emacs discovery for today is dired-omit-mode. It hides less interesting files (object files, backups etc). There are a few options to tweak what you want hidden.
The default binding is C-x M-o but I've also put it on just M-o in my config so that I can toggle it quickly.