[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29664: 26.0.90; Auto Hscroll Mode + Visual Line Mode + Truncate don'
From: |
Eli Zaretskii |
Subject: |
bug#29664: 26.0.90; Auto Hscroll Mode + Visual Line Mode + Truncate don't work well together |
Date: |
Tue, 12 Dec 2017 05:30:17 +0200 |
> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 11 Dec 2017 21:07:50 +0000
> Cc: 29664@debbugs.gnu.org
>
> Why are you turning on both visual-line-mode and truncate-lines?
> These are mutually exclusive: the former is for wrapping long
> continued lines, the latter is for not continuing lines at all.
>
> What am I missing?
>
> Yes, I understand that. But they were both enabled by mistake.
>
> - The visual line mode was enabled by default in org-mode-hook
> - And I happened to have "# eval: (toggle-truncate-lines 1)" in the Local
> Variables footer in one of the Org files.
>
> There were no signs of problem until C-a and C-e started misbehaving that
> way.
>
> Should emacs do the "right thing" and auto-disable the other if one got
> enabled, or throw a warning?
I'm not sure it should, but at least what you see is expected when you
mix these modes, they are incompatible and utterly confuse the display
engine.
> This problem with C-a and C-e does not happen if skip this part in the test
> setup:
>
> (setq auto-hscroll-mode 'current-line)
>
> - C-a works perfectly
> - C-e does not jump instantly to the EOL, but progressively goes to the EOL
> on hitting C-e, and eventually gets
> there (interesting behavior).
(So not really "no problem".)
> So at least with the default value of auto-hscroll-mode, a user is not stuck
> wondering why C-a/C-e stopped
> working, even if they enabled visual-line-mode and toggle-truncate-lines
> simultaneously by mistake.
If someone wants to propose a patch to warn the user in this case, I
don't object.
> PS: I noticed that the email client or the debbugs server auto-inserted
> newlines in my test function.
I see no such newlines in the mail message I received.