On 5/9/21 10:58 AM, René J.V. Bertin wrote:
On Sunday May 09 2021 00:10:38 hw wrote:
Can that be deactivated per buffer? Not that I would want to do that;
autosaving is a good feature, and I don't see how turning it off could
be useful for protecting buffer contents from being accidentially altered:
Simple, really: if you always save *yourself* to commit any conscious changes you made, you can reload the document from disc if you have doubts about any unsaved changes.
That's what I'm doing. Since I'm not a computer, I sometimes forget to
save something. Protecting some buffers by setting them read-only is
extremely helpful. What do I have a computer for? :)
Autosave means to save a copy of a file, not overwriting the file that
has been modified and not saved. Does kate overwrite files when
autosaving them?
Autosave is a global setting, not per-document ... and why would it be anything other? Than again I never understood why people would use emacs instead of vi O:-)
Maybe someone doesn't want to autosave all files. That can be
particularly useful when editing remote files and for editing files in
directories the user doesn't have permission to write new files to.
So why should autosave be a global setting? That won't make sense.
I tried vi, too. The approach of not editing a file but instead typing
commands all the time to painstakingly altering it character by
character doesn't agree with me. That way, vi is totally getting in the
way of editing files. If that approach is for you, I guess I can
understand how someone would use vi instead of emacs.
Vi is like carving stone tablets while emacs is like a colour laser
printer which even automatically refills its toner when you enable the
mode. That's how people use emacs. I'm not sure what people using vi
are doing ;)
And kate? Kate feels more like an empty parking garage with dim
illumination, some waterfalls somewhere and very white walls nobody
wants to enter.
(The duration of emacs sessions is usually the
same as the uptime of the machine, and that can be more than a year.)
Sounds like you're trying to make Kate behave like emacs, and that you'd be better off using emacs in a terminal emulator.
No, I was trying kate again because emacs doesn't work in plasma-wayland
sessions. Kate doesn't need to work like emacs, it only needs to let me
do things emacs lets me do.
That's probably going to be faster too, and way less RAM hungry in case you're keeping the editor open for more than a year.
My impression is that not running in a terminal is faster, and in a
terminal, not all key combinations work. All machines I would be
running emacs on have sufficent RAM, and what do I have RAM for when I
don't use it.
Or use a pager like `less` that has a shortcut to open the document in an editor if you want to make a change.
It's easier to just switch to another buffer in emacs than to switch to
a terminal to run less on.
You did select the "Mouse Precedence" type of "Focus follows Mouse" in KWin's settings, right? There are 2 stricter levels but if those aren't enough to make KWin handle focus as you wish, there are plenty of other WMs out there (I find xfwm4 a good one that doesn't get in my way).
Yes, and focus stealing prevention higher than medium is too high in
that it disables the focus on things it shouldn't be disabled on, like
the search bar in the applications menu of the panel.
That is not the problem, though. It's a bug in kwin which makes it so
that when you move the mouse pointer from one window to another --- like
an emacs frame or a konsole window --- the window you moved the pointer
to doesn't get the focus. You can move the pointer back and forth and
the window you want focused may eventually get it. Until then, the
focus goes somewhere else, and you usually don't know where it went.
Fvwm doesn't have this bug.
Now imagine that on your screen, there is a gap between two konsole
windows which are on top with an emacs frame below. You move the
pointer from one konsole window to the other and kwin sometimes makes it
so that the emacs frame gets the focus. Since you don't realise, you
start typing in the konsole window and nothing happens and you move the
mouse to get that window focused and eventually can type in the konsole
window.
Especially when the gap between the two windows is very small, you never
realised that you typed into an emacs buffer (or somewhere else) --- and
only some time later, when you happen to save some buffers or when
exiting emacs after editing files, you need to figure out if you did
want to save the file you accidentially edited.
That is prone to errors and annoying, and setting buffers to read-only
prevents problems like that. Even if kwin wasn't buggy, it's always
possible to accidently hit a key you didn't want to and to type
somewhere you didn't want to. Just set some buffers to read-only, and
the problem doesn't exist anymore.
I don't know how I could switch the window manager in kde. And which
one would I use? That would have to be one that works with wayland ---
and if it wasn't for that, I'd use fvwm and no kde. Kde only slows the
computer down. Wayland still isn't usable, but in Fedora 34 it finally
works with NVIDIA drivers --- it wouldn't even start before --- and over
time it'll replace X11 ...
Gnome would be an alternative, but it is so dumbed down and so
unconfigurable that it is totally useless. Unfortunately, that is
intentional, so that is unlikely to ever change. I keep wondering why
people would put up with it.
What else works with wayland?
