Assuming that you are referring to plain text…

while keeping them as clickable links

First of all you need to establish why a plain text URL is doing something when you click on it, as your new requirement is going to need to interact with that.

(I’m guessing goto-address-mode is enabled, so I would check that first.)

Check C-h v comint-process-echoes in that buffer.

If it’s nil, try (setq-local comint-process-echoes t)

If that fixes it, then you can use this repl’s major mode hook to do that automatically.

There is a thing which provides zsh completions. It’s zsh. If that’s what you’re wanting, then maybe don’t stop using it?

Have you considered an org-capture template fitting your desired format?

I don’t use use-package, but I’ve seen a lot of questions from users who do use it but don’t understand how to use it, or what it’s going to expand to, or what the things that it expands to actually do. My conclusion has been that for some users it introduces as many problems as it solves. I think those users would be better off if they learned how to manage their config without it first, and only considered use-package after understanding the more fundamental building blocks upon which it is built.

It’s certainly not something you need to use, in any case. It’s clearly an invaluable system to many users, but if you don’t get along with it, don’t use it.

The author of the emacs pgtk code says that no one who has X installed should use pgtk – he’s stated on several occasions that if you have X at all then you should use a supported X toolkit in Emacs for best results.

I’ve seen counter-arguments that pgtk is still beneficial if you happen to have a “high DPI display”, but I believe that’s the only argument I’ve ever seen for using pgtk under X.

I always build --with-x-toolkit=lucid myself, and can happily vouch for that one. I don’t use Wayland, though.

You don’t have to declare a new variable each time you want to remember an old value. You could, e.g., put a custom symbol property on the variable symbol with the old value (or list of old values) you wanted to store. Or maintain a single variable mapping all your variable symbols to their old values.

the configuration contains a lot of junk

What do you mean? What is the specific problem?

Tell us how you run that external program outside of Emacs, and we can show you how to run it inside Emacs.

Then it’s just a matter of timers and a variable in your mode-line-format. Note that your variable will need the risky-local-variable in order to show text properties (for the colour). See C-h i g (elisp)Mode Line Data and/or C-h i g (elisp)Properties in Mode.

Everyone can contribute to the documentation to make it better. Consider doing so.

Remember, no one gets paid to maintain or document Emacs, so the quality of the documentation is really pretty remarkable for how good it is.

It can always be made better, though.

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

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.

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.

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.

The question lent itself to both earnest and humorous replies, and it duly received both, so this seems very unnecessary. If you don’t think a joke is funny, down-vote it and move on.

I don’t know, but it might help to check C-h l to see which sequence of mouse events Emacs is reporting in each case.