lafite>LAFITE-INDENT needs some work

[rmkaplan]

It may still depend on some TEDIT internals, and it may still have some confusion between paragraphs, selections, and the part of a selection that is visible in one or more split windows.

This is not LAFITE-specific, should be moved out to Lispusers and perhaps renamed as TEDIT-INDENT.

[rmkaplan]

This lays out some of the more general issues that came up in the 3/10/2025 meeting that relate to the functionality that LAFITE-TEDIT is providing. LAFITE-TEDIT is specifically oriented towards unformatted (non-TEDIT) unwrapped email that presumably comes from or goes to an outside source.

Incoming emails can be hard to read and edit because lines within a paragraph are broken according to their internal EOL's without regard to the width of the Tedit window. And a message with that has been edited or reformatted for readability in Tedit may have unpleasant line breaks if it is forwarded or replied to a non-Tedit reader, particular if the standard conventionis applied of indenting an included message in a reply.

So for example, LAFITE-INDENT provides some functions for coercing paragraph-internal EOL's to spaces, so that the lines will wrap in the Tedit window. It also provides a function for indenting lines (as in a reply) by sticking some padding string at the beginning of each line and inserting temporary line breaks to prevent lines from overflowing.

One problem with this implementation is that it its strong focus is on lines and how to manipulate them, without clearly dealing with how selections, paragraphs, and window-panes interact in Tedit. Thus, the lines of a document only exist when they are visible in a window pane, whether or not they are selected, and different lines of a selection may appear in different panes of a split window. And selections can begin in the middle of lines and can lines in different paragraphs. Understanding and modernizing the current code might not be so easy.

But it also seems that the functionality it aims for is not restricted just to email conventions, it is also relevant to any plaintext file that Tedit might import or export.

Paragraph internal linebreaking can be a unpleasant when any plaintext file is opened (not just for Tedit, but for other editors). That calls for a separate function that can be applied to selected paragtraphs (not lines) when a plaintext file is imported, or perhaps at some other point in the session. That function would replace itnernal EOL's with spaces, and maybe replace multiple EOL's by paragraph breaks. That transformation might or might not make it be a Tedit formatted file, but it would be readable and easier to edit.

Separately, when a file (formatted or not) is saved as a plain text file, the opposite transformation can be applied: convert the file to a plaintext file by replacing spaces with EOL's at what would be Tedit line breaks (or based on a LINELENGTH parameter that doesn't depend on the window or margins). And then put the file as plaintext.

There could be a mode (as in LAFITE-INDENT) that remembers which EOL's were originally replaced by spaces, and use convert those back.

Indentation seems like a separate issue. The easiest way to indent, after a file (plaintext or not) has been read in, is to change the margins with the paragraph looks menu (or, with the newer key bindings, meta-[ and meta-]) or by executing the paragraph-looks function. Lines will flow in an easy-to-edit way, if the document was plaint-text to start, that change will make it formatted.

So another transformation can be performed when the file is exported as plaintext, as an embellishment on the algorithm that inserts EOL's for spaces in long lines. As the lines are being broken up, a fixed string of spaces can be inserted at the beginning of each line, the length of which would roughly correspond to the margin in the current font.

On this scheme a plaintext file can be TEditified so that it is easy to read and modify in Tedit, and a formatted Tedit file (whether originally plaintext or not) can be put as a plaintext file that external viewers can more happily read and/or modify.

[rmkaplan]

On further thought, I think the problem of having Tedit simulate margins and indentations when doing a plaintext put can be solved by essentially removing Tedit's current strategy for producing plaintext files altogether, and replacing it with a separately defined plaintext imagestream.

Currently Tedt produces a plaintext file by writing out the content-part of the file, as if it was a formatted file, and then simply discarding the formatting information. If we had a plaintext imagestream (do we?), we could reimplement a Tedit (or any other) plaintext put as a straightforward hardcopy to such an image file.

A plaintext stream would have to be told the scale/point-width of an average character in the (presumably fixed-pitch) font that it might be expected to be viewed in. Its margin method (actually DSPXPOSITION, but only moving forward) would have to approximate the left margin by spaces, but Tedit would automatically put EOL's on the right. DSPYPOSITION (only down) would be approximated with EOL's.

If the primitives are properly defined, I think we would get margins and line breaking, old-fashion add-spaces justification, and centering for free. And double-spacing and multiple linefeeds between paragraphs, depending on how each paragraph's line-leading and paragraph leading are approximated.