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

WIP: handle labels more readably #166

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

@FLHerne
Copy link
Contributor

@FLHerne FLHerne commented Oct 31, 2020

Unfinished, but does this look sane?

See changes in regression/expected.

@glx22
Copy link
Contributor

@glx22 glx22 commented Nov 1, 2020

Changes in regression/expected are correct. I like how ASCII values are printed, but full numerical values looked better with dxXXXXXXXX

@FLHerne
Copy link
Contributor Author

@FLHerne FLHerne commented Nov 1, 2020

Changes in regression/expected are correct. I like how ASCII values are printed, but full numerical values looked better with dxXXXXXXXX

You mean the ones like "\12\34\56\78"? That's where the input NML happened to use all escaped bytes in a string-literal, e.g. in this case

// also override some other grf, this time not setting our own grfid explicitly
engine_override("\12\34\56\78");

I think this is probably helpful because it makes it clearer where the value came from, and that adding some heuristic would be confusing.

This should never affect numeric values that weren't strings in the source code.

@FLHerne FLHerne force-pushed the flh-wip-labels branch from f29f3b4 to 0a8b77b Nov 3, 2020
@FLHerne FLHerne force-pushed the flh-wip-labels branch from 0a8b77b to 4ebe7a8 Nov 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants