[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43948: 28.0.50; [PATHC][NS] Make s-<left/right> to move to beginning
bug#43948: 28.0.50; [PATHC][NS] Make s-<left/right> to move to beginning/end of line
Fri, 13 Nov 2020 10:05:44 +0200
> From: Andrii Kolomoiets <email@example.com>
> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
> Date: Fri, 13 Nov 2020 01:20:36 +0200
> Eli Zaretskii <email@example.com> writes:
> >> 2. M-: (set-frame-width nil 50)
> >> 3. M-<
> >> 4. M-x end-of-visual-line
> >> The point moved to the beginning of the next visual line
> > What else did you expect, in a continued line? There's no place to
> > show the cursor except at the beginning of the next screen line.
> Well, sometimes the cursor is on the fringe.
Can't be done in this case, because the fringe is "taken" by the
> With "bar" cursor type this leads to interesting behavior:
> emacs -Q
> M-: (set-frame-width nil 70)
> M-: (setq cursor-type 'bar)
> Now it's easy to place the cursor after the "." on the first line:
> M-< C-e
> But it is not possible to place the cursor after last "e" on the second
> IIRC it's because the cursor is actually "on" some character and not
> "before" or "after" it.
Technically, because we decide where to place the cursor before we
know what is the shape of the cursor. And yes, we draw the cursor
inside a certain character cell (because that's what users generally
> And at the end of the first line the cursor is on the "new line"
> I didn't mean to say the behavior of the 'end-of-visual-line' function
> is wrong. I tried to say that behavior of the 'end-of-visual-line'
> function outside the 'visual-line-mode' can be surprising for the users
> who press Command-<Right Arrow> to go to the end of the line.