7890yuiop

Could you fix the formatting?

The only code block formatting method which works for all users of reddit is to switch the reddit editor to markdown mode* and indent the code by 4 spaces (you can use M-4 C-x C-i on a region followed by M-x untabify to achieve this in Emacs); and you need to use empty lines to separate the indented lines from the other text. Otherwise for lots of readers your message looks like this: https://old.reddit.com/r/emacs/comments/17etbx8/saveexcursion_wrong_type_argument/k685ohy/

Be sure to remove any different syntax intended for formatting (such as triple backticks) at the same time.

(*) Switching to the markdown editor may or may not still be necessary. At one time it prevented problems.

M-x toggle-debug-on-error should get you a stack trace which will explain what's going on.

Another option is to run a local Emacs and access the remote files over ssh via Tramp.

E.g.: C-x C-f /ssh:USERNAME@HOST:/path/to/file

You can read about Tramp in its own manual: C-h i g (tramp) RET

That's what git is for

Even for files which are being tracked in version control, I don't agree that VCS always replaces backups. In some cases, yes; but backups are to protect me from data loss, and I want that protection in more situations than VCS gives me.

or just having undo-tree

I assume you mean "with a persistent undo record", which is another form of backup file, so sure -- whichever kind(s) of backup you prefer. Personally I believe I'd still want regular backups even if I used that -- if I can't trivially grep or compare old versions, I'd feel I'm missing a capability.

I tried to keep auto-saves and backup files in their own separate directory, since they always litter my projects which is annoying, but they just won't listen, I have to disable them.

I keep all backups in a separate directory, and I do not experience your problem, so that sounds to me like a fixable config issue.

For details, see etc/PROBLEMS

I trust you did that.

* Crash bugs
 
** When Emacs is compiled with Gtk+, closing a display kills Emacs.
 
There is a long-standing bug in GTK that prevents it from recovering
from disconnects: https://gitlab.gnome.org/GNOME/gtk/issues/221
 
Thus, for instance, when Emacs is run as a server on a text terminal,
and an X frame is created, and the X server for that frame crashes or
exits unexpectedly, Emacs must exit to prevent a GTK error that would
result in an endless loop.
 
If you need Emacs to be able to recover from closing displays, compile
it with the Lucid toolkit instead of GTK.

Which means using ./configure --with-x-toolkit=lucid when building Emacs from source.

If you're not currently building Emacs from source then that will be a new adventure, but if you keep a log of everything you needed to do on your system to achieve that then you'll have a record (which you could always convet to an executable script) for building it in future without any hassle.

You have a couple of commands with double-hyphenated names as if they were internal-use functions, but (being commands) they're a part of the public-facing interface. I suggest renaming those.

Autosaves aren't needed once you've saved -- but emacs should already be removing them when you save your changes.

Backups are very specifically protecting you from the situation where the thing you saved was wrong. If you think that's useless, you haven't understood the purpose.

I think you'd probably write a custom command for this.

A normal way to do this in elisp is a simple while loop for your main search, and at every match you perform a second search, bounded by the desired limit, for your exclusion terms. Depending on whether or not the second search succeeds, add the original match to the results buffer.

You can leverage some of the occur machinery for presenting the results.

I suggest reinstalling Emacs, as your install sounds kinda broken. That file should not be missing, and I'd guess it's not the only one.

You don't have the Emacs manuals installed?!

Interesting. I'm still just guessing, but I notice that you're using relative line numbers which means that there's a potential difference between the amount of space needed to show the relative line number vs the absolute line number, and that might explain the shift in display. Can you reproduce this when using absolute line numbers? If not, that seems to narrow down the trigger scenario, which will be helpful information for an upstream bug report.

My guess is that the "drag" detection is a side-effect of this:

the whole buffer shifts to the left like a single pixel

as it's conceivable that this means the positions of the click and release are "different" even if you didn't actually move the mouse.

So that maybe explains the end result, but not the actual trigger.

I'm just speculating though.