Type of TEDIT's first argument and editing text in memory

[Paolo Amoroso]

Section "1.2 Invoking TEdit" of Stephen Kaisler's book Medley Interlisp: Interactive Programming Tools, on page 38 of the PDF file, describes the TEDIT Lisp function for invoking TEdit. The first argument is listed as "TEXT, a text specification" but the book doesn't seem to explain what a text specification is anywhere else.

What type(s) are allowed for the TEXT argument? The TEDIT function accepts a stream and a filename as the first argument, but not a string not designating a file.

Can TEdit edit an arbitrary string or other text in memory? The only way I found is by passing a string stream to TEDIT like (TEDIT (OPENSTRINGSTREAM "Some text")), but the TEdit buffer includes unprintable characters likely due to encoding conversion issues.

Paolo

--

Blog | Mastodon

[Paolo Amoroso]

According to chapter 8. Programmer's Interface to Tedit of TEdit's user's guide:

"TEXT may be a file name, an open STREAM, a string, or an arbitrary (MKSTRING-able) Lisp object."

[Paolo Amoroso]

Thanks, makes sense. But (TEDITSTRING "Some text") has the same character encoding issue as (TEDIT (OPENSTRINGSTREAM "Some text"), like the attached screenshot that shows the output of the TEDITSTRING call in Interlisp Online.

[Ron Kaplan]

Hmm, I don’t see that.  Can you send a snapshot of the string itself?  Also can you show the result of (CHCON “shift-select-that-string-from-the-Tedi-window”).

If those black boxes correspond to zeros, that would be an external-format issue.  You have a “fat” 2-byte string that somehow isn’t being recognized as such.

If you (INSPECT (OPENSTRINGSTREAM “that string”)) and scroll down to the bottom of the inspect window, you should see that it has a STRING exernal format.  Let me know what you see there.

On Mar 19, 2023, at 11:04 AM, Paolo Amoroso <paolo....@gmail.com> wrote:

Thanks, makes sense. But (TEDITSTRING "Some text") has the same character encoding issue as (TEDIT (OPENSTRINGSTREAM "Some text"), like the attached screenshot that shows the output of the TEDITSTRING call in Interlisp Online.

<teditstring.png>

[Nick Briggs]

I just tried it with a new full loadup made on the current medley master branch, and I see what Paolo sees.

The result of OPENSTRINGSTREAM is an Input Basebytes stream that is externalformat STRING.  (READCCODE …) does the right thing.  Shift-selecting it into an exec from (old) TEDIT is fine. The extra bytes are zeros.

--
https://Interlisp.org for more details
---
You received this message because you are subscribed to the Google Groups "Medley Interlisp Users/Interest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to interlisp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/interlisp/85F3A12C-1C35-48D7-A310-04B928E5DA81%40post.harvard.edu.

[Paolo Amoroso]

I attached a screenshot showing the information you asked for. When inspecting the string I shif-selected it from the TEdit window too.

I'm using Interlisp Online on a Chromebox under chromeOS.

--

Blog | Mastodon

[Ron Kaplan]

OK, I also see it in the released/master system.

I don’t see it in my Tedit-working system.  I’ll see if I can back-patch it.

To view this discussion on the web visit https://groups.google.com/d/msgid/interlisp/02A543D4-FE1A-4B2C-9497-B7CB9C53EBF3%40gmail.com.

[Ron Kaplan]

This was a change made about a year ago, to remove from the Tedit interface the ambiguity of file designation that was left over from the Common Lisp integration.

Originally, files in Interlisp were designated by literal atoms, not strings, so a string passed to Tedit could be interpreted unambiguously not as a file-identifier but as the immediate target of the edit.  But Common Lisp says that files can be designated by “namestrings” as will as by pathnames. 

In the interests of consistency, Tedit was changed to remove the ambiguity and conform to the Common Lisp convention.  We provided a separate way of calling TEDIT that simulates the old Interlisp behavior:

Calling (TEDITSTRING XXX …) instead of (TEDIT XXX …) will call TEDIT with (OPENSTRINGSTREAM XXX) if XXX is a string, otherwise just Tedit.  (Tedit still also interprets atoms as file designators.)

There were relatively few calls in the system and in Notecards that were clearly passing strings (usually to put up an error message in the Tedit window when the intended target couldn’t be found).  Those calls were changed to TEDITSTRING.

The documentation has not yet been updated (in fact, I am still unclear where (or whether) we have the sources for the Tedit documentation).

On Mar 19, 2023, at 8:58 AM, Paolo Amoroso <paolo....@gmail.com> wrote:

According to chapter 8. Programmer's Interface to Tedit of TEdit's user's guide:

"TEXT may be a file name, an open STREAM, a string, or an arbitrary (MKSTRING-able) Lisp object."

--
https://Interlisp.org for more details
---
You received this message because you are subscribed to the Google Groups "Medley Interlisp Users/Interest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to interlisp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/interlisp/23626167-728b-4586-8360-26cbb56f65d9n%40googlegroups.com.

[Paolo Amoroso]

On Sunday, March 19, 2023 at 3:04:58 PM UTC+1 Paolo Amoroso wrote:

Can TEdit edit an arbitrary string or other text in memory? The only way I found is by passing a string stream to TEDIT like (TEDIT (OPENSTRINGSTREAM "Some text")), but the TEdit buffer includes unprintable characters likely due to encoding conversion issues.

The problem seems that OPENSTRINGSTREAM fattens its string argument, even if it's thin. See the comment in the source:



TEdit works as expected with a file stream, including an in memory {NODIRCORE} stream. In this case the text read from the stream has no spurious characters.

[Ron Kaplan]

Yes, the black-boxes in string editing are due to the fact that OPENSTRINGSTREAM fattens its strings to simplify its own character reading functions (maybe not a useful optimization). That’s just a bug. But separately, whether any string, or any string-sream, is fat or thin should not be visible at the user level.

The problem with the released Tedit is that it doesn’t have the proper flag set for these streams, and I haven’t wanted to go into that while I’m trying to revise a whole bunch of other stuff.

It is a different issue whether Tedit can be used to “edit” a string.  The model is that a string-stream is just like a file-stream:

Tedit doesn’t actually modify a file as you do the edits, it effectively reads (“gets’”) the file-contents, and stores the modified contents back when you do a put, to a new version of the same name or to a file with a different name.  So you essentially copy in, make changes, copy out.  Until you do a put, the file is read-only (although the textstream is not.)

String-streams are the same way:  you effectively copy the contents of the stream into Tedit, make changes like any other stream.  Afterwards you can put the changes to a file, in the ordinary way.  

What may seem counterintuitive, in the case of string-streams, is that you can’t directly “put” the modified characters back to the same string-datum (growing it or shrinking it in some way, but maintaining the same pointer).And you can’t see the changes in the string, if you kept a pointer to it, as you go along.  But in that it is just like editing any other information source.

But there are two ways of getting a string that contains the character-sequence of any textstream, no matter what its original sources, the function COERCETEXTOBJ and TEDIT.SEL.AS.STRING, both of which are documented.

So:

(SETQ FOO (TEDIT (OPENTEXTSTREAM “abc”))   (or (TEDIT ‘{DSK}XXX.TEDIT))

   edit edit edit

(COERCETEXTOBJ FOO ’STRING)  

     (in current released TEDIT you may have to pass (TEXTSTREAM FOO) instead of FOO—TEDIT returns the process handle)

I hope this is useful.

On May 8, 2023, at 8:30 AM, Paolo Amoroso <paolo....@gmail.com> wrote:

On Sunday, March 19, 2023 at 3:04:58 PM UTC+1 Paolo Amoroso wrote:

Can TEdit edit an arbitrary string or other text in memory? The only way I found is by passing a string stream to TEDIT like (TEDIT (OPENSTRINGSTREAM "Some text")), but the TEdit buffer includes unprintable characters likely due to encoding conversion issues.

The problem seems that OPENSTRINGSTREAM fattens its string argument, even if it's thin. See the comment in the source:

<openstringstream.png>

TEdit works as expected with a file stream, including an in memory {NODIRCORE} stream. In this case the text read from the stream has no spurious characters.

--
https://Interlisp.org for more details
---
You received this message because you are subscribed to the Google Groups "Medley Interlisp Users/Interest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to interlisp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/interlisp/28332d86-bedf-48d5-a819-212c37fa2240n%40googlegroups.com.
<openstringstream.png>

[Paolo Amoroso]

On Mon, May 8, 2023 at 6:19 PM Ron Kaplan <ron.k...@post.harvard.edu> wrote:

But there are two ways of getting a string that contains the character-sequence of any textstream, no matter what its original sources, the function COERCETEXTOBJ and TEDIT.SEL.AS.STRING, both of which are documented.

So:

(SETQ FOO (TEDIT (OPENTEXTSTREAM “abc”))   (or (TEDIT ‘{DSK}XXX.TEDIT))

   edit edit edit

(COERCETEXTOBJ FOO ’STRING)  

     (in current released TEDIT you may have to pass (TEXTSTREAM FOO) instead of FOO—TEDIT returns the process handle)

Thanks, this helps for the use case I had in mind: using TEdit as an external text editor from other programs which feed it some text to edit and get back the result. And yes, I do have to pass (TEXTSTREAM FOO).

--

Paolo Amoroso | Blog | Mastodon