-
Notifications
You must be signed in to change notification settings - Fork 314
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
Can 'doc' use the terminal width for formatting output? #595
Comments
Unfortunately it can't with the way it's currently written (the line breaks, indents, etc are hardcoded into the manual DB during compilation). |
Ah, ok. Is that an upstream issue, or something you potentially have control over? (I'm not quite sure where the If you have control, and wrapping at 80 columns is an option, I think that would be a safer choice for hard-coding. Failing that, it would be interesting to know what the actual rules are for formatting (as that would potentially allow detection and re-formatting -- even if I'm doubtful that I'll actually try to do that :) |
After a look at some example output, I decided to give it a whirl after all, and got it working pretty well! I'm assuming that more than one space always indicates an indent/tab-stop, and that seems to hold in my initial tests. I'm expecting I'll find edge-cases where it wraps things it shouldn't, but the only example I've seen so far turns out to be an issue by default:
The HTML docs have it as:
In theory, could I expect all list items to have the asterisk+space prefix? Or is there a fixed set of such characters? |
We do have control over the wrapping. The most straightforward thing to do here would be to wrap to 80 characters at build time. We're not, because that extra 20 characters means a lot more things don't get awkward when they're wrapped. But we definitely could. We're wrapping at build time because proper line wrapping at runtime would require a lot more complexity, e.g. storing structured data rather than flat strings. We could wrap nothing at build time, and attempt to wrap at runtime. But it's not completely straightforward. For example:
In the
But even if we could come up with a good heuristic for this, it's hard, because we're not wrapping plain text. We're wrapping formatted text, which is stored with markup that changes colors, makes things bold, etc, so string lengths, column boundaries, etc are a lot more complicated. So to do this right, we're back to needing to store structured data rather than flat strings :-/ |
Yes, non-plain-text will cause issues -- as I found when I first tried to plug in my filter, as it was acting before the ansi colour escape codes had been dealt with, so the end result, once the escape characters had been removed, was indented all over the show :) Here's that example after I've made my window quite narrow:
I'd show code, but I'm guessing lisp won't help you, and the actual wrapping is a hand-off to a library function. The custom logic is essentially:
I'd figured that the "2+ spaces" heuristic might be a fragile thing to rely on, but it seems to apply in all the cases I've checked so far. |
Yes, I guess it's trickier on your side, as I do get to process plain text (without the escape codes -- the colour properties are stored differently by that point). I presume there must be code handling this for the current build system in order to wrap at the current 100 columns, but I've no idea whether it would be easily re-usable or adaptable for dynamic wrapping. |
Well, I've spotted some counter-examples in
Those rogue double-spaces mean I end up with the likes of:
I believe those are both errors in the original data, but it does prove that my approach is brittle. I'd happily live with these occasional minor issues, though -- the pros greatly outweigh the cons. |
Since this hasn't seen much attention in the last year, I thought I'd post my kludgy workaround. I like to read the docs with a single command
(using this uses the wrapping baked into the files) # unfold is this awk script, which tries to undo the effects of fold.
alias unfold='awk '"'"'(length($0) < 70){print $0}(length($0)>=70){printf $0}'"'"
# Custom build of fold accounts for escape sequences
cheatpp () { cheatp $1 --color | sed 's/^ */ /g' | unfold | fold -sw $COLUMNS; };
The custom build of fold is a modification of fold from ctools, with a hack which tries to account for escape sequences (just by subtracting a fixed amount). diff --git a/src/fold.c b/src/fold.c
index eb48a2d..f6d97cf 100644
--- a/src/fold.c
+++ b/src/fold.c
@@ -166,6 +166,8 @@ fold(char * const path, const long w, const unsigned int mode)
cp = 0;
} else if (buf[i] == '\t') {
cstep = 9 - cp % 8;
+ } else if (buf[i] == '\e') {
+ cstep = -3;// zach hack!
} else {
cstep = 1;
} The result is a colored output, which fits the size of the current terminal (whether narrow or wide), but has preceding indentation replaced with a single space. |
At present, regardless of the terminal width, doc output seems to wrap at ~100 columns. I'm not sure whether this formatting is under psysh's control, but if so then it would be nice if it used the actual terminal width (or else used 80 columns, which is a much safer assumption for a hard-coded value).
The text was updated successfully, but these errors were encountered: