Tags prefixing a gather line don't appear

[Ruscaceae]

I'm encountering an issue where most of my tags don't appear to be showing up in the line immediately following a gather.

=== choice_test ===
- Line 0
* [Choice 1]
- - Choice 1 line 1
* [ Choice 2]
- - Choice 2 line 1
# before tag
- Line 2 # after tag
-> END

If I pick choice 1, then check _inkStory.currentTags when I reach line 2, it only returns "after tag". This behaviour doesn't seem to occur in the final choice in a set: if I pick choice 2, then it performs the expected behaviour of returning both "before tag" and "after tag".

I'm using version 0.8.1.

[joethephish]

Hmmmm. So, in the engine, tags are sort of treated like "normal but invisible content" as opposed to being somehow directly attached to a piece of text (though maybe I ought to reconsider that at some point). So, I think what's going on is that it's structuring it like this:

=== choice_test ===
- Line 0

* [Choice 1]
    - - Choice 1 line 1

* [ Choice 2]
    - - Choice 2 line 1
    # before tag

- Line 2 # after tag

-> END

So, the fix in this particular case would be to write it more like this:

-> choice_test

=== choice_test ===
- Line 0

* [Choice 1]
    - - Choice 1 line 1

* [ Choice 2]
    - - Choice 2 line 1

- # before tag
Line 2 # after tag

-> END

In other words, the gather - is "splitting" the tag from its content, so your # before tag was being included in the choice 2 weave indent level.

[Ruscaceae]

That does appear to solve the problem as a workaround, thanks! I appreciate the quick response.

It makes sense that it works that way internally, but I'm not sure that's particularly intuitive for the user, and I'm not sure the feature being created here is worth it. (Especially since, unless I'm missing something, it's an undocumented one.) To me, metadata implies something descriptive of a line, rather than a set of directives being constructed, and the examples used in the docs seem to emphasize that.

You wouldn't be able to create an instance of this behaviour happening with tags that occur after a line, after all. To me, it feels like the advantage of the prefixed version of tags is that they function the same as suffixed tags but with increased legibility for instances of having many or long tags.

In any event, this feels unintuitive to me. I think probably this should be caught as an edge case, or at the very least, explained in the docs.

[joningold]

It kinda has to function this way, I think; everything between Choice 2 and the gather below is part of choice 2’s weave block - and if anything in that block appeared when you chose Choice 1 it’d definitely look like a bug

• like some content had “leaked”.

(Weave is odd, in many ways; it creates walled bits of content with very little markup to say what’s where; so indenting is pretty crucial to making this stuff look intuitive..!)

So yeah, I take your point about tags looking like metadata not content but I think the weave ownership rules have got to take precedence all the same, otherwise things will get very confusing!

Jon On Thu, 16 Aug 2018 at 5:29 pm, Christine notifications@github.com wrote:

That does appear to solve the problem as a workaround, thanks! I appreciate the quick response.

It makes sense that it works that way internally, but I'm not sure that's particularly intuitive for the user, and I'm not sure the feature being created here is worth it. (Especially since, unless I'm missing something, it's an undocumented one.) To me, metadata implies something descriptive of a line, rather than a set of directives being constructed, and the examples used in the docs seem to emphasize that. https://github.com/inkle/ink/blob/master/Documentation/RunningYourInk.md#marking-up-your-ink-content-with-tags

You wouldn't be able to create an instance of this behaviour happening with tags that occur after a line, after all. To me, it feels like the advantage of the prefixed version of tags is that they function the same as suffixed tags but with increased legibility for instances of having many or long tags.

In any event, this feels unintuitive to me. I think probably this should be caught as an edge case, or at the very least, explained in the docs.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/inkle/ink/issues/460#issuecomment-413605738, or mute the thread https://github.com/notifications/unsubscribe-auth/AA40o0yCuPtmB4ETUacJvq4RrhG4WwOTks5uRZ4DgaJpZM4V-8qx .

[joethephish]

Yeah, I definitely have a lot of sympathy for what you're saying Christine... it definitely looks designed one way, and implemented another, and this edge case is catching us out for sure.

Definitely one to think about for the future... I do think that there's potential for turning it into Proper Metadata one day instead of having content masquerading as metadata. But I'm afraid it can't really be a priority right now unfortunately!

[Ruscaceae]

Well, if nothing else, I would definitely recommend mentioning it in the docs. I'm sure I won't be the last person to be surprised by this!

[JacobChrist]

I'm having a similar issue but different. Think ink will suppress the tag in the content but not report it in currentTags:

=== InkMarkupTesting
# tag:param1,param2,...,paramN

This section describes markup that has been implimneted to  augment ink.
Tags are in the format: 
\# tag:param1,param2,...,paramN

+ [audio] -> audio
+ [focus] -> focus
+ [latitude] -> latitiude
+ [longitude] -> longitude
+ [California History] -> CaliforniaHistory

However, if I move the tag it does work. Here is the crazy thing. This is not always true, sometimes the ink above will work.

=== InkMarkupTesting
This section describes markup that has been implimneted to  augment ink.
Tags are in the format: 
\# tag:param1,param2,...,paramN
# tag:param1,param2,...,paramN

+ [audio] -> audio
+ [focus] -> focus
+ [latitude] -> latitiude
+ [longitude] -> longitude
+ [California History] -> CaliforniaHistory

Edit: Interestingly enough, the tags are correctly detect in inky but not in Unity API.