Auto locate/open Inline Type

[umitkablan]

Is it possible to auto locate the (nearest or after an interactive selection) inner file type without moving to that area? For ex. if I open a html file and issue InlineEdit the plugin opens the js/css section if available; If the section is sole one it is trivial to select, if not the nearest or user selected one opens etc..

[umitkablan]

@AndrewRadev, any comments?

[AndrewRadev]

Sorry for not answering sooner, but I was waiting until the weekend when I would have more time to go into the code, experiment with it, and think about the feature before replying.

What I can say right now is that it's probably doable, I'm just not sure if it will be a good idea. For example, if you go to an area that you think would be possible to trigger an inline edit, but it doesn't work (maybe due to a bug in the plugin, or maybe the area is not quite what the plugin expects), then the plugin may just open something completely different and unexpected. Also, let's say the plugin opens the nearest js tag, but you wanted the css tag instead. Now you have to go there anyway, except you also need to close a buffer window. To me, this makes the whole feature somewhat unreliable -- it may work, or it may not, depending on what kind of stuff you have in the buffer. Alternatively, if you just search for script or style you could easily find the area, do your thing, then use the backtick (or anything else) to go back to where you were editing.

That said, this is just my initial assesment. I'm going to go over the feature this weekend (I hope) and think about it some more. Maybe I'm worrying for nothing. Even if I implement it, it'll probably be optional anyway, so it's likely that some of the issues I can think of are rendered moot by that.

[AndrewRadev]

I implemented a proof of concept in the auto-locate branch.

Currently, if no pattern has been matched around the cursor, it goes through the file looking for the start regex of each pattern and opens up the first one that it sees. This has the annoying property that it doesn't try to locate the "closest" one around the cursor, just the first one. The "closest" behaviour shouldn't be too difficult, but I'd have to reorganize some of the code a bit.

Does this implementation cover your use cases? I was a bit doubtful, but it could actually be a valid workflow addition as long as I open the "closest" item. I would still have some work to do to clean up the code and document it, though, but for now, could you try this branch and let me know what you think?

[umitkablan]

With the initial toy example I coded I can say that embedded JS in HTML is OK, inside of it and outside behaviour is good (I can wait for "closest" :)). But CSS is also an embedded source and I saw that the plugin does not take into account CSS, only JS is auto located in HTML. Sorry I haven't read your code but it might be because not all regexps are searched?

My other suggestion was to make the user selects from a scratch buffer (plugin created) which embed to focus on and close automatically after select. N (configurable) lines might be shown in that scratch buffer as preview or maybe main buffer forced to scroll to that region we are about to open. Is it logical? If not that's OK because closest might be valid for many workflows which you think is easy to implement.

[AndrewRadev]

The plugin does take into account CSS in my tests. However, it actually attempts each pattern throughout the file, so if there's, say, a javascript pattern anywhere in the file, it'll actually open that one. I guess I do need to implement the "closest" functionality before this feature makes sense.

Adding an interface to the plugin would be a lot of work and I really don't think it'll even be useful. I still think the feature is only somewhat helpful, since you could always just search for script or style or whatever it is you're looking for. Vim has much better ways to put you in the correct position than I could ever implement in the plugin. Jumping to the closest area is something I feel is the best use case, especially if you can see it nearby, so you'd rather just hit the mapping instead of bothering to type or something like that.

[AndrewRadev]

I implemented the "open closest pattern" feature, though I'm not very happy with how it turned out. In my experiments, I kept being confused over which pattern would really be opened. You see, I monitor both the start and end matches, which means that if you have something like this:

<script>
  alert('foo');
</script>

<style>
  body { color: red; }
</style>

If you put the cursor between the two blocks, either one could be selected, since they're both 1 line away from the cursor.

Alternatively, I could only look for the start patterns, but this would always give priority to patterns after the cursor. This may be okay, but it may not, it all heavily depends on how you use it. For example, if I were to focus on start patterns only, then consider this case:

<script>
  alert('foo');
  alert('bar');
</script>

<span>one</span>
<span>two</span>
<span>three</span>

<style>
  body { color: red; }
  a { color: blue; }
</style>

If you're on the one span and you :InlineEdit, you'll open the style tag, since its starting tag is 4 lines away, and the script tag's is 5 lines away. Even if it visually looks much closer due to the closing tag being close.

For now, I would recommend you to experiment with the feature and see if the currently implemented method (look for the closest start or end) feels right in your workflow.

I also have a different idea to make this use case easier -- have a motion in the vein of [[ and ]] that moves back and forth between start patterns. If you have that, you'll basically be able to easily go to the area you wish for and then open a proxy buffer. What do you think about this train of thoughts?

[AndrewRadev]

@umitkablan, it's been a while, have you tried this feature for some time? Do you think it's useful enough to keep and do you have any thoughts on my [[/]] idea?

[umitkablan]

I haven't tried the feature yet (if we don't count my last branch usage), but can help in brainstorming :) The closest for anything (opening or closing tag) is more apropriate for my cognition (not talking about implementation though), and just fail with error if cannot decide. On the other hand, your idea of "unimpaired"ish solution is really viable for me, I use such movements frequently in my workflow. I can even go further and suggest two commands :InlineEditNext/:InlineEditPrev as well as accepting a g:* variable to decide whether InlineEdit guesses or not.

[AndrewRadev]

I've implemented two mappings that jump to the next and the previous inline patterns. You'd have to do something like this to use them:

nmap [[ <Plug>InlineEditJumpPrev
nmap ]] <Plug>InlineEditJumpNext

With this, [[ would jump to the previous pattern (if there is any) and ]] would jump to the next. At that spot, you could easily use a mapping to inline-edit the area, or even create a mapping that jumps and inline-edits.

What do you think?