Should (STREAM CHARPOS) by the generic \OUTCHAR ?

[rmkaplan]

The common behavior is that CHARPOS is set to 0 on an EOL and otherwise incremented by 1. This controls the behavior of the linelength-sensitive printing functions; they check to see whether this goes over the stream's LINELENGTH (if not infinite), and go to a newline if there would be overflow.

Currently the update to CHARPOS has been a responsibility of the different outchar implementation functions, but I noticed some cases where this little wrinkle has been neglected.

This behavior could be moved up to the generic \OUTCHAR and removed from where it appears in the existing format-implementation functions. Which would guarantee that CHARPOSITION would always be updated in the same way no matter what the format--it would then be the LINELENGTH setting of the stream that would affect how PRIN1 etc. behave

It seems better to me in principle to make CHARPOSITION-updating as a generic property of outing a character, and that the CHARPOSITION manipulations should be removed where it exists in current functions. Versus making sure that each outchar implement does the right thing.

Is there a reason not to make it generic?

(Note: this is different than the rightmargin calculations for display streams, which appears to deal with overflowing of individual character images. CHARPOS/LINELENGTH are trying to keep atoms/strings intact.)

[nbriggs]

I think CHARPOS is at best an approximation, but it begs the question of whether any of the existing code decrements CHARPOS on output of a backspace or any other character that it thinks might change the output position (tab?)

[masinter]

Careful. The reason for not changing existing interfaces is that we haven't examined the uses in the applications we want to run: notecards, loops rooms; we haven't examined if there is a Common Lisp conformance requirement, or all of the LispUsers packages.
People discovering a bug wouldn't fix it but patch around it. When you "fix" the current "bug" it causes their patch to not work (as happened with Notecards and the change of W vs WINDOW -- messing up the ADVISE.

I noticed that PRINT in windows wasn't wrapping properly. Is it LINELENGTH or CHARPOS or something else.

Finally, if the default font is not fixed width - wrapping should take into account the width in pixels or fractions thereof and not pay attention to character counts.
Try FONTSET(BIG) -- our advice for people like me who can't read the tiny letters when displayed on a high-res monitor.

[masinter]

#399 makes old and new lisp sources prettier when viewing in Linux by changing colors instead of font

[nbriggs]

Finally, if the default font is not fixed width - wrapping should take into account the width in pixels or fractions thereof and not pay attention to character counts.

That's the job of the DSP... functions. At the point where CHARPOS and LINELENGTH are being dealt with you don't know anything about what font it might be displayed in later (e.g., output to a regular file)

[rmkaplan]

Yes, that’s the rightmargin calculation that I mentioned, which is done at a lower per-character (not per string or atom) level. This could be rationlized also, by making LINELENGTH, CHARPOSITION, POSITION, TAB have stream-dependent functions which could multiply their arguments by the average width of a character, or the width of the space in the default font. Systematically mapping character numbers to screen points. This would be another shake-down cruise.

…

On Aug 8, 2021, at 12:56 PM, Nick Briggs ***@***.***> wrote: Finally, if the default font is not fixed width - wrapping should take into account the width in pixels or fractions thereof and not pay attention to character counts. That's the job of the DSP... functions. At the point where CHARPOS and LINELENGTH are being dealt with you don't know anything about what font it might be displayed in later (e.g., output to a regular file) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#401 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMSRYX5J7DI3DCCG5DT33OQFANCNFSM5BYYSE3Q>.

[rmkaplan]

I think that legacy systems should attach themselves to specific sysouts that they know they work in. They can try to track the evolution of the future-oriented code if they see any advantage and want to do their own testing and verification. But I don’t think that legacy systems should be the inertia that stands in the way of sensible changes to fix bugs and nonfeatures or to remove at least a few obstacles that make the system unattractive to potential new users or applications.

…

On Aug 8, 2021, at 12:38 PM, Larry Masinter ***@***.***> wrote: Careful. The reason for not changing existing interfaces is that we haven't examined the uses in the applications we want to run: notecards, loops rooms; we haven't examined if there is a Common Lisp conformance requirement, or all of the LispUsers packages. People discovering a bug wouldn't fix it but patch around it. When you "fix" the current "bug" it causes their patch to not work (as happened with Notecards and the change of W vs WINDOW -- messing up the ADVISE. I noticed that PRINT in windows wasn't wrapping properly. Is it LINELENGTH or CHARPOS or something else. Finally, if the default font is not fixed width - wrapping should take into account the width in pixels or fractions thereof and not pay attention to character counts. Try FONTSET(BIG) -- our advice for people like me who can't read the tiny letters when displayed on a high-res monitor. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#401 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNIHEAXAUX7AMFZLO3T33MMRANCNFSM5BYYSE3Q>.

[masinter]

it isn't anachronistic -- modern systems often rely on fixed-width fonts (with color changes for inline emphasis),
for programmer use.

[rmkaplan]

The question of whether or not we should be calculating line breaks in font-widths vs. character counts is a more complicated and different question than what I was asking about here: whether or not the conventions for setting CHARPOSITION and reverting it to 0 on EOL should be a generic property of \OUTCHAR or a requirement that each format-implementation must deal with.

Can we contemplate an external format whose OUTCHAR function doesn't want to increment CHARPOSITION on ordinary characters or set it back to 0 on an EOL. If not, then moving it to the generic \OUTCHAR would make simpify the format-implementations and guarantee consistency.

This has to do with trying not to break up atoms or strings when they hit the margin, the basic PRIN1/PRIN2 level. Getting proper alignments with variable-spaced fonts might be more at the higher level of pretty-print. But then of course the layout would likely be quite screwed up if the file is viewed as text in an environment that doesn't have access to the font information

[masinter]

we might want to step back and consider the fundamental architecture before doing more here.
stream types are made for object oriented programming but we're not using it here in a natural way. Let's consider why.

[masinter]

not sure what to do with this. There are problems mentioned which seem to just be bugs -- things that used to work (like line-wrapping on spaces rather than just at character boundaries -- but this was an architecture question which seems still open...
=> Discussion