On Do, 22 Nov 2018, Bram Moolenaar wrote:
>
> Christian wrote:
>
> > On Do, 15 Nov 2018, Christian Brabandt wrote:
> >
> > > Ah, I have seen that error before and thought I fixed. That usually
> > > happened when the buffer was not loaded. I'll have a closer look later.
> > > I suppose that happen when running test86?
> >
> > Here is an updated patch, that fixes the crash, and contains updated
> > documentation and a test.
>
> Thanks.
>
> > Note, I changed the shiftwidth() function to accept an optional column
> > number instead of a position List.
> >
> > However, I am not sure it makes sense. When developing the test, I found
> > it actually confusing, that e.g. `>` depends on the actual cursor
> > position. So using `norm! 0>>` will behave differently than `norm! $>>`.
>
> Depends on how you explain it. I think it does sort of make sense that
> you get the effective width at the specified position. However, if you
> shift multiple lines you do expect the indenting to depend on the
> previous indent. Thus it's better to always use the firt non-blank
> character position. I'll make it work like that, please check it.
>
> > So it might be a better idea to simply document, that the shiftwidth()
> > function will always return the `tabstop` setting instead of using
> > whatever vartab setting is in effect for the current column (and also
> > auto indenting will not respect the vartab feature, when the shiftwidth
> > setting is zero).
>
> This function is used by plugins to get the "normal" shiftwidth, in
> which case passing no argument, like before. In case the plugin wants
> to get the effective shiftwidth depending on 'vartabstop', I suppose
> using shiftwidth() with the column argument is the only way. Having the
> plugin compute that by itself is complicated. It would probably have to
> try to change the text and find out what it ends up like.
>
> > So here is an example, consider this example:
> >
> > :set sw=0 vartab=10,20,30,40
> >
> > and the following line:
> >
> > x
> >
> > On hitting >>, the line will be shifted like this:
> > x
> > x
> > x
> > however, if you leave the cursor at the start of the line, the indent
> > will rather look like this (e.g. using norm! 0>>
> > x
> > x
> > x
> >
> >
> > It might be confusing to the user to understand, why it was shifted one
> > way and not the other. So I am not sure, if this change is actually
> > justified.
>
> The way I made it work now is that the same indent is added no matter
> where the cursor is, it depends on the first non-blank character. I
> think this is what users expect.
Thanks for fixing those remaining parts.
BTW: The patch mail for 8.1.0542 did not arrive yet.
Best,
Christian
--
Man sage nicht: Das Schwerste sei die Tat. Das Schwerste dieser Welt
ist der Entschluß.
-- Franz Grillparzer
--
--
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.
