Support multiple ranges for code

[ensko]

The line-range argument currently only supports a single range of lines, e.g. line-range: (2, 4) selects lines 2 and 3. It would be very nice if multiple ranges could be supported, and ideally a separator indicating skipped lines; this corresponds to the ranges and smart-skip/skips feature of codly.

As for the API, I think the line-range parameter could support both modes: if the parameter is an array, it either contains two numbers (single range like now) or arrays and dicts (multiple ranges)—no ambiguity.

(separate but kinda relate to this feature request: I wonder how you feel about inclusive ranges; specifying (2, 3) to select lines two and three feels more natural, even though it's less common in IT. In crudo, I even use strings for that purpose, formatted similarly to how page ranges are specified when printing, e.g. "-2, 4-5, 7, 9-" for pages up to 2, then 4, 5, 7, and then pages starting at 9)

[hongjr03]

Thanks for your feature request! I’ve implemented the feature based on your description (and kept the same argument name as in codly since I think it fits really well).

(Separate but somewhat related to this feature request: I wonder how you feel about inclusive ranges; specifying (2, 3) to select lines two and three feels more natural, even though it’s less common in IT. In [crudo](https://github.com/SillyFreak/typst-crudo), I even use strings for that purpose, formatted similarly to how page ranges are specified when printing, e.g. "-2, 4-5, 7, 9-" for pages up to 2, then 4, 5, 7, and then pages starting at 9)

For now, I think keeping it as $[a, b)$ makes sense since it’s more consistent with most of Typst’s API. Probably the main issue is that I currently just use an array of length 2 instead of the range function. What do you think?

[hongjr03]

Using strings — I actually thought about that at first too, since it aligns well with my intuition from writing Markdown with expressive code highlighting. However, I found that Typst treats the string appended after the language name as the first line of code, which makes things tricky. I haven’t yet figured out a reliable way to tell whether it’s an actual first line of code (which means no highlight line number) or my intended control strings. Maybe once I find a stable solution, I’ll update it in a future version!

[ensko]

I found that Typst treats the string appended after the language name as the first line of code, which makes things tricky. I haven’t yet figured out a reliable way to tell whether it’s an actual first line of code (which means no highlight line number) or my intended control strings

I actually just meant as a possible way to specify the ranges parameter, not for embedding in the raw code—the latter could be nice, but it is indeed tricky and also a bit magical. But even if it is not supported directly, an option could be to define (either in zebraw, or as a user of the package) a function that returns an array of the expected form. If my tests indicated this correctly, using none as the upper bound for the line range works already; supporting it for the lower bound would be useful for half-open ranges of the form "-p"

[hongjr03]

Sorry for the late reply. I haven't been able to address Zebraw's issues and prs promptly lately. I'll design those features and review the pull requests over the next month. :)

[ensko]

thank you! I know that maintaining open source projects is not always top priority; I do hope to soon go back to a release (currently I'm using my fork with your and my recent PRs) but I can manage for now. And I hope my PRs are good enough that they actually save you some work :)

[ensko]

Hi @hongjr03, sorry to bother you—I am starting to share my template that uses zebraw with colleagues, and currently I advise them how to install my fork to get this feature and #36 for their documents. This works, but it's a bit of overhead for people switching to Typst. If you could find the time to look at the open PRs, that would be greatly appreciated.

As I said, I am currently successfully working around this, but it would definitely simplify things.