What's the best way to enable this in every mode, under all conditions, as
the default? Right now I have a bunch of hooks for el / C / org, etc., but
not shell or dired.
Also, why is the default to have wrapping in the middle of words? (probably
a question for Emacs devs).
drain <aeus...@gmail.com> writes:
> What's the best way to enable this in every mode, under all
> conditions, as the default? Right now I have a bunch of hooks for el
> / C / org, etc., but not shell or dired.
Put (global-visual-line-mode) in your ~/.emacs.
> Also, why is the default to have wrapping in the middle of words?
> (probably a question for Emacs devs).
Then the text is displayed as-is. With word wrapping, you cannot judge
how many whitespaces are between the last word on line N and the first
word on line N+1.
drain <aeus...@gmail.com> writes:
> Indeed, that's what I meant: why isn't visual line mode the default?
I agree with everything Eli & Peter said. ;-)
> global-visual-line-mode is better, but not global: my draft buffers
> still wrap in the middle of words. I have to turn on visual-line-mode
> manually.
Is it possibly that you still have visual-line-mode in some hooks? What
you describe sounds like global-visual-line-mode first turns on VLM in
your draft buffer, and then your hook turns it off again (or the other
way round).
Peter Dyballa <Peter_Dyba...@Web.DE> writes:
>> Can you elaborate?
> I can't see where lines end and where new line starts.
The fringe indicators help.
> Cursor behaviour/moving in the text is strange.
Depends. I use visual-line-mode when I need to write LaTeX documents
with other people that always write a paragraph on one line, and
basically everybody that doesn't use Emacs does so. In those
situations, VLM is really an improvement. It's even better with
`adaptive-wrap-prefix-mode' (package adaptive-wrap in ELPA).
>> Indeed, that's what I meant: why isn't visual line mode the default?
> I agree with everything Eli & Peter said. ;-)
>> global-visual-line-mode is better, but not global: my draft buffers
>> still wrap in the middle of words. I have to turn on visual-line-mode
>> manually.
> Is it possibly that you still have visual-line-mode in some hooks? What
> you describe sounds like global-visual-line-mode first turns on VLM in
> your draft buffer, and then your hook turns it off again (or the other
> way round).
> Bye,
> Tassilo
Not that I am aware of. When you launch compose-mail with global-visual-line
mode (merely to reproduce my conditions), does it work for you?
Given the amount of visual-line-mode backlash, I suppose I should confine it
to non-code docs.
drain <aeus...@gmail.com> writes:
>> Is it possibly that you still have visual-line-mode in some hooks?
>> What you describe sounds like global-visual-line-mode first turns on
>> VLM in your draft buffer, and then your hook turns it off again (or
>> the other way round).
> Not that I am aware of. When you launch compose-mail with
> global-visual-line mode (merely to reproduce my conditions), does it
> work for you?
Ah, ok. When I do:
1. emacs -Q
2. M-x global-visual-line-mode
3. M-x compose-mail RET
I get an *unsent mail* buffer in message-mode. `visual-line-mode' is
indeed active, but message-mode also activates `auto-fill-mode' which
automatically inserts hard line breaks after 72 chars by default.
So basically, you could add
(add-hook 'message-mode-hook 'turn-off-auto-fill)
to have `visual-line-mode' work as expected in message-mode. But do you
really want to send such badly formatted mail?
> to have `visual-line-mode' work as expected in message-mode.
Works now. Though I should note it was MIME-edit-mode in my case (being a
Wanderlust user).
> But do you really want to send such badly formatted mail?
I like VLM primarily for reading, especially e-mails. For writing, for
archiving books / articles, etc., I set fill-column to 70 - 75 and
fill-paragraph, one paragraph at a time. Probably more efficient ways of
doing all this, but obviously I'm just starting out.
>> Cursor behaviour/moving in the text is strange.
> Strange in what ways? Can you give an example?
Not that easily. I remember that some development version of GNU Emacs 24 came with visual-line-mode on. For me it was hard to navigate, the cursor stopped in every /visible/ line and did not visit the next line of text…
Maybe there were more disturbing things this day. I did not like that experience. And hopefully I 'll be dead before GNU Emacs comes with visual-line-mode on!
--
Greetings
Pete
We have to expect it, otherwise we would be surprised.
>> Cursor behaviour/moving in the text is strange.
> Strange in what ways? Can you give an example?
One more example: the text cursor forgets where the end of the line was and seems to jump between the column it started to move and the visual end of the text.
--
Greetings
Pete
A designer knows he has arrived at perfection not when there is no longer anything to add, but when there is no longer anything to take away.
– Antoine de Saint-Exupéry
> From: Peter Dyballa <Peter_Dyba...@Web.DE>
> Date: Fri, 12 Oct 2012 17:55:13 +0200
> Cc: Help-gnu-em...@gnu.org
> One more example: the text cursor forgets where the end of the line
> was and seems to jump between the column it started to move and the
> visual end of the text
> From: Peter Dyballa <Peter_Dyba...@Web.DE>
> Date: Fri, 12 Oct 2012 17:46:04 +0200
> Cc: Help-gnu-em...@gnu.org
> Am 12.10.2012 um 15:28 schrieb Eli Zaretskii:
> >> Cursor behaviour/moving in the text is strange.
> > Strange in what ways? Can you give an example?
> Not that easily. I remember that some development version of GNU Emacs 24 came with visual-line-mode on. For me it was hard to navigate, the cursor stopped in every /visible/ line and did not visit the next line of text…
I think you are talking about bugs in early versions of the
bidirectional display engine.
>> One more example: the text cursor forgets where the end of the line
>> was and seems to jump between the column it started to move and the
>> visual end of the text
> A recipe, please.
Narrow the width of the window with text in Latin (left-to-right) script so that visual-line-mode puts long lines of text onto at least two lines. Now position the text cursor on the end of some line, say, at column 40 or 50, near an area where lines are broken onto at least two lines. Then start to move the text cursor into that area. On lines longer that those 40 or 50 columns it will stay in the starting column, on lines shorter it will reach the end of the line. Broken lines are visited more than once.
I prefer that the cursor stays at the line endings or visits broken lines only once.
--
Greetings
Pete
Every instructor assumes that you have nothing else to do except study for that instructor's course. – Fourth Law of Applied Terror
> From: Peter Dyballa <Peter_Dyba...@Web.DE>
> Date: Fri, 12 Oct 2012 23:40:33 +0200
> Cc: Help-gnu-em...@gnu.org
> Narrow the width of the window with text in Latin (left-to-right) script so that visual-line-mode puts long lines of text onto at least two lines. Now position the text cursor on the end of some line, say, at column 40 or 50, near an area where lines are broken onto at least two lines. Then start to move the text cursor into that area. On lines longer that those 40 or 50 columns it will stay in the starting column, on lines shorter it will reach the end of the line. Broken lines are visited more than once.
> I prefer that the cursor stays at the line endings or visits broken lines only once.
But that's exactly what visual-line-mode is about: it treats every
_screen_ line as if it were a physical line. IOW, this cursor motion
is a major, perhaps the main, feature of visual-line-mode. That's how
other applications behave, and that's why most users like
visual-line-mode.
As for the cursor not jumping to the end of line: Emacs cannot put the
cursor where there's no text. This is a basic design of the cursor
display in Emacs. The only exception I know of is picture-mode, and
that only happens there because AFAIR Emacs adds spaces to prolong the
line to the cursor position.
> From: Peter Dyballa <Peter_Dyba...@Web.DE>
> Date: Sat, 13 Oct 2012 00:06:13 +0200
> Cc: Help-gnu-em...@gnu.org
> > I think you are talking about bugs in early versions of the
> > bidirectional display engine.
> No, no, it still happens today. Maybe I am not finding the right words… The text cursor travels through every visible line of text, for example hitting the columns 12, 59, 107, … also these positions all belong to one long line of broken text. There is also no fixed rule by which the column number increases (or decreases when going towards the top of the buffer). This is really disturbing, I instantly assumed column-number-mode was broken.
You'd have to rethink that when you use visual-line-mode, those are
features, not bugs. (Why do you care about how columns
increase/decrease? For that matter, why do you turn on
column-number-mode at all?)
> And while I was testing this behaviour again it happened that I could not position by means of the mouse the cursor onto every column of a long broken line, i.e., most columns, for example those of the first part or the beginning of the broken line, could not be reached.
I have no problem with this when I try it now. Does it happen for you
in "emacs -Q", if you just turn on visual-line-mode?
> And there also lines segments containing the last part of a broken line that cannot be reached at all, neither with the mouse nor by using the cursor movement keys…
Are you again talking about putting the cursor beyond the text?
That's impossible in Emacs.
If you are talking about something else, please elaborate.
> And although I removed any white space on the lines after the (black) text had ended, I can see the cursor stay in that deleted white space:
> As for the cursor not jumping to the end of line: Emacs cannot put the
> cursor where there's no text.
This is as clear as a clear day. Or night. I would have reported a bug when I would have encountered something like that. And I was not complaining that the text cursor jumped from EOL (end of line) in column 47 to column 23 (when the line's so short, how can the text cursor stay far out in space?), what I miss is that it does not jump to column 61 where the other line actually ends but stayed in column 47.
OTOH, what I tried to show with my screen-shot looks exactly like something impossible: the text cursor beyond the end of the line of text. After the word "xdv2pdf" cannot be any white space because it was certainly removed before (I can't remember that replace-regexp was failing before) and because it was not shown in the other wider buffer. Was GNU Emacs a bit confused because the first part of the line it had to break was longer than the window is wide?
--
Greetings
Pete
We are usually convinced more easily by reasons we have found ourselves than by those which have occurred to others.
– Blaise Pascal
