1

Assuming I have a line such as the following one:

XXXXXXXXXXXXXABCXXXXXXXXXXXXXXXXXABCXXXXXXXXX

mark a is at the first instance of ABC, mark b on the second one.

Now I run a macro on it, breaking the line twice, and inserting something around that position:

XXXXXXXXXXXXX
YYYABCYYY
XXXXXXXXXXXXXXXXXABCXXXXXXXXX

After this, I want to go back to mark b, but it is now located at the very end of the first line, instead of at the second occurrence of ABC. In fact, both the marks are there now. I assume this is because vim uses the x and y coordinates in the file to remember the marks. I believe it can deal with some changes to the file one edits, keeping the markers in the proper position in respect to the surrounding text, but not here. But maybe that assumption is mistaken.

My real world files look much more complex, and probably my example is not the best, but it does show the sticking of both marks to the end of the first line after the insertion. I reality, both instances of ABC may or may not be the same, although they will definitely be similar. Many times they differ from each other enough to make jumping between the two based on a search for that pattern, while not impossible, but apparently impossible to automate. Anyway, I was just going to ask if I missed anything about marks that could help me use them in this context, and get the expected behavior.

Improve this question
0

1 Answer 1

Reset to default
2

Your hunch about x and y is correct with the x and y being line number and column number. You can see this directly, for example, with :marks. Being just a position and generally (see below) not having any binding to any actual text, the mark's line remains the same if you, for example, insert a newline in front of the mark on the same line. If you delete characters from the same position the mark will remain in its column until the line gets too short in which case the mark will follow the end of the line.

There is one exception I'm aware of (thanks to @Mass) where this stick-to-the-position rule is bypassed. Quoting help:

The line number of the mark remains correct [if] you insert/delete lines

So you can delete 10 lines above the mark and the mark's line number will subsequently be -10 as it remains with the same text.

Even with that exception it sounds like marks are probably not going to get you where you want to go. FYI, the only thing that "sticks to" text, to my knowledge, is text properties. They can be used as text markers. They're not persistent, though. If that's not an issue you could explore the possibilities there. (I've been meaning to do a writeup on them...if only there were more hours in the day...)

Improve this answer
5
  • 1
    "mark's line remains the same even while edits are moving text vertically" Although marks are line-based (unlike text properties) as demonstrated by OPs question, they do move if you perform operations like inserting lines in before a marked line. Breaking a line keeps the mark on the first line.
    – Mass
    Commented Jan 21, 2021 at 21:30
  • What I said is consistent with marks remaining on a line even if a newline is inserted in the middle of it. And I had verified this myself. But I missed the mark moving upon insert of a line before its position. That's not consistent with what I said. I'll check it out. Thanks.
    – B Layer
    Commented Jan 21, 2021 at 21:38
  • @Mass Answer updated. Thanks for the heads up.
    – B Layer
    Commented Jan 21, 2021 at 21:48
  • By now the task at hand (conversion of a critical edition from LaTeX to TEI (XML)) has been completed. But instead of extracting all information from the file actually being edited I switched to working with splits, extracting most information from the original version of the file. That way I needed to modify my macros not that much, just adding a few ^W^W here and there. My original approach had worked as long as the creator of the file had kept his apparatus on separate lines, but he had changed conventions mid file, causing a bit of trouble, but no problem.
    – muk.li
    Commented Jan 22, 2021 at 6:13
  • 1
    @muk.li Congrats on finding a painless workaround. :)
    – B Layer
    Commented Jan 22, 2021 at 7:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.