Set trim_trailing_white_space_on_save as true.
I don't see anything out the ordinary? The first file remains untouched for me. Could other plugins be misbehaving here?
I tried it again with all plugins disabled (except Vintageous and VintageousEx) but it is still happening
What do you see after 6 switching back to the previous tab?
Understood. Luckily, it's nothing to do with unwanted edits to the file, it's just the x coord is off, since the buffer has changed beneath Vintageous' feet. It's a condition that manifests in other cases too.
fixes #126: adjust carets on_post_save to counter trim_trailing_white…
I'm still having the same problem but now the caret goes to the last character of the line (as expected).
Can you confirm this happens to you only in the last line of the buffer? I can reproduce this too, but not in any other non-empty line.
That's weird. I cannot reproduce it any more.
It's a blind guess, but you may try this in the console:
...and then restart SublimeText.
Didn't work, but i noticed that this is happening at any place of the line:
Unless I'm missing something, what I see in the clip is normal behavior.
As a test, repeatedly pressing the sequence i, esc should make the caret walk backward. That's what Vim does too.
Thats correct, but the file is also being marked as modified.
Damn, I've been missing this all along. I get it now. It's especially weird if you consider that pressing i, esc after esc has "modified" the file before doesn't have the same effect.
hg diff shows that the file hasn't actually changed, though.
All right, this seems to be Sublime Text's behavior (I don't know whether intentional or not). It's calling the command "glue_marked_undo_groups" what's making the buffer appear as dirty if there actually are any undo groups marked. That's at least what I've been able to infer.
Good catch, btw! :)
Seems to have been fixed in S3 3020 dev build. @weslly, could you please confirm?
Still no luck. :(
Btw, this seems to happen only when I save the file in insert mode (cmd+s). If I switch to command mode before saving it works fine.
Now I'm pretty sure I can't repro this any more. Have you disabled atomic saves in S3?
I disabled atomic_save but it didn't solve the issue.
Here's how i'm reproducing it:
Still can't reproduce, and I don't think I've modified the behavior regarding this particular issue. Let's revisit the issue when I've uploaded a new version of Vintageous.
Well, now I can reproduce it again.
This has been acknowledged as a potential issue, but I don't know about its priority. I will remove this one from the milestone today or tomorrow and tag the tip as 0.5 after that.
(BTW, this might not happen any more after the latest changes, but I'm not entirely sure the latest changes are correct regarding gluing/ungluing undo groups.)
Related to #170.
This issue seems to be unavoidable.
I'm not sure if this is related to this issue but sometimes the file stays marked as dirty even after saving with :w.
fix #126 - avoid marking the buffer as dirty if unwarranted
@weslly Hope this improves things.
Note that the trim_trailing... shenanigans seem to be an issue with Sublime Text, not Vintageous. I think I could fix it on my end, but let's see if there's a better solution.
It seems to be fixed now. This bug was awfully annoying, thanks a lot for the fix! :D
It was annoying indeed. Note, however, that the issue with trailing white space remains for now.
#126 - fix false-positive dirty file detection