Why meow-append behaves the same way when there's no region?

[DogLooksGood]

The question have been asked a few times, so I migrate my answer to Q&A.

meow-insert means insert at the beginning of region, and meow-append means append at the end of region. So when there's no region, insert and append will behave the same. The behavior is expected and reasonable.

It's simple to write your own function to move the cursor when no selection available. BUT, this doesn't get to the root of the problem.

For example, if you write your own meow-append.

Press a, cursor stays

Press a, cursor moves

weird, doesn't it?

In Vim, cursor is located on one character. In Emacs, cursor is located between two characters. (no matter the cursor shape)
In Kakoune, there's always a selection, with minimal width 1, but we can't do this in Emacs.

The only solution is to hack the cursor position, (like Evil does), I don't know what Evil does, but I have implemented one in Meow.

;; Must set before enable `meow-global-mode`
(setq meow-use-cursor-position-hack t
      meow-use-enhanced-selection-effect t)  ;; optional, for visual effect

(meow-global-mode t)

NOT RECOMMENDED. I didn't even mention the feature in document. Since Meow is not Evil, I enjoy simplicity.

[ghost]

I think it would make sense to add an option for meow-insert to always change state to insert without moving the cursor. Then you can use meow-reverse to change cursor position inside selection before inserting.

[ghost]

Don't know if there's a difference, but for now I just removed (meow--direction-backward) from meow-insert defun.

Edit: meow-insert-mode won't cancel selection.

[DogLooksGood]

There's a lot commands don't have a explict direction, for example, meow-line. That is, there's a lot cases that requires you one more key, if you do reverse insert to insert at the other side.

[ghost]

I don't understand, meow-line does have a direction, doesn't it? It's to the end of a line by default and to the start of a line with negative-argument.

Actually, with meow-reverse/line/join I don't see any point to have meow-append especially if it doesn't work like in vi, for me it's just confusing. So I mapped meow-join and meow-line to a and e instead, for a more "emacsy" feel.

[DogLooksGood]

Yes, it's recommended to have your customized keybindings according to your taste.
meow-line has a direction, but it gives two positions once the selection is created. The beginning of the line and the end of the line. For most of the time, you can do line insert or line append, the reverse is only used when you want to move to the beginning without switching to INSERT state. And there are similar situations with meow-block, meow-join, meow-inner/bounds/beginning/end-of-thing, etc.

[ghost]

So it's two buttons instead of one, yes, but that's already the case without a selection. You can't use I and A to move to the start and to the end of a line, like in vi, you have to use meow-line or meow-join first. It feels more consistent to have the same in selection - you have to use meow-reverse before you can insert on the other end of selection.

Most of the time you have no need for that either, because you either select stuff to move cursor around, so you certainly don't need to insert at the start/end of the selection, but at the lines you moved to, or you select block to do something with it, so you don't want to use append/insert, because it would cancel the selection. (By the way, is there a way to restore last selection, like in vim with gv?) That means you need meow-append only to save one keystroke in some very specific situations, and most of the time you probably would use meow-line/join with meow-insert instead.

[quarkw]

I believe Meow would work more intuitively if no selection was actually treated as a selection of length one. In addition, I believe that with all selections, when the point is at the end of the selection, the point should actually be moved one character earlier, so the point is visually part of the selection.

For the following, I'll describe using the default qwerty keymap.

With the current behavior, the default "reset" state of having no selection causes multiple commands to act the same way in a confusing way.

1. i and a do the same thing when nothing is selected
2. c, and L then c do the same thing when nothing is selected
3. When visiting a word, the point is not actually on the word, so if we want to execute a function at the current point, it will not be on the word we're visiting, unless we reverse the selection with ;
4. On an empty line, c behaves differently from x then c, even though x on an empty line is an empty selection.

I understand that changing core default behavior is probably not desired, but maybe there could be a flag to enable this as alternate behavior?

I believe this could be done with chaining commands, and would make the logic of using Meow more consistent. In fact, the no-selection is a selection of one char paradigm is actually already applied for c with the fallback command. This actually causes the inconsistent behavior in 2 and 4.

One serious downside of this change is that the commands d and D no longer fit logically, as they are commands that operate on the cursor/point uniquely as opposed to a selection. However, to me D doesn't make much sense in the first place since it does the same thing as backspace, even in normal mode. And I would prefer if d functioned as a non-copying version of s, or equivalent to c then ESC, since d just aliases to C-d anyways, and doesn't do anything special like preserving the current selection. However, this is already untrue (that c then ESC is equivalent to s, minus the copying) since s has special cases for new lines and join selections.

Also, selections that include a new line would also have to be rendered specially. Evil mode does this by showing the selection region all the way to the edge of the screen past the point.

[gf3]

i would also find this more intuitive!

[DogLooksGood]

We were a similar option in the past, but later I found that's just simulating the kak style. It will work, but also need a lot hacks and bring a lot compatibility issues. So I decided to stay with the nature of Emacs.
I want Meow to be more close to vanilla Emacs, make it a thin modal layer.

[quarkw]

After taking a closer look at how meow is implemented, yeah this would be a lot of hacking because of how regions are defined in emacs, unfortunately 😢

I would argue that the way emacs regions are implemented, combined with the point existing between characters makes it very incompatible with the kind of editing experience meow is trying to experience. There is already some hacking in the form of meow-selection-command-fallback to try and get around this.

I definitely understand why you want to keep things as vanilla as possible though. Meow is a great package, but not for me. The inconsistencies caused by this issue have made me switch back to evil.