-
Notifications
You must be signed in to change notification settings - Fork 51
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
Additional text objects? #14
Comments
Thank you for your input! Let me tackle them in order: To be fair, separator text objects can't target the first and last arguments because they are surrounded by different delimiters. I had many thoughts about some special argument text objects because it would be really useful in combination with next and last text objects. An easy way might be to introduce separator classes so that different characters could be used as separators for one text objects. For example Also: Should the list of separators be customizable or just a fixed set that we can agree on? I thought about this too. Looking at the default bindings, I'm a happy user of this text object plugin myself. Thinking of it, it might be interesting to target next indents. So In general I would say I'm not striving to combine all text objects into targets.vim. All of them can coexist independently and everybody can choose what might fit their needs. So instead of including and expanding them in targets.vim, it might be fair to give their maintainers the chance to expand them themselves. That said, I do see benefits in expanding these text objects to support next and last text objects. Maybe there is even a way to just generalize this concept of next and last to make it easier to support that for existing text objects. Is this what you had in mind? Or what benefits would you see in integrating them into targets.vim? |
Thanks for the quick response!
Yeah, I'm biased to working mainly in C-like languages so a fixed set would be fine for myself. But then again, wouldn't be fussed if it was customizable either. Nested arguments seem such a fringe case that I doubt it'd be worth devoting the time and energy to getting right.
After re-examining, personally 'l' for last seems better than line so if it were to be incorporated I'd say the line object should be the one to change. It's also one of these objects that I use so rarely that 'dd' or 'cc' cater for that it's maybe not worth bothering about at all.
Yeah, I was concious this might be the case and sounds like a sensible strategy. I think the goal is just having a good generalised set of text objects for the masses.
Agree with all your thoughts entirely, plugin is heading in the right direction and I'll be keeping my eye on it! |
I use https://github.com/kana/vim-textobj-lastpat regularly (
BTW thank you for the great plugin! |
@edkolev Depending on your Vim version you don't need that plugin anymore. I'm using So I don't see any reason to replicate that text object in targets.vim. But I agree that it should be possible to disable certain mappings. Let's continue that discussion in #15. |
@edkolev You might be interested in yesterdays vimcast: http://vimcasts.org/episodes/operating-on-search-matches-using-gn/ He even mentioned the patch I wrote that makes |
Nice! Thank you, for pointing this out and for providing the patch to vim :) |
How about allowing for = as a marker? Handy if you are dealing with equations. |
@EPNGH That's a good idea. Lets continue the discussion regarding |
Is there any interest with regards to incorporating LaTeX environments and quotes into text objects?
Currently I use https://github.com/rbonvall/vim-textobj-latex for these, however I'm fairly lazy and I really love targets.vim's ability to "search out" the text object you're trying to edit rather than having you have to be inside of it. That plus the 'nNlL' makes for a very fluid workflow that isn't available with textobj plugins (although I wish they were). It does lead me to ask whether these will be implemented, however. Or if there exists a way to add them myself. |
@thang1thang2 That's an interesting use case I haven't considered yet. I will think about it. Thank you! |
@wellle: Awesome, looking forward to giving it a whirl! |
Chiming in... @wellle do you know https://github.com/justinmk/TextObjectify ? Your plugin is very similar, but each of you have exclusive features. I tell this to you, because I don't understand why you need the I think it could be a source of inspiration. You and the other contributors might have a lot to talk about ;-) |
Using Sanity checks would be needed for the "any pair of characters on the fly", to ensure that you're checking only non-mapped characters. (e.g. |
@freeo: Yes I know TextObjectify. I agree that on the fly text objects sound useful, but I never felt like I'm missing a text object with targets.vim. And if I do, it's quite easy to add it with the supported customization. One problem that I see with on the fly text objects, is that it's not sure whether it should behave like a quote text object ( Having
So to me it looks like we need some sort of additional modifier to allow all three cases. |
About wordsI suggest the creation of a new kind of text object named "sequence text object", that, instead being defined by separator or delimitator characters, these objects are defined by a sequence of characters (or by a regular expression). For example, a Note¹: The user can change what is a word by changing the option Note²: Vim uses the option About paragraphs and sentencesA A But, for vim, sentences have special features:
If a sequence text object is an object defined by regular expressions, paragraphs and sentences can be defined by regexps. |
@Seninha: Thank you for your comment, that is a great suggestion! I think sequence text objects and separator text objects ultimately lead to the same text objects. But I agree that some text objects (like words) could be easier defined by sequence than by separator. As you described WORDs yourself, they still might be easier defined by separator (any whitespace). I will definitely keep this in mind when adding word text objects. If ever. Is there demand? Some open questions:
|
Or to put it another way: Should we add sequence text objects or match text objects? As in: Should we allow only certain sets of characters to build sequences from, or should we allow full regexes? The former would be much easier to reason about. The latter is more powerful, but probably much more complex to do right. There might be minuscule differences in expectations, similar to the difference between quote text objects and separator text objects that we might not see yet. Anyway, I'll think about it 👍 |
I think just sequence text objects is necessary, since it can works together with options like Also, complex objects like sentences could be best defined by separator expressions, i.e., by a regexp that matches to separators. I think using regexps to match separators is more useful than using them to match an entire object. |
This is starting to broach a much more meta topic that I've been privately musing about for a while, which is the broader diagramming of language as a whole. When one operates on text inside vim, they operate on an abstraction of text into groups that make logical sense to humans. In English, we commonly break text into the distinctions of letter, word, phrase, sentence, paragraph, page, chapter, and document. For programming, we have a different set of distinctions: word, letter, argument, line-of-code, function, function argument, "block" (e.g. not the entire function but the internals of it), and so on so forth. Obviously, programming is a much more difficult and rigidly defined abstraction of thought, but it has to be by nature. The purpose of a text editor such as vim is very different than most other text editors. Most other text editors perform actions on manually selected areas of text, if possible, but otherwise are very blind and are simply containers in which you type out your text. Vim, on the other hand, aims to be intelligent of language structure so that you don't operate in text but rather operate on linguistic structures. It was this revelation that revealed to me that Vim, flexible as it is, was actually incredibly restricting in how it approached damn near everything. It was written in a time where C reigned supreme as a language and where everyone who would ever use it spoke English as a first, and probably only, language. This lead to some short-sightedness in programming the editor (which is, of course, obvious only in hindsight). What I would love to have an eventual goal of targets.vim be (heh, or maybe even something else entirely) would be to strip out all the 'object' code in vim and smash it with a hammer and re-write it in a way that's extremely flexible. My main premises:
footnote 1: An example of the flexibility I envision. I would see
Intuitively. One would expect
and so on, so forth. And if you had the cursor on 'word' you would get the result:
and so on, so forth. And additionally, But this raises up another problem. What are you doing when you
This would allow for all the 'text object' code to go away in vim. How I see it is you would just then have a file structure in vim like so:
Since location is dependent on action which is dependent on textobj, location is also dependent on textobj. But, importantly, you don't need to define location to have an action and vice versa, this allows you to create a generic 'next' or 'inner' and have it work with everything, but customize behavior for tricky things like function arguments. Additionally, Objects would be defined in reference to filetypes, so a 'block' would be different in python than C than in Haskell. The 'Action' and 'Location' parts are what targets.vim currently hit and it does a pretty good job of it. But currently there's no way to have intuitive behavior outside of global ultimatums. For example: you can't, currently, have vim treat a word as "text between underscores" while treating hyphenated words as a single 'word' in one filetype but have it do the opposite in another without massive pain with the 'iskeyword' stuff. Also, having vim see every single thing as a keyword makes navigating a huge pain because 'w' sees _ as its own word (which is what iskeyword does, really), so this_is_a_pain-to-move_through_with_w will take like 15 spams with 'w' but only one with W. Ideally you want 'w' to move from 't'his to 'i's, which it currently doesn't. Additionally, diw if the cursor was on 'to' (should) be able to be customized to delete pain-to-move since that's one "word" for our hypothetical filetype. All in all, it's quite interesting thinking of how to truly diagram language in a way that it's extensible for all cases and programming languages without being complex to the end user or impossible to program for the programmer. |
@thang1thang2: Thanks for your huge comment 👍 |
@thang1thang2 Wow! I beleave that Text Objects (or just Objects as you proposed, and I liked your proposal) must be reimplemented to a more natural, context-relative, filetype-relative and dynamic way. I hope the NeoVim project stuck to this approach. I liked the way you proposed Objects to be defined in a more objective and structural way (as a truly object in any programming language):
Well, this is only a hope I have that I hope to happen. |
In the meanwhile, https://github.com/Julian/vim-textobj-variable-segment provides a workaround for the The plugin Making this patchwork more coherent by a word regex for each filetype (maybe the distinction Text or Code Filetype is already sufficient) would be nice. |
I would want to caution against the notion of binding something to a specific 'key' on a keyboard; such thinking is a very constrained idea. It would be better to bind the action to a user-definable key, where the binding could be anything from a single key on a keyboard, to a sound-file, to a chord (see: stenographic keyboard), etc. Binding actions to a sound-file would allow for organic voice commands being used to manipulate vim, which is sometimes necessary for blind people and otherwise essential for people with motor disabilities. Binding actions to chords would allow you to type a natural chord/syllable on a stenographic keyboard without having to set silly workaround bindings in a vimrc. Such is the type of forward-thinking I envision when I see the potential for vim's object-styled "composing" language. Additionally, I would argue that objects could be defined in multiple types of logics, depending on how you need to define it, filetypes, etc
When in doubt, it is almost always possible to further generalize a concept. To which extent 'objects' are generalized depends mostly on what is possible to accomplish in vim. It may be that we would have to wait for a project like NeoVim to "finish" refactoring vim to a state where it would be possible to rip out most of the 'word' and other 'object' oriented code and rebuild it in a much more robust and extensible way. My greatest inspiration for the restructuring is along the following train of thought: Humans speak in a verbal language, which is fuzzy and incomplete (and yet capable of expressing any idea). One of the most attractive principles of vim is the fact that you 'communicate' with vim in an almost human language. 'caw' -> "change around word" is a very human train of thought, and almost sounds like you're just speaking to the editor in your own words and telling it what to do. Unfortunately, if you completely subscribe to that, you quickly run into limitations in vim's ability to "communicate" with you, due to the constraints under which it was originally conceived. In studying how language argues and shapes things, and how grammatical structures are formed, you can see (dimly) vim's "language". Being able to expand this to a completely customizable, and extensible "grammatical/syntactical" system of using commands in context would allow the editor to become much more powerful and 'natural' to use over time, seemingly without limit. |
@thang1thang2: You might like VimSpeak. |
I was reading Steve Losh's dotfiles And found a
|
@alx741: Thanks, will consider. |
@wellle one of the disadvantages of vim-textobj-user and it's derivatives is that they're very slow loading wise. You mentioned that you use vim-textobj-indent, I'd wager that it's in the top 10 of your plugins that's slowing down your loading. |
@gaving: I'd like to keep this issue open as it still contains a lot of good ideas I wouldn't want to get lost. If you don't want to get updates about this issue you can click on the |
@welle Ah no worries, I was just tidying up a load of ancient issues/requests I had open. Cheers! |
Just generating discussion but I'm a fan of the following additional text objects:-
I'm thinking the argument one is superseded by targets.vim's separator objects, but any chance of either line or indent making their way in?
The text was updated successfully, but these errors were encountered: