RFC positions in streams of text

[Jose E. Marchesi]

Hi Chris.

> Good afternoon everyone,
>
> I'm more or less back in the thick of things with transput.  One of the core
> concepts in both the RR and van Vliet is that of "position" in the text of the
> file, which is defined in the RR on p.141 as:
>
> {private} mode Pos = struct (int p, l, c);
>
> This triple is meant to indicate:
> - the page number within the text;
> - the line number within the current page;
> - the character number within the current line.
>
> Back on 20 December, Jose and I had an exchange about transput where he
> offered some opinions about the above.  He stated:
>
>> For character transput, structuring the files being edited in
>> pages/lines/char is something that currently every application wishing
>> to edit text structured data have to do by themseves, on top of the
>> simplistic stream-of-bytes I/O systems: you should handle newline, you
>> should keep count of the number of lines you are reading or writing,
>> which column I am right now, etc.
>>
>> IMO it is cool for the transput system to implement the complexity of
>> dealing with structured text.  Like so many other things, I/O systems
>> got simplified way too much.
>>
>> One may argue about pages.  With some few exceptions (like the GNU
>> custom of using ^L characters to group related information) almost
>> nobody bothers to structure their text files into pages.  So we may want
>> to simplify the book to be a collection of lines/chars, rather than
>> pages/lines/chars.
>>
>> However, nowadays paging made a comeback by being used extensively in
>> contents provided by web servers, where the result of a query is very
>> often paged, to be fetched page by page.  So we may want to keep the
>> page/line/char after all.
>
> I'm coming to the conclusion, after thinking about this on and off for quite
> awhile, that I should either
> - follow Mountbatten (dispense with page and line numbers except for channels
>   like tapes or screens where that could make sense) or Marcel (just generally
>   dispense with page and line numbers completely); or
> - emprace them completely.
>
> Thinking about "embracing them completely" for a minute - to me this means
> that in files that are streams of text (ie not binary mode)
>   - use "'f" (form feed) as the way to separate pages
>   - use "'n" (line feed) as the way to separate lines
>
> To do this when writing or reading text files sequentially, I need to count
> form feeds and line feeds, call line_ended when reading or writing a line
> feed and call page_ended when reading or writing a form feed.
>
> When reading sequentially, the set procedure will require reading character by
> character, counting line and form feeds until the (p, l, c) values passed to
> set are reached.

The sequential nature of the operation is also required because as you
observe below the stored data is UTF-8.

> When writing sequentially, this type of "set by reading" is not feasible on
> stand_out_channel, since it may not be opened for reading + writing.  It may
> be feasible to work this way when writing sequentially on stand_back_channel,
> but only when the desired set position is before the current write position
> (which is the end of file by definition if I am correct).

This is interesting.

According to the RR the requirements for a File opened through
stand_out_channel ("a channel value whoe field selected by 'put' is a
routine which always returns true, and whose other fiels are some
suitable values") is that put_possible should always be true.

So, when we "open" a filesystem file via stand_out_channel, we can
distinguish between two possibilities:


a) The filesystem file can be read.  In this case set_possible for the
   File is true.

b) The filesystem file cannot be read (it is write-only).  In this case
   set_possible for the File is false.

In other words: set_possible is contingent to the underlying filesystem
file to be readable.  I think this would be conformant to the RR.

WDYT?

> As for reading and writing at random locations throughout a file, I need to
> think about this a bit more.  I guess by definition write at a random
> location does not move the end of file.
>
> And as for binary files, I'm not addressing them as yet.
>
> So in sum, I guess I'm leaning into the "embrace completely" camp, at
> least as far as dealing with text in filesystem files.

I agree it is better to embrace the 3D view of the textual space of
transput files.

> NB what I am counting are Unicode characters in the program and not
> UTF-8 characters in the filesystem (which also seems kinda weird).
>
> Any comments, doubts?

What about allowing the user to configure the line terminator and page
terminator characters, with suitable Unicode defaults like \n and \f?