Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separator Text Object: First Field Unreferenceable #110

Open
orbisvicis opened this issue Apr 3, 2015 · 8 comments
Open

Separator Text Object: First Field Unreferenceable #110

orbisvicis opened this issue Apr 3, 2015 · 8 comments

Comments

@orbisvicis
Copy link

vi,
+
a , b , cccccccc , d , e
   +++
@wellle
Copy link
Owner

wellle commented Apr 3, 2015

Works as expected. vi, selects between commas. a is not between any commas, so it can not be selected with vi,.

Adding linebreaks to the mix makes it impossible to select multiline entries separated by comma (like function argument lists with one argument per line).

Adding the beginning and end of the buffer seems would be such a special case that I don't think it makes much sense to break consistency here.

So what do you suggest?

@orbisvicis
Copy link
Author

I think this should be fixed:

  • current behaviour unexpected
  • current behaviour has problems
  • significantly more useful if fixed

Given a document containing multiple lists in multi-line style, attempting to select the first or last elements instead selects multiple lists:

List Style 1:

a ,
b ,
cccccc ,


d ,
e


List Style 2:

    a
,   b
,   ccccccc


,   d
,   e


List Style 3:

  a, b, ccccc, d, e


List Style 4: (3&1 or 3&2):

a, b,
c
, d,
e, f, g

The beginning of a multi-line list can't be accurately determined in style#1. The end of a multi-line list can't be accurately determined in style#2. However a list-boundary condition needs to exist, if only to prevent the aforementioned selection problem.

The simplest boundary condition is to stop on lines without the selected delimiter. However I think this might be more effective:

  1. Move in direction X to next line
  2. Get line contents
  3. Strip out comments (requires filetype support, but isn't dependent on any particular filetype)
  4. Continue (to 1) if:
  • Line contains whitespace (\s) only
  • Line is empty after stripping but not empty before (entire line was a comment)
    1. Stop. Selection includes starting line only (ignore lines in 4)

Single-line lists should be relatively simple to fix.

@hoschi
Copy link

hoschi commented Apr 19, 2015

I think this should be fixed
...
I think as @orbisvicis this is more usefull and expected when fixed, see also #116

@krusty
Copy link

krusty commented Aug 24, 2015

I would like to have this (or #84) since it would allow to select things like the left and right sides of an assignment, or multi-line hashes in several languages.

@acornejo
Copy link

acornejo commented Sep 2, 2017

This seems to be an issue that multiple people have found unexpected.

However, I understand fixing it would be a backwards incompatible change.

So what about making this a configurable option. There are a multitude of ways of implementing this, one has already been described above. A simplest one would be to just consider BOL and EOL as an instance of whatever delimiter is being used.

@hoschi
Copy link

hoschi commented Sep 27, 2017

Opt-in sounds like a good compromise.

@aeosynth
Copy link

aeosynth commented Nov 2, 2018

this issue affects more than just beginning/end of line, for instance:

fn(a, b)

targets.vim cannot delete a or b with di,. i think a general solution is an ANY delimiter: in this example, placing the cursor on a would seek left to the first delimiter and find (, seeking right would find ,. in the OP example, ANY would seek left to find BOL, seek right to find ,.

@wellle
Copy link
Owner

wellle commented Nov 4, 2018

@aeosynth: Your specific example is covered by the argument text objects. Try daa or cina.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants