unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Phil Sainty <psainty@orcon.net.nz>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 52163@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>,
	iung@autistici.org
Subject: bug#52163: 28.0.60; visual-line-mode breaks C-a and C-e in extreme case
Date: Sun, 16 Jan 2022 22:58:34 +1300	[thread overview]
Message-ID: <ce505094517a15ace28660dcf4096653@webmail.orcon.net.nz> (raw)
In-Reply-To: <42F16660-8FDC-499E-896B-D7DABDC59FD8@gnu.org>

On 2022-01-16 20:22, Eli Zaretskii wrote:
> Where do you want Emacs to place the cursor when there's no
> whitespace at end of visual line?
> 
> IOW, before declaring that there is a problem, please be sure to
> consider any reasonable solutions.

In this scenario I would expect it to place the cursor on the final
character of the original visual line, rather than the first character
of the subsequent visual line.

If you do C-a C-e C-a and the two C-a commands take you to two
different positions (and indeed different lines), I think that is very
strange indeed.

Regardless of the solution, there is no whitespace for the cursor to
be positioned at, so I think the decision to use position N+1 rather
than N seems somewhat arbitrary, and unintuitive as a "Move point to
end of current line" behaviour.

I expect the counter argument is that the first character of the next
line *is* the position at the end of the visual line if it's not
possible to break that line (i.e. the region between the C-a and C-e
positions is indeed the entire visual line); but I think visual lines
are such a dynamic notion to begin with (depending on window width,
font size, etc, etc), and the "end" of an unbreakable line an even
fuzzier notion, that using the position of the last char of that line
doesn't seem like it would be very problematic for most users.

A user option to select between the two behaviours would be nice.


-Phil






  reply	other threads:[~2022-01-16  9:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-28 14:49 bug#52163: 28.0.60; visual-line-mode breaks C-a and C-e in extreme case iung--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-28 17:07 ` Eli Zaretskii
2022-01-15 13:08   ` Lars Ingebrigtsen
2022-01-15 22:53     ` Phil Sainty
2022-01-16  7:22       ` Eli Zaretskii
2022-01-16  9:58         ` Phil Sainty [this message]
2022-01-16 10:18           ` Eli Zaretskii
2022-01-16 10:23             ` Eli Zaretskii
2022-01-16 11:08               ` Phil Sainty
2022-01-16 10:55             ` Phil Sainty
2022-01-16 11:03               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce505094517a15ace28660dcf4096653@webmail.orcon.net.nz \
    --to=psainty@orcon.net.nz \
    --cc=52163@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=iung@autistici.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).