Skip to content
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

Suggestion: Generate a warning for unmatched {color=#......} tags #255

Open
FaceCrap opened this issue Feb 16, 2023 · 6 comments
Open

Suggestion: Generate a warning for unmatched {color=#......} tags #255

FaceCrap opened this issue Feb 16, 2023 · 6 comments

Comments

@FaceCrap
Copy link

FaceCrap commented Feb 16, 2023

I've tasked myself to clean up code for existing projects, and sometimes I get files that don't properly close {color=#....} tags. Although Ren'Py projects themselves don't seem to be affected negatively, in vscode it is often causing the code either to be displayed in the defined color from that point or syntax highlighting getting completely disabled.

It would be nice if this would generate a warning, so I can easily jump to the position(s) where this happens.

@duckdoom4
Copy link
Collaborator

That's a great idea, this should be added. It should also check for other string tags that are not properly closed.

@FaceCrap FaceCrap changed the title Suggestion: Generate a warning for unmatched {color=x......} tags Suggestion: Generate a warning for unmatched {color=#......} tags Feb 25, 2023
@Gouvernathor
Copy link
Member

Gouvernathor commented Mar 5, 2023

I think this is supported until since recently. Not closing builtin tags has always (?) been working, and now it's documented.
So, flagging it with a warning would be a mistake. In these kinds of lines, the color (or whatever markup) should survive until the end of the string and not after.

@duckdoom4
Copy link
Collaborator

Hmm, that changes things. That makes for a slightly complex regex. I'll see what I can do

@FaceCrap
Copy link
Author

FaceCrap commented May 27, 2023

Hmm, that changes things. That makes for a slightly complex regex. I'll see what I can do

Making markup tags survive until the end of the string might not be the only thing. there's also the possibility that the same markup tag can occur more than once in the same string.
At least for color markup tags it would mean they not only need to be considered closed at the end of a string, but also when a new color tag is encountered before the end of the same string.
Since these visually alter how code is displayed in the editor and can't be 'stacked' like font-style markup.

Frankly, I could care less how it's solved, whether by terminating markup at the end of a string (which can span multiple lines too it seems) or by actually forcing to use the closing tag.
I just hope it's done soon as the code I have to deal with now often looks like my little pony shat in it

@duckdoom4
Copy link
Collaborator

Can you post a screenshot of what you're currently seeing? Additional markup tags should overwrite the previous tags if any overlap. So if another color tag is opened, it should already change the color to a new tag.

@FaceCrap
Copy link
Author

the color does indeed change when a new color tag is encountered ;) That is why I compared the result to a my-little-pony toilet :D Because the color keeps continuining until another color tag is encountered, causing the file to have big chunks of differently colored code/dialoge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants