Allow / in identifier strings

[jaxter184]

I'd like to be able to express a path-like string without quotes. I run into them a lot, and I think it would make it more CLI-like, assuming the "xml-like semantics that looks like you're invoking a bunch of CLI commands" description on kdl.dev is a design goal.

Sorry to bring this up so close to the v2 release, just wanted to mention it in case it's not too late to change things. After writing this all out, it seems like it might be more added complexity than it's worth, but I wanted to at least put it out there for discussion since I think it's a pretty common case.

Examples

• UNIX paths, like spawn-at-startup "/home/jaxter/.config/niri/bg.sh" from my niri config
• Proposal: support identifiers anywhere strings are accepted #308 (reply in thread)
  • A similar situation in my project, which also uses Open Sound Control: https://git.sr.ht/~jaxter184/tlature/tree/main/item/tlature-engine/src/graph/block/test.rs#L166

Two approaches

• remove / from the disallowed characters of the identifier-char rule
  • I think it's a simple change? Both to the spec and to most implementations
  • Would allow identifier strings like word//word, which is a little unintuitive, given word //word would treat the second half as a comment
  • Similarly, would allow glob/*.ext, but not /*.ext
  • Would probably mess with syntax highlighting
• Revamp identifier parsing to disallow comment-like
  • Would error on all examples from above, which would be good for avoiding mistakes, but would also disallow things that may seem intuitive (ex: glob/*.ext).
  • I think it's a more complex change, because the current structure checks individual identifier-chars, and if I'm correctly understanding how it works, it wouldn't be as simple as taking the existing line identifier-char := unicode - unicode-space - newline - [\\/(){};\[\]"#=] - disallowed-literal-code-points - equals-sign and replacing the disallowed characters with ... - [\\(){};\[\]"#=] - '/' [/-*] ..., instead requiring that whole section of the spec to be rewritten, and probably most implementations too (sidenote: I think the equals-sign here is a mistake, probably a relic from when there were multiple kinds of equals signs).

[zkat]

I too kinda wanted this but the more I thought about it, the more the potential conflicts around comment parsing seemed like a bigger and bigger footgun. For example, I really don’t want to require a space after /-, since attaching it directly to the item being commented is the most common way for it to be used.

[bew]

I don't really see a conflict, and I don't see why you'd want to add a space after /-.
What about forcing a space before /- to consider it as a commented node?

A /- path is unlikely to ever be needed, and we can always do it by quoting it 🤔

[zkat]

Re: approaches… the most obvious approach is to ban either just / or //, but this already reduces the value of this change: now you have to remember that while you can represent relative paths without quotes, you can never represent absolute paths without quotes. If the latter heuristic is used, then you effectively ban UNC paths and the representation of schemeless URLs (which are used, for example, in NPM’s configs.

So, effectively, we would be adding noticeable cognitive overhead to quoteless string logic (which imo is already pretty complex) and, at best, you would get a subset of UNIX-style relative paths out of it, and very little else. Does this one (valuable!) use case really make the whole thing worth it?

[zkat]

worth noting: this proposal already completely leaves out Windows-style paths which are, in fact, widely used (and easily represented with raw strings). Considering \ a potential identifier char kinda scares me tbh

[jaxter184]

worth noting: this proposal already completely leaves out Windows-style paths

I assumed it was ok to forsake Windows paths because they already require a raw string (or \\) anyway

at best, you would get a subset of UNIX-style relative paths out of it, and very little else

I think this sums up my current position. I think I run into more instances of this than most other people who use KDL, and even then, I've only run into it a handful of times.