medley
medley copied to clipboard
Interlisp
Glitches when using 'prc'
minor glitch -- when the 1106:229 on the right is selected, the left side has a section on the left still underlined.
plus various other glitches with prc and not this PR. Made into a separate issue. Also, the linelength when prettyprinting is too big and the lines wrap in a way that makes the code hard to read.
Originally posted by @masinter in https://github.com/Interlisp/medley/pull/799#issuecomment-1163904878
The "See" command goes to PRETTYFILEINDEX, which seems to be setting linelength to the output-stream's width divided by the width of space in the streams current font. Which seems like the right idea. Except that it isn't clear that the width it is measuring is actually the width of the wndow.
It formats pretty well for me, but I think the fonts in my fontset are a little smaller than yours
Actually, for source-compare, it is in fact reprinting the s-expression, using TEDITDEF called from EXAMINEDEFS. (It doesn't use SEDIT because I don't know how to highlight differences there).
TEDITDEF can be informed about an appropriate linelength. There are 3 parameters: target window/region width, font size, and the default linelengths. In this case the window/region is given, so linelength should be computed from that. If the window isn't specified, then perhaps the suggested width for the region should be calculated from the linelength and font.
I think it might be better to calculate the linelength from the region and font rather than the region from the linelength and font. Since the region is determined mainly by the screen dimensions and placements.
Looking at why PRETTYFILEINDEX fails on bitmaps.
It gets a "NIL is not a number error" in PFI.PRINT.BITMAP. The NIL is coming from a call to DSPTOPMARGIN, which DINFO describes as:
"The top margin is an integer that is the Y position after a new page (in the image stream's coordinate system). This function has no effect on windows."
Any idea what a reasonable default value would be? 0? 65535?
It's using this to compute a scaling ratio
Actually, in this context I think MAX.SMALLP is the best, just means that the vertical difference won't be calculated in determining the scale. The bitmap may or may not be printed anyway, when you aren't going to a hardcopy file (maybe it should just print the characters, not the picture?)
Anyway, this won't cause an error now
i found this issue trying a demo of "pick" and I think that whatever I was complaining about has been fixed enough that I will close it. Feel free to reopen, or better write a new, clearer issue and if you must, reference this one.