longlines-mode and visual-line-mode

longlines-mode and visual-line-mode

[Leo]

Hi there,

After briefly trying these two modes, I haven't found any significant
difference between them. It looks like longlines has all the features
for visual-line-mode. Is my impression correct? Thank you.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

Re: longlines-mode and visual-line-mode

[Deniz Dogan]

2009/5/31 Leo <sdl.web@gmail.com>:
> Hi there,
>
> After briefly trying these two modes, I haven't found any significant
> difference between them. It looks like longlines has all the features
> for visual-line-mode. Is my impression correct? Thank you.
>
> --
> .:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.
>
>
>
>

This is not the case, as I understand it.  For an example, fill a
buffer with a very long line in longlines-mode and resize the window.
Then turn it off and switch to visual-line-mode and resize the window.
 Notice the difference!  visual-line-mode turns on word-wrap (a
variable) which is what gives this differente behaviour.

IIRC, longlines-mode is/was a hack which was introduced due to the
lack of something like word-wrap in earlier versions of Emacs.

-- 
Deniz Dogan

Re: longlines-mode and visual-line-mode

[Miles Bader]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:
>> After briefly trying these two modes, I haven't found any significant
>> difference between them. It looks like longlines has all the features
>> for visual-line-mode. Is my impression correct? Thank you.
>
> This is not the case, as I understand it.  For an example, fill a
> buffer with a very long line in longlines-mode and resize the window.
> Then turn it off and switch to visual-line-mode and resize the window.
>  Notice the difference!  visual-line-mode turns on word-wrap (a
> variable) which is what gives this differente behaviour.
>
> IIRC, longlines-mode is/was a hack which was introduced due to the
> lack of something like word-wrap in earlier versions of Emacs.

Also of course, because longlines-mode _modifies_ the buffer to do it's
thing, it's more dangerous, far less efficient (think of a large
buffer...), and far more likely to interact in unforseen (and likely
bad) ways with various modes...

-Miles

-- 
White, adj. and n. Black.

Re: longlines-mode and visual-line-mode

[Leo]

On 2009-05-31 17:26 +0100, Deniz Dogan wrote:
> 2009/5/31 Leo <sdl.web@gmail.com>:
>> Hi there,
>>
>> After briefly trying these two modes, I haven't found any significant
>
>> difference between them. It looks like longlines has all the features
>> for visual-line-mode. Is my impression correct? Thank you.
>>
>
> This is not the case, as I understand it.  For an example, fill a
> buffer with a very long line in longlines-mode and resize the window.
> Then turn it off and switch to visual-line-mode and resize the window.
>  Notice the difference!  visual-line-mode turns on word-wrap (a
> variable) which is what gives this differente behaviour.
>
> IIRC, longlines-mode is/was a hack which was introduced due to the
> lack of something like word-wrap in earlier versions of Emacs.

After (setq longlines-wrap-follows-window-size 10), I haven't noticed
any difference.

Could you elaborate the different you were referring to? Thanks.

Leo

Re: longlines-mode and visual-line-mode

[Deniz Dogan]

2009/5/31 Leo <sdl.web@gmail.com>:
> On 2009-05-31 17:26 +0100, Deniz Dogan wrote:
>> 2009/5/31 Leo <sdl.web@gmail.com>:
>>> Hi there,
>>>
>>> After briefly trying these two modes, I haven't found any significant
>>
>>> difference between them. It looks like longlines has all the features
>>> for visual-line-mode. Is my impression correct? Thank you.
>>>
>>
>> This is not the case, as I understand it.  For an example, fill a
>> buffer with a very long line in longlines-mode and resize the window.
>> Then turn it off and switch to visual-line-mode and resize the window.
>>  Notice the difference!  visual-line-mode turns on word-wrap (a
>> variable) which is what gives this differente behaviour.
>>
>> IIRC, longlines-mode is/was a hack which was introduced due to the
>> lack of something like word-wrap in earlier versions of Emacs.
>
> After (setq longlines-wrap-follows-window-size 10), I haven't noticed
> any difference.
>
> Could you elaborate the different you were referring to? Thanks.
>
> Leo
>

I think Miles explained it pretty well...  longlines-mode does roughly
the same thing by actually modifying the buffer contents.  It's rare
to actually see this break anything, but I've experienced myself when
blogging from Emacs using, among other things, Muse.  longlines-mode
is simply the wrong thing to use now that we have real word-wrapping
with visual-line-mode and word-wrap.

-- 
Deniz Dogan

Re: longlines-mode and visual-line-mode

[David Reitter]

On May 31, 2009, at 1:11 PM, Leo wrote:
> After (setq longlines-wrap-follows-window-size 10), I haven't noticed
> any difference.
>
> Could you elaborate the different you were referring to? Thanks.

Try using a variable-width font, perhaps with at least some lines in a  
larger font, as in AUCTeX's latex-mode (section headings) - you should  
notice missed or over-eager line breaks in longlines-mode.

Also, try editing a sufficiently large file, and then resize the  
window - you may notice slowness in longlines-mode.

Is there still a need for longlines?
We may want to get rid of it, using some aliases to switch users to  
using word-wrap.

Re: longlines-mode and visual-line-mode

[Leo]

On 2009-05-31 18:03 +0100, Miles Bader wrote:
[...]
> Also of course, because longlines-mode _modifies_ the buffer to do it's
> thing, it's more dangerous, far less efficient (think of a large
> buffer...), and far more likely to interact in unforseen (and likely
> bad) ways with various modes...
>
> -Miles
On 2009-05-31 18:17 +0100, Deniz Dogan wrote:
[...]
>
> I think Miles explained it pretty well...  longlines-mode does roughly
> the same thing by actually modifying the buffer contents.  It's rare
> to actually see this break anything, but I've experienced myself when
> blogging from Emacs using, among other things, Muse.  longlines-mode
> is simply the wrong thing to use now that we have real word-wrapping
> with visual-line-mode and word-wrap.
On 2009-05-31 18:21 +0100, David Reitter wrote:
[...]
> Try using a variable-width font, perhaps with at least some lines in a
> larger font, as in AUCTeX's latex-mode (section headings) - you should
> notice missed or over-eager line breaks in longlines-mode.
>
> Also, try editing a sufficiently large file, and then resize the
> window - you may notice slowness in longlines-mode.

I have now seen the difference. Thank you, Deniz, David and Miles.

> Is there still a need for longlines? We may want to get rid of it,
> using some aliases to switch users to using word-wrap.

I also think longlines should be marked obsolete for 23.1.


Leo

Re: longlines-mode and visual-line-mode

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

>> Is there still a need for longlines? We may want to get rid of it,
>> using some aliases to switch users to using word-wrap.
>
> I also think longlines should be marked obsolete for 23.1.

I'm planning to do this post 23.1.

Re: longlines-mode and visual-line-mode

[MON KEY]

Was surprised to learn today of a new mode to rival
visual-line-mode... Lone Lines Mode - presumably for Texans!

`emacs-23.0.94/info/emacs-3  @line 1611 column 28 there is a typo:
``Unlike Visual Line mode, Lone Lines mode breaks long lines at the fill''
should be ``Long Lines'' - I hope :P
see diff below
---
>> I also think longlines should be marked obsolete for 23.1.

> I'm planning to do this post 23.1.

How does visual-lines-mode mirror longlines-mode functionality w/re
softlines at fill-column?
`
From what I can gather from the docs visual-line-mode and word-wrap are
wrapped at the fringe whereas longlines mode can _line wrap_  at an
arbitrary buffer or mode local fill column setting.

If indeed visual-line-mode and longlines-mode offer reasonably
identical behavior, how does one duplicate the longlines effect with
visual-lines-mode?
Neither the docstrings or the manual are clear about this vis a vis
filling when visual-lines-mode is non-nil.

FWIW, I have come to rely on longlines mode for certain types of
functionality and have also managed to kludge together more than one
function to accomodate it's idiosyncrasies.  While I have no objection
to abandoning longlines-mode this should not be at the loss of the
line-wrapping it has to offer.

(info "(emacs)Visual Line Mode")
"Here, each long logical line is divided into two or more screen
lines, like in ordinary line continuation.  However, Emacs attempts to
wrap the line at word boundaries near the right window edge."

Per `longlines-mode' docstring:
"In Long Lines mode, long lines are wrapped if they extend beyond
`fill-column'.  The soft newlines used for line wrapping will not
show up when the text is yanked or saved to disk.

(info (emacs)Continuation Lines")
"This is called "line wrapping" or "continuation", and the long
logical line is called a "continued line".


----------------------------------------------------------------
*** /home/sp/local-emacs/emacs-23.0.94/info/mm	
--- /home/sp/local-emacs/emacs-23.0.94/info/emacs-3	
***************
*** 1608,1614 ****
  "soft newlines" as you type (*note Hard and Soft Newlines::).  These
  soft newlines won't show up when you save the buffer into a file, or
  when you copy the text into the kill ring, clipboard, or a register.
! Unlike Visual Line mode, Long Lines mode breaks long lines at the fill
  column (*note Fill Commands::), rather than the right window edge.  To
  enable Long Lines mode, type `M-x longlines-mode'.  If the text is full
  of long lines, this also immediately "wraps" them all.
--- 1608,1614 ----
  "soft newlines" as you type (*note Hard and Soft Newlines::).  These
  soft newlines won't show up when you save the buffer into a file, or
  when you copy the text into the kill ring, clipboard, or a register.
! Unlike Visual Line mode, Lone Lines mode breaks long lines at the fill
  column (*note Fill Commands::), rather than the right window edge.  To
  enable Long Lines mode, type `M-x longlines-mode'.  If the text is full
  of long lines, this also immediately "wraps" them all.
--------------------------------------------------------------------

Re: longlines-mode and visual-line-mode

[Leo]

On 2009-06-01 01:53 +0100, MON KEY wrote:
>>> I also think longlines should be marked obsolete for 23.1.
>
>> I'm planning to do this post 23.1.
>
> How does visual-lines-mode mirror longlines-mode functionality w/re
> softlines at fill-column?
> `
> From what I can gather from the docs visual-line-mode and word-wrap are
> wrapped at the fringe whereas longlines mode can _line wrap_  at an
> arbitrary buffer or mode local fill column setting.

Marking it obsolete does not mean its going to disappear. You can still
reply on it. But it should be discouraged given that the functionality
is not properly implemented. Then people can focus on improving the new
visual-line-mode.

Leo

Re: longlines-mode and visual-line-mode

[Stefan Monnier]

>>>> I also think longlines should be marked obsolete for 23.1.
>>> I'm planning to do this post 23.1.
>> How does visual-lines-mode mirror longlines-mode functionality w/re
>> softlines at fill-column?
>> From what I can gather from the docs visual-line-mode and word-wrap are
>> wrapped at the fringe whereas longlines mode can _line wrap_  at an
>> arbitrary buffer or mode local fill column setting.
> Marking it obsolete does not mean its going to disappear.

Actually, it does say that we intend to remove it in some future version
of Emacs.

> You can still reply on it.

Only in the "short" term (e.g. it might not be in Emacs-24).

Of course, an obsolete mode could potentially be de-obsoleted if it
turns out that many people like some of its unique features which
can't or won't be added to the mode that was meant to replace it.
I don't think it's ever happened, tho.


        Stefan

Re: longlines-mode and visual-line-mode

[MON KEY]

> Marking it obsolete does not mean its going to disappear. You can still

Understood.

> reply on it. But it should be discouraged given that the functionality
> is not properly implemented.

Respectfully, I'll be taking that one with a not too small lump of
salt given your initial inquiry:

"After briefly trying these two modes, I haven't found any significant
difference between them."

> Then people can focus on improving the new visual-line-mode.

This does not in any way address either of my principal inquiries (nor
yours for that matter...)

While I understand, appreciate, and respect the sentiment - improving
V-L-M simply because it is _new_ strikes me as wrong-headed in the
worst way.

If L-L-M is fundamentally flawed in ways that V-L-M isn't, it is most
important to understand the nature of those flaws; how and where they
occur; why they arose in the first place; and how or why they
can/should be avoided when improving V-L-M.

I am aware that Mr. Yidong had a hand in maintaining longlines-mode. I
suspect he will spearhead future extension of V-L-M capability.

It would seem that Mr. Yidong is publicly hinting at deprecating L-L-M
in favor of V-L-M in upcoming releases.

Great! L-L-M _is_ backward headed on more than one count... hence the
kludges I alluded to earlier.

That said, given the recent furor over line-move-visual _now_ would
seem a reasonable time to begin airing out the extant gaps of V-L-M
which L-L-M is/can/will continue to mitigate during the transition.

Investigating how users such as myself might expect V-L-M to
accommodate those aspects of L-L-M which _are_ worth preserving seems
fundamental to a focused approach towards improving V-L-M and
supporting ancillary code/packages which are
developed/ported/re-factored in lieu of any such improvements.

s_P

Re: longlines-mode and visual-line-mode

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jun 01, 2009 at 01:14:03AM -0400, MON KEY wrote:
> > Marking it obsolete does not mean its going to disappear. You can still
> 
> Understood.

[...]

> If L-L-M is fundamentally flawed in ways that V-L-M isn't, it is most
> important to understand the nature of those flaws; how and where they
> occur; why they arose in the first place; and how or why they
> can/should be avoided when improving V-L-M.

As one data point, I'm working on a set of programs to represent mark-up
in buffers with the help of text properties and mark-up. Those get very
confused with the newlines inserted by longlines-mode whereas they work
flawlessly with v-l-m (it has been mentioned upthread that l-l-m
modifies the buffer, so this is a confirmation that yes, v-l-m seems
much more probable to interact well with other apps).

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKI6WZBcgs9XrR2kYRAp2qAJ4gzCN3qdD++JpvqKIUpu0tY7vhLQCfa083
o0H/1zjxUvmufbBlvh3jRmQ=
=QaI5
-----END PGP SIGNATURE-----

Re: longlines-mode and visual-line-mode

[Lennart Borgman]

On Mon, Jun 1, 2009 at 11:55 AM,  <tomas@tuxteam.de> wrote:
>
> As one data point, I'm working on a set of programs to represent mark-up
> in buffers with the help of text properties and mark-up. Those get very
> confused with the newlines inserted by longlines-mode whereas they work
> flawlessly with v-l-m (it has been mentioned upthread that l-l-m
> modifies the buffer, so this is a confirmation that yes, v-l-m seems
> much more probable to interact well with other apps).

I can confirm such experiences.

Re: longlines-mode and visual-line-mode

[Leo]

On 2009-06-01 06:14 +0100, MON KEY wrote:
> Respectfully, I'll be taking that one with a not too small lump of
> salt given your initial inquiry:
>
> "After briefly trying these two modes, I haven't found any significant
> difference between them."

That's my initial impression at the first time when I was trying to
decide which one is better to use. Other people's comments have made me
aware of llm's defects, which you can see yourself.

Anyway, I believe the following is useful but still missing in v-l-m, a
variable to control the width, i.e. if it is positive integer, it
controls the length of the line, otherwise it is the distance from the
window edge to the right-most char of the line.


Leo

Re: longlines-mode and visual-line-mode

[MON KEY]

> Anyway, I believe the following is useful but still missing in v-l-m, a
> variable to control the width, i.e. if it is positive integer, it
> controls the length of the line, otherwise it is the distance from the
> window edge to the right-most char of the line.

Realized this evening where Mr. Yidong may be looking to -> grapheme-clusters.

Now that the underlying Emacs encoding is "..to Unicode and Beyond"
this would seem a likely approach esp. coupled with the users
language-environment settings.

Fancy that...

(defun my-grapheme-fuzz-factor-pref ()
  (if (and (member
	    (cdr (assoc 'major-mode (buffer-local-variables)))
	    '(language-o-choice-mode
	      language-o-plenty-mode
	      emacs-rdf-graph-navigator-mode))
	   (and (assoc 'syntax-table text-property-default-nonsticky)
	   (cdr (assoc 'syntax-table text-property-default-nonsticky))))
  (setq right-most-grapheme-avoidance 3)))

  (set (make-local-variable 'grapheme-wrap-fuzz-factor) nil)))

  (add-hook 'buffer-grapheme-wrap-fuzziness-hook 'my-grapheme-fuzz-factor-pref)

Or, for the bidi bound - test for a front-skicky instead in
`my-grapheme-fuzz-factor-pref' and

  (setq left-most-grapheme-avoidance 3)  instead :)