Peculiarities with printing(BOUT) to a Tedit stream

[rmkaplan]

A Tedit stream has 2 personalities, as the basis for interactive text editing and as a Medley file stream. I don't think all the details of their behavior and how they interact were worked out in the Venue years.

On the one hand a Tedit stream is set up as a normal text editor that supports selection, insertion, deletion, looks-changes etc. Typically those are specified by on-screen keyboard actions, but there are also public functions (TEDIT.INSERT, TEDIT.DELETE, TEDIT.GETSEL, TEDIT.SETSEL and others) that allow programs to manipulate the stream whether or not it is on screen. (If it is onscreen and those functions are called, the screen is updated to reflection the changes).

On the other hand, the Tedit stream acts (mostly) like a Medley file stream. You can read from it, write from it, move the file pointer around, etc. Importantly, Tedit using the stream interface internally for line formatting and display, as changes are made through the editing interface. Also for hardcopy.

The behavior we inherited from Venue leaves some things to be desired.

1. The Tedit BOUT doesn't actually act like BOUT's on other file streams. Normally, if BOUT is called when the file is positioned at a particular byte in the middle of the stream (GETFILEPTR), the character at that position is replaced by the new character. But Tedit's BOUT currently doesn't do an insertion, it does a replacement. It inserts the new character in front of the character at that position, everything at that position and beyond is pushed back, and 1 is added to the length of the stream. (There is no difference in the typical case when appending to the end of the stream.)

The current behavior seems wrong. OK to change it from insert to replace?

2. Edit insertions are typically undoable. Since BOUT is currently going through the standard character inserter, the bouting is also undoable. The history list will get very long, and every sequence of BOUT's will be undoable possibly as a single event. Is this a good idea?

3. Tedit treats image objects as pseudo-characters, with respect to most internal operations. This leaks over into the stream interface, in that BIN will return an image object if it is the next character at the file ptr. Should BOUT also be able to install an image object, to complete the analogy? Currently a separate object-inserting functions is need to insert an object.

4. If the stream is being displayed and a character is bouted, should the screen update? What if a character is bouted (insertion or replacement) in a part of the stream that is not currently visible. Should the display scroll to show where the change happened? That's what happens if the caret is off screen and a character is typed.

Those are the easy questions. The more difficult and confusing issues concern the stream/edit interactions. The edit operations can step on the file pointer in a way that is difficult for a stream-client to predict.

For editing the selection has a notion of the insertion point (the caret), that moves around through the editing interface (clicking etc). If you type, that's where the character gets inserted. Sometimes GETFILEPTR will give you the caret's byte position, but you can't count on that. SETFILEPTR will set the file pointer without changing the selection, so that the two diverge. And displaying lines may change the file pointer implicitly, since the formatter sets the file pointer in order to do its internal binning. The worse case is scrolling: the selection stays where it is (even if no longer visible) but the file pointer moves to the position at the end of the last line updated on the display.

Even if the lines are not being displayed, if you use the TEDIT.INSERT/TEDIT.DELETE operations on a selection at a position before what you think is the current file position, you can get unexpected results. Suppose you get the file ptr and save it, because you want to restore it after something else you want to do. If then you insert 5 characters before that position, setting the file pointer back to that saved value will point to a character 5 before what you thought it was pointing to before. (And again, if the display is running, the position will depend on the character of the last changed line in the window.)

Is there a sensible way of arranging the interaction of these two modes? Or should they be made mutually exclusive--a stream is either in edit/selection mode or bin/bout/fileptr mode, and you have to explicitly switch between those modes.

[masinter]

it sounds like some kind of stream composition, like with (Common Lisp) synonym, broadcast, etc.

Where does the EXTERNALFORMAT fit into the picture -- if you're reading and writing bytes with BIN and BOUT, that's below the level of in and out characters (or characters with looks + image objects).
I thought GETFILEPTR and SETFILEPTR only work at the byte level.
You trust that the user won't SETFILEPTR into the middle of a UTF-8 single-character-multiple-byte sequence.

