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