visual line mode

[drain]

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).



--
View this message in context: http://emacs.1067599.n5.nabble.com/visual-line-mode-tp266925.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

[Tassilo Horn]

drain <aeu...@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.

Bye,
Tassilo

[Eli Zaretskii]

> Date: Thu, 11 Oct 2012 23:56:48 -0700 (PDT)
> From: drain <aeu...@gmail.com>

>
> Also, why is the default to have wrapping in the middle of words?

It isn't. visual-line-mode wraps between words, except when a single
word is wider than a line.

[Tassilo Horn]

Eli Zaretskii <el...@gnu.org> writes:

>> Also, why is the default to have wrapping in the middle of words?
>
> It isn't. visual-line-mode wraps between words, except when a single
> word is wider than a line.

But visual-line-mode is not the default. (That's how I've interpreted
the question.)

Bye,
Tassilo

[drain]

Tassilo Horn-6 wrote
> Eli Zaretskii &lt;

> eliz@

Indeed, that's what I meant: why isn't visual line mode the default?

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.



--
View this message in context: http://emacs.1067599.n5.nabble.com/visual-line-mode-tp266925p266940.html

[Peter Dyballa]

Am 12.10.2012 um 12:35 schrieb drain:

> Indeed, that's what I meant: why isn't visual line mode the default?

Because it's so awful.

--
Greetings

Pete

Ce qui a été compris n'existe plus.
(Paul Eluard)

[drain]

Because it's so awful.

Peter Dyballa wrote

Can you elaborate?



--
View this message in context: http://emacs.1067599.n5.nabble.com/visual-line-mode-tp266925p266943.html

[Eli Zaretskii]

> Date: Fri, 12 Oct 2012 03:35:15 -0700 (PDT)
> From: drain <aeu...@gmail.com>
>

> >>> Also, why is the default to have wrapping in the middle of words?
> >>
> >> It isn't. visual-line-mode wraps between words, except when a single
> >> word is wider than a line.
> >
> > But visual-line-mode is not the default. (That's how I've interpreted
> > the question.)
> >
> > Bye,
> > Tassilo
>

> Indeed, that's what I meant: why isn't visual line mode the default?

Because Emacs is first and foremost a programmer's editor, and
wrapping lines in a buffer that shows program source is a bad idea.

[Peter Dyballa]

Am 12.10.2012 um 12:48 schrieb drain:

> Can you elaborate?

I can't see where lines end and where new line starts. Cursor behaviour/moving in the text is strange.

--
Greetings

Pete

Typography exists to honor content.
– Robert Bringhurst

[Tassilo Horn]

drain <aeu...@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).

Bye,
Tassilo

[Tassilo Horn]

Peter Dyballa <Peter_...@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).

Bye,
Tassilo

[drain]

Tassilo Horn-6 wrote
> drain &lt;

> aeuster@

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.



--
View this message in context: http://emacs.1067599.n5.nabble.com/visual-line-mode-tp266925p266949.html

[Eli Zaretskii]

> From: Peter Dyballa <Peter_...@Web.DE>
> Date: Fri, 12 Oct 2012 13:27:09 +0200
> Cc: Help-gn...@gnu.org

>
> Cursor behaviour/moving in the text is strange.

Strange in what ways? Can you give an example?

[Tassilo Horn]

drain <aeu...@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?

Bye,
Tassilo

[Eli Zaretskii]

> From: Tassilo Horn <ts...@gnu.org>
> Date: Fri, 12 Oct 2012 13:36:33 +0200

>
> Peter Dyballa <Peter_...@Web.DE> writes:
>
> >> Can you elaborate?
> >
> > I can't see where lines end and where new line starts.
>
> The fringe indicators help.

What fringe indicators? You mean, if visual-line-fringe-indicators
are customized?

[drain]

Tassilo Horn-6 wrote

> 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.

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.



--
View this message in context: http://emacs.1067599.n5.nabble.com/visual-line-mode-tp266925p266967.html

[Peter Dyballa]

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…

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.

[Peter Dyballa]

Am 12.10.2012 um 13:36 schrieb Tassilo Horn:

>> I can't see where lines end and where new line starts.
>
> The fringe indicators help.

They're much too many! It's like with the wood and the trees in it…

--
Greetings

Pete

If you don't find it in the index, look very carefully through the entire catalogue.
– Sears, Roebuck, and Co., Consumer's Guide, 1897

[Peter Dyballa]

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?
>

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

[Eli Zaretskii]

> From: Peter Dyballa <Peter_...@Web.DE>
> Date: Fri, 12 Oct 2012 17:55:13 +0200
> Cc: Help-gn...@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

A recipe, please.

[Eli Zaretskii]

> From: Peter Dyballa <Peter_...@Web.DE>
> Date: Fri, 12 Oct 2012 17:46:04 +0200
> Cc: Help-gn...@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.

[Peter Dyballa]

Am 12.10.2012 um 18:30 schrieb Eli Zaretskii:

>> 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

[Eli Zaretskii]

> From: Peter Dyballa <Peter_...@Web.DE>
> Date: Fri, 12 Oct 2012 23:40:33 +0200
> Cc: Help-gn...@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.

[Eli Zaretskii]

> From: Peter Dyballa <Peter_...@Web.DE>
> Date: Sat, 13 Oct 2012 00:06:13 +0200
> Cc: Help-gn...@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:

I cannot reproduce this. Can you give a recipe?

[Peter Dyballa]

Am 13.10.2012 um 09:36 schrieb Eli Zaretskii:

> 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

[Eli Zaretskii]

> From: Peter Dyballa <Peter_...@Web.DE>
> Date: Sat, 13 Oct 2012 17:26:13 +0200
> Cc: Help-gn...@gnu.org

>
> what I miss is that it does not jump to column 61 where the other line actually ends but stayed in column 47.

Sorry, but this is not helpful. Column 61 and column 47 don't say
anything to me, unless you show a precise recipe, starting with
"emacs -Q", that would explain what you expect Emacs to do.

> 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?

This is either due to a bug or to some customization (most probably
the latter). Again, please give a recipe to reproduce such a
behavior. It should never happen, and has nothing to do with
visual-line-mode.

[Peter Dyballa]

Am 13.10.2012 um 09:41 schrieb Eli Zaretskii:

> (Why do you care about how columns
> increase/decrease? For that matter, why do you turn on
> column-number-mode at all?)

Because columns play an important role in *shell* buffer: if the cursor or line length is around 1,000 it can happen that this lengthy command cannot be executed.

While trying to find this or that recipe you requested, I found that effect:

Create a file containing that line with TABS between "6)" and "von":

Tausendschönchen (Sedmikrasky) (1966) von Vera Chytilová

Launch GNU Emacs with -Q and visit that file read-only. Activate visual line mode. Resize the frame's width to 15 columns ("C-a C-u 14 C-f" should put the cursor into the last, right-most column). Position the cursor at the SPACE in the name "Vera Chytilová" and use the cursor movement keys to make the text cursor move upwards. In the visible line with TABs it will not go upwards but leftwards, in a left-to-right script one TAB backwards, as it will do on the visible line above, where UP makes it jump to column 0, i.e., left of "(1966)". On next UP it's back in the column where the cursor started.

When I position the text cursor with the mouse on the second "n" in "Tausendschönchen" and then press CURSOR DOWN it jumps over all the TABs after "(1966)" and lands on the "a" in "Very Chytilová" instead of the SPACE…

>
>> 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?

I certainly have to click a lot more. What I encountered is that I clicked into column X on some line and repeatedly the text from the last column until where I clicked was high-lighted. Or when I clicked into column Y on some other line the text cursor was put into column (X - N).

>
>
>> 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:
>
> I cannot reproduce this. Can you give a recipe?
>

I cannot reproduce that as well – because I failed to see that the text was

% \DeclareGraphicsExtensions{.pdf,.png,.jpeg}

which was broken into what you see in the screen-shot. But what I can do with the text line

% \DeclareGraphicsExtensions{.pdf,.png,.jpeg} % in pdfTeX allowed graphics formats

is:

a) position the cursor in column 0 on the "%"
b) perform RIGHT C-u C-x = RIGHT C-u C-x = RIGHT C-u C-x = RIGHT C-u C-x = (this is exactly four times right on exactly one SPACE character)

The *Messages* buffer contains:

Char: % (37, #o45, #x25) point=2577 of 37255 (7%) column=0

Char: SPC (32, #o40, #x20) point=2578 of 37255 (7%) column=1

Char: SPC (32, #o40, #x20) point=2579 of 37255 (7%) column=2

Char: SPC (32, #o40, #x20) point=2580 of 37255 (7%) column=3

Char: SPC (32, #o40, #x20) point=2581 of 37255 (7%) column=4

And here is an excerpt, the end, of *Help* buffer:

<down-mouse-1> <mouse-movement>
<mouse-1> C-a C-u C-x = <right> C-u C-x = <right> C-u
C-x = <right> C-u C-x = <right> C-u C-x = <down-mouse-1>
<mouse-movement> <mouse-1> <down-mouse-1> <mouse-movement>
<mouse-movement> <drag-mouse-1> <down-mouse-1> <mouse-movement>
<mouse-1> C-a <right> <right> <right> <right> <right>
<help-echo> <down-mouse-1> <mouse-1> C-x b * M e s
s <tab> <return> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <down-mouse-1> <mouse-movement> <mouse-1>
<down-mouse-1> <mouse-movement> <mouse-movement> <help-echo>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <drag-mouse-1> <down-mouse-1> <mouse-movement>
<mouse-1> <help-echo> C-h l


Eli, right now and possibly the next few years I am not and shall not be interested in visual-line-mode. I don't like it and I shall not like it presumingly another few years long. Whether it has bugs or not – I don't care. During the described period of time I think working on visual-line-mode will be a waste of time for me. For me less annoying and more satisfying thing exist, so I am stopping now this thread for me. If you want, then I can send you the two files I used for "testing". I was using the Lucid/Xaw3d variant of a recently, 10.10., updated GNU Emacs 24.2.50.

I prefer to have a GNU Emacs that is as true and reliable as Honest John, the sheriff with the hat of the Mounted Police, played by W.C. Fields, in the film “Six Of A Kind”, who explains at a billiard pool why he carries the honourable name "Honest". (I also don't like org-mode. It's cheating as well. IMO. And I don't want to explain that and return to that trauma.) GNU Emacs should stay a reliable computer programme and not quantum physics where nothing is certain, only more or less likely. I like tools that *I* can control, not the other way round.
honourable
--
Greetings

Pete

Be careful of reading health books, you might die of a misprint.
– Mark Twain

[Bob Proulx]

Peter Dyballa wrote:
> While trying to find this or that recipe you requested, I found that effect:

> ...

I believe that effect is due to the basic incompatibility of tabs and
visual-line-mode. Trying to position the cursor on any of the screen
whitespace of a tab expansion means that the cursor will be displayed
on the beginning of the tab whitespace. In the proposed example this
causes the cursor to back up into the next line above skipping the
actual visual line. And looks crazy. If the line has tabs expanded
then the case is avoided. I think. At least for that case.

BTW add me to the list of people who does not like and cannot stand
visual-line-mode. I understand it. I don't like it. It makes a
terrible default.

Bob

[Eli Zaretskii]

> From: Peter Dyballa <Peter_...@Web.de>
> Date: Sat, 13 Oct 2012 23:54:54 +0200
> Cc: Help-gn...@gnu.org

>
> Create a file containing that line with TABS between "6)" and "von":
>
> Tausendschönchen (Sedmikrasky) (1966) von Vera Chytilová
>
> Launch GNU Emacs with -Q and visit that file read-only. Activate visual line mode. Resize the frame's width to 15 columns ("C-a C-u 14 C-f" should put the cursor into the last, right-most column). Position the cursor at the SPACE in the name "Vera Chytilová" and use the cursor movement keys to make the text cursor move upwards. In the visible line with TABs it will not go upwards but leftwards, in a left-to-right script one TAB backwards, as it will do on the visible line above, where UP makes it jump to column 0, i.e., left of "(1966)". On next UP it's back in the column where the cursor started.
>
> When I position the text cursor with the mouse on the second "n" in "Tausendschönchen" and then press CURSOR DOWN it jumps over all the TABs after "(1966)" and lands on the "a" in "Very Chytilová" instead of the SPACE…

These are bugs.

> > 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?
>
> I certainly have to click a lot more. What I encountered is that I clicked into column X on some line and repeatedly the text from the last column until where I clicked was high-lighted. Or when I clicked into column Y on some other line the text cursor was put into column (X - N).

I don't see this problem.

> % \DeclareGraphicsExtensions{.pdf,.png,.jpeg} % in pdfTeX allowed graphics formats
>
> is:
>
> a) position the cursor in column 0 on the "%"
> b) perform RIGHT C-u C-x = RIGHT C-u C-x = RIGHT C-u C-x = RIGHT C-u C-x = (this is exactly four times right on exactly one SPACE character)
>
> The *Messages* buffer contains:
>
> Char: % (37, #o45, #x25) point=2577 of 37255 (7%) column=0
>
> Char: SPC (32, #o40, #x20) point=2578 of 37255 (7%) column=1
>
> Char: SPC (32, #o40, #x20) point=2579 of 37255 (7%) column=2
>
> Char: SPC (32, #o40, #x20) point=2580 of 37255 (7%) column=3
>
> Char: SPC (32, #o40, #x20) point=2581 of 37255 (7%) column=4

I don't see this, either. I get the correct characters shown in the
echo area and in *Messages*.

> I prefer to have a GNU Emacs that is as true and reliable as Honest John, the sheriff with the hat of the Mounted Police, played by W.C. Fields, in the film “Six Of A Kind”, who explains at a billiard pool why he carries the honourable name "Honest".

It will never be that.

[drain]

VLM is a disaster in dired and when browsing Emacs packages
(el-get-list-packages).



--
View this message in context: http://emacs.1067599.n5.nabble.com/visual-line-mode-tp266925p267304.html

[Matt McClure]

On Fri, Oct 12, 2012 at 9:32 AM, Eli Zaretskii <el...@gnu.org> wrote:
> What fringe indicators? You mean, if visual-line-fringe-indicators
> are customized?

Why does visual-line-mode turn off fringe indicators by default? IMO
there's little disadvantage to turning them on, if any, and it helps
me distinguish which line breaks are in the text itself versus which
are only in the view.

--
Matt McClure
http://www.matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure

[Eli Zaretskii]

> Date: Wed, 28 Nov 2012 10:06:47 -0500
> From: Matt McClure <matthew...@gmail.com>
> Cc: "help-gn...@gnu.org" <help-gn...@gnu.org>

>
> Why does visual-line-mode turn off fringe indicators by default?

I guess because it looked weird to have the indicators when the line
appears to be shorter than the window width.

Anyway, why do you care about the defaults? Emacs makes it very easy
to customize that.

[Matt McClure]

On Wednesday, November 28, 2012, Eli Zaretskii wrote:

> Date: Wed, 28 Nov 2012 10:06:47 -0500
> From: Matt McClure <matthew...@gmail.com>
> Cc: "help-gn...@gnu.org" <help-gn...@gnu.org>
>
> Why does visual-line-mode turn off fringe indicators by default?

Anyway, why do you care about the defaults?  Emacs makes it very easy

to customize that.

Because I lived with some awkward behavior (can't put my finger on exactly what) for months before I thought to search for a way to reenable fringe indicators.  And I care too much about others' experience. ;-)

[Stefan Monnier]

>> What fringe indicators? You mean, if visual-line-fringe-indicators
>> are customized?

> Why does visual-line-mode turn off fringe indicators by default?

Good, question, I can't remember the answer, tho.
I can guess at a few possibilities:
- "knee-jerk" reaction along the lines of "so you want word wrapping
like the other crap editors? well, I'll give you just that, then".
I don't think we were so thoughtless, but there might have been
the reasoning that "since other word-wrapping editors don't show
indicators, it should be OK if we do the same".
- if you have "one logical line per paragraph", then your fringes would
be pretty much full of indicators everywhere, except at paragraph
boundaries, which ends up being neither pretty nor convenient.

For the "most lines are long" case mentioned in point 2, a better
approach would be to put a fringe indicator only at
paragraph boundaries.


Stefan

[Matt McClure]

On Nov 29, 2012, at 8:51 AM, Stefan Monnier <mon...@iro.umontreal.ca> wrote:

> For the "most lines are long" case mentioned in point 2, a better
> approach would be to put a fringe indicator only at
> paragraph boundaries.

I like that idea.

Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure