On 04-Jun-2014 16:54 +0200, Павлов Николай  Александрович wrote:

On 04-Jun-2014 16:54, Павлов Николай Александрович wrote:>
> 
> On June 4, 2014 6:44:34 PM GMT+03:00, "Павлов Николай 
> Александрович" <zyx....@gmail.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
> 
> 
> 
>> On June 4, 2014 3:48:42 PM GMT+03:00, Ingo Karkat 
>> <sw...@ingo-karkat.de> wrote:
>>> On 04-Jun-2014 13:34 +0200, Axel Bender wrote:
>>> 
>>>> I'd already be happy if virtcol() would take into account
>>>> the length
>>> of the showbreak string. I'm otherwise prepared to work with 
>>> UTF-8 characters...
>>> 
>>> Character widths are not directly related to this, but that 
>>> little incorrectness in your otherwise precise and welcome bug 
>>> report shouldn't have provoked such a rant. Sorry.
>>> 
>>>> I consider this a flaw (well maybe a bug?) that should be 
>>>> fixed.
>>> 
>>> I can reproduce this issue with 7.4.264. Even worse, :set 
>>> linebreak also affects the virtcol() value and makes it wrong 
>>> (when such wrap
>> occurs).
>>> So, one only gets correct values out of virtcol() with :set 
>>> sbr=
>> nolbr;
>>> which indeed should be fixed!
> 
>> I am not sure it is a bug. Most likely it is absolutely correct 
>> behavior: pretend you need to know on which virtual line of the 
>> current line cursor is located and on which virtual column on 
>> this virtual line. Please describe how you will solve this with 
>> current behavior of virtcol() and with proposed one.
> 
>> Discussing whether this behavior is a bug or not is pointless 
>> without showing the use-case. I know that the above task may
>> only be solved with "bugged" virtcol(), otherwise you will have
>> to do option parsing for yourself which is a waste of time.
> 
> I have a use-case: if you need to move to some character you 
> usually use bar motion and bar motion ignores additional
> characters from &showbreak.
> 
> Thus I would suggest to patch bar motion to also take breaks into 
> account like virtcol() does.

I use virtcol() in several of my plugins (e.g. AlignFromCursor,
http://www.vim.org/scripts/script.php?script_id=4155), mostly to align
the current line to a column. With the current (broken) behavior of
virtcol(), this alignment would be off when wrapping and linebreak /
showbreak is enabled! When I use the plugin to align the text right of
the cursor to column 80, I want the plugin to manipulate *the text*
(not including any editor embellishments like showbreak!) before the
cursor so that it occupies 79 display cells, regardless of the way
that text line is currently wrapped and displayed. Of course, my
plugin could replace virtcol() with strdisplaywidth(), but the latter
is a recent addition only, and in the next paragraph I'm going to
argue that the two should correspond, not have slightly different
semantics (that before this bug report nobody was aware of).

>> I though think that virtcol() behavior is not a bug, but 
>> documentation is incorrect (it says "the last screen position 
>> occupied by the character at that position, when the screen
>> would be of **unlimited width**" which obviously contradicts with
>> the current behavior: no wraps are possible on the screen with 
>> unlimited width hence these options may not apply).

To me, what the documentation describes is the sensible and desired
behavior, and the implementation should be changed, not the other way
around. Vim's wrapping behavior and 'showbreak' is limited to this
editor and the user's settings, but when I do formatting, I usually
want to align to "idealistic" screen columns. Same applies to the bar
motion; I think the current behavior is correct.

-- regards, ingo

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui