Unwanted spaces added at each invocation

[shym]

Starting with a buffer containing:

a |
|

and running Tab /|, I get:

a |
  |

as expected. But running it again on the same buffer, I get:

a  |
   |

Each successive run adds a new space:

a   |
    |

etc.

If all lines contain nothing or all contain something before the |, everything behaves as expected.

[bodograumann]

I have run into the same issue.

The problem is, that all spaces at the start of a line are not trimmed. So another issue which arises is, given

ab|
b|

and doing a :Tab /|/r1, the output is ok:

ab |
 b |

But then it is impossible to get back to left-alignment for the first column. :Tab /| doesn’t change anything.

[co-dh]

A walk around is :Tab /|/l0l1
make the first column left 0, other left 1

[godlygeek]

This is the same issue as was reported in #21 - the fix for which never appears to have gotten merged. Can you try testing out the fix there (the trim_1st_field branch) for a few days and see if it solves this problem without adding any new ones?

[bodograumann]

I put it into canaaerus/tabular/master for installing with Vundle.
What I can say already is, that my test case above works all right now. Though I don’t use Tabular that often, to confirm that nothing else is broken.

[shym]

I just switched branch and will use this version now. But, just like canaaerus, I hardly ever ran into this issue. Well, we’ll see. Thank you very much!

[shym]

Trying the branch trim_1st_field, I ran into the following problem.
Started from a file with only one character | running :Tab /| will
add a space before (|). And each subsequent call to :Tab adds a
new space of indentation.
So I’m going back to the master branch.

[bodograumann]

That is true. An empty first column will grow by one space on every call of :Tab.
This should probably be changed, but I don’t think the situations occurs often for me.

[godlygeek]

9921b31 changes the behavior to prevent adding the padding after the 1st field if the 1st field was blank on all lines. That's the new HEAD of the trim_1st_field branch - can you try using that version for a while and see if you find any other problems, @shym?

[shym]

Thank you for your message, @godlygeek, I switched shortly after. But I recently encountered another corner case. Calling :Tabular /\\ on:

#define longmacro \
    macro first line \
    macro second line \
    yet another line \
    and the end

yields:

#define longmacro \
macro first line  \
macro second line \
yet another line  \
    and the end

instead of the expected (and working on master):

#define longmacro     \
    macro first line  \
    macro second line \
    yet another line  \
    and the end

Maybe it is just that the first field should be trimmed only on the right-hand side?

[khwilliamson]

This is not a corner case for me; it's what our code base is full of. I have noticed that switching gvim into visual, selecting a block, and doing gq sometimes causes some lines to be improperly indented, similar to the 'and the end' line in the second box above. Perhaps part of Tabular's problem here is an underlying vim bug. I don't know enough to know if this is even relevant information, but do so because it might be.