But Tedit's BOUT currently doesn't do an insertion, it does a replacement. It inserts the new character in front of the character at that position
Is your first sentence backwards?

1. I think the insert feature is the only one that makes sense because of the possible mismatch of lengths with external formats.
2. i think undo info can be compacted simply.
3. BOUT can install an image object that was previously BIN'ed and turned into a private use character.
4. of course update if the window is showing the text taht would be there if you did a redisplay.

"

[rmkaplan]

Perhaps it could have been imlemented as a CL stream composition if that had been available in those days, although probably with less efficiency at least in the case of 7-bit Ascii regions of UTF-8 backing streams or char-set 0 regions of XCCS backing streams. But I don’t think that would have changed the issues that I am currently looking at. But for context: A text stream (OPENTEXTSTREAM) is a stream with its own external format (of type :TEXTSTREAM) that implements the bin/peek/back/outchar/fileptr... functions that support the generic BIN/BOUT/PEEK/BACK/GETFILEPTR... functions. The text stream stands in front of whatever storage arrangement contains the content that its characters are derived from. The backing storage can be one or more files each with its own external format (UTF8, XCCS...), a thin or fat string, or an imageobject. The textstream decodes the backing storage so that its BIN, BOUT … implementation functions (\TEDIT.TEXTBIN, \TEDIT.TEXTBOUT, \TEDIT.TEXTGETFILEPTR…) always traffic in Medley’s internal codes (currently XCCS) and image objects. The only way that users can do a SETFILEPTR into the middle of a utf-8 sequence would be to get hold of the actual backing-file stream inside the textstream, and then set its fileptr. Depending when/how that might happen, it could really screw things up. Note also that even if a section of the text stream is backed with a file, that file is not modified as editing or bouting is carried out; the changes are all recorded internally in strings that are only saved to a file by doing an explicit Put. It has always been the case that “byte” and “character” on a textstream are essentially equivalent. When you set the fileptr to N and BIN, you will get the 16-bit SMALLP character (or image object) at logical position N+1 in the document, no matter how that may be derived from the backing information. If you BOUT a character code at a given position, go back to that position, and BIN, you will get that character. You are right that my first sentence was backwards. I meant "But Tedit's BOUT currently doesn't do a replacement, it does an insertion. It inserts the new character in front of the character at that position” The problem is that that is not the way BOUT works on other streams—they all replace.

• I think the insert feature is the only one that makes sense because of the possible mismatch of lengths with external formats.

There can't be a mismatch, because the replacement happens in the textstream, not in any of the backing stores no matter how they may be formatted.

• i think undo info can be compacted simply.

Perhaps. A history event has to keep track of the character that was replaced as well as the position. And events have to be linked together. You probably wouldn’t want to do this for a textstream that was used as a Trace or Exec window—you can scroll the past and extract from it, but you can’t undo it. A sequential run of bouts could be collected into a single event, which is what happens as you type in. This history would intermix with any interactive editing events, which may make logical sense.

• BOUT can install an image object that was previously BIN'ed and turned into a private use character.

I’m not sure: are you proposing for BOUT to associate a private code with an image object, and that that code would be returned by BIN instead of the object?

…

On May 9, 2024, at 1:08 PM, Larry Masinter ***@***.***> wrote: it sounds like some kind of stream composition, like with (Common Lisp) synonym, broadcast, etc. Where does the EXTERNALFORMAT fit into the picture -- if you're reading and writing bytes with BIN and BOUT, that's below the level of in and out characters (or characters with looks + image objects). I thought GETFILEPTR and SETFILEPTR only work at the byte level. You trust that the user won't SETFILEPTR into the middle of a UTF-8 single-character-multiple-byte sequence. But Tedit's BOUT currently doesn't do an insertion, it does a replacement. It inserts the new character in front of the character at that position Is your first sentence backwards? • I think the insert feature is the only one that makes sense because of the possible mismatch of lengths with external formats. • i think undo info can be compacted simply. • BOUT can install an image object that was previously BIN'ed and turned into a private use character. • of course update if the window is showing the text taht would be there if you did a redisplay. " — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>