Re: ENB: Are huge Leo outlines possible?

[tbp1...@gmail.com]

I remember writing the manual for the electronic device I had designed on 
our 8k 8/i using the asr-33 teletype. We had no other text display, so that 
was the output display as well. I can't remember any more how I edited it 
after first typing it.  We did have a fixed head disk unit, and I must have 
stored it there, but it's been too long...

On Thursday, December 10, 2020 at 8:51:30 PM UTC-5 David Szent-Györgyi 
wrote:

> On Wednesday, December 9, 2020 at 10:11:01 AM UTC-5 tbp1...@gmail.com 
> wrote:
>
>> Ah, the pdp-8, a trip down memory lane.  I used an 8i extensively in the 
>> early 70s, but did not make the acquaintance of TECO.  After looking it up 
>> on Wikipedia, I' m glad I didn't.  Remember how 3 ascii characters were 
>> packed into two 12-bit words?  And while the 8e may have come with 12k of 
>> RAM, the 8i came with 4k, unless you had the money to get the extension to 
>> 8k (which ours had).
>>
>
> Some of TECO's ugliness has to do with the media it supported, including 
> (if I recall correctly) paper tape(!). I used it with files on floppy disk, 
> fortunately for me. 
>
> The 8/e I used had two ASR-33 teletypes and two (two!) eight-inch floppy 
> disk drives, using disks which held 250KB if I recall.  We used OS/8 for 
> single-user computing with access to the disk drives, and a time-sharing 
> BASIC for two-user computing with paper tape for program storage. One of 
> our projects was to modify a time-sharing BASIC with support for DEC's 
> floppy disk drive unit to work with the third-party drive unit we used; 
> after several years of work by us high school students, we figured out that 
> the BASIC depended on the interrupts generated by DEC's floppy controller; 
> the third-party unit used programmed I/O, and could not generate interrupts!
>
> Ah, nostalgia. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0d4840b3-499a-4f24-947e-37d83acbe01cn%40googlegroups.com.

Re: ENB: Are huge Leo outlines possible?

[David Szent-Györgyi]

On Wednesday, December 9, 2020 at 10:11:01 AM UTC-5 tbp1...@gmail.com wrote:

> Ah, the pdp-8, a trip down memory lane.  I used an 8i extensively in the 
> early 70s, but did not make the acquaintance of TECO.  After looking it up 
> on Wikipedia, I' m glad I didn't.  Remember how 3 ascii characters were 
> packed into two 12-bit words?  And while the 8e may have come with 12k of 
> RAM, the 8i came with 4k, unless you had the money to get the extension to 
> 8k (which ours had).
>

Some of TECO's ugliness has to do with the media it supported, including 
(if I recall correctly) paper tape(!). I used it with files on floppy disk, 
fortunately for me. 

The 8/e I used had two ASR-33 teletypes and two (two!) eight-inch floppy 
disk drives, using disks which held 250KB if I recall.  We used OS/8 for 
single-user computing with access to the disk drives, and a time-sharing 
BASIC for two-user computing with paper tape for program storage. One of 
our projects was to modify a time-sharing BASIC with support for DEC's 
floppy disk drive unit to work with the third-party drive unit we used; 
after several years of work by us high school students, we figured out that 
the BASIC depended on the interrupts generated by DEC's floppy controller; 
the third-party unit used programmed I/O, and could not generate interrupts!

Ah, nostalgia. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c6f5bd5e-ead6-4e36-8682-67b55176ecf5n%40googlegroups.com.

Re: ENB: Are huge Leo outlines possible?

[David Szent-Györgyi]

On Wednesday, December 9, 2020 at 10:30:54 AM UTC-5 Edward K. Ream wrote:

> Yes, and those considerations have nothing to do with teco :-)
>

Leo doesn't need the engineering underlying TECO - fortunately, it doesn't 
have to work on an architecture of segmented memory - but editing text 
files too large to fit in RAM needs careful design of the user interface. 
Here's a short description of TECO's design: 

The original TECO editors were created when computer systems were very 
memory limited, and were therefore optimized to run in small memory 
configurations. One way that this was accomplished was that TECO was a 
*pipeline 
editor*. Text was read from the input file into an edit buffer, and then 
written out to the output buffer. The only part of the file which was 
resident was the edit buffer, and this was typically kept quite small. Once 
text was paged out to the output file, it could not be called up again 
without writing out the entire contents of the files, and then re-reading 
to the point in question. 

If that is not what you plan to deliver, you're going to need to figure out 
an abstraction that doesn't kill performance, and for that you're going to 
need to define use cases. 

An image editor that I support as part of my job handles multi-image files 
that are indexed by number. Navigation among the images in a given image 
editor window is a matter of indicating which image is current. This editor 
allows tens of thousands of images in a single file; it loads into its 
memory buffer as many images as will fit. As the user moves from the first 
image to the last, the editor swaps images between a scratch file on disk 
and RAM. For operations that run image-by-image from first to last, that 
works fairly well. It slows to a crawl on other patterns of access to 
images, because the engineering cannot anticipate all cases. For some of 
those cases, the performant solution is to provide RAM enough to hold the 
all the images in the desired file - or two such images, to provide for 
creation of a modified result. 

For some customers, "RAM enough" means 128 GB. The image editor does not 
need to load all the images from disk when opening a file, but saving a 
multi-image file of 32 GB of data takes time, even on a current-day 
workstation - the data comes from memory, or from the scratch file, it has 
to be written to disk, and the metadata for each image and the file as a 
whole have to be written as well. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ceed18fe-22b5-465f-811a-11ed8fea31b0n%40googlegroups.com.

Re: About the default behavior for externally modifying a .leo file while it's opened in Leo

[Edward K. Ream]

On Thu, Dec 10, 2020 at 4:17 PM jkn  wrote:

> update, after trying with the ekr-change branch:
>
> - making a change in the .leo file (outside of leo) now seems to be noted.
> I still think the dialog text is confusing though. To my mind 'overwrite
> it' smacks of writing something to disc, and the wording should be more
> like ... reload into Leo?"
>

I'll change the dialog.

- just touching the file (ie changing the timestamp) externally doesn't
> seem to be noticed by leo, at least not consistently.
>

That's on purpose. efc.has_changed first checks the timestamps. If they are
different, the code then checks that the contents are different. Only then
does it raise the dialog.

- Leo also fails to restart sometimes after answering 'yes'
>

I'll look into this.

efc.ask does have some weird timing code, which is probably needed because
the dialog is raised as the result of checks that are made periodically at
idle time.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0MxJ8PxAUtmHW9pM9ybpta86v%2B5TY_JrWGkruoX%2BGGoA%40mail.gmail.com.

Re: About the default behavior for externally modifying a .leo file while it's opened in Leo

[jkn]

update, after trying with the ekr-change branch:

- making a change in the .leo file (outside of leo) now seems to be noted. 
I still think the dialog text is confusing though. To my mind 'overwrite 
it' smacks of writing something to disc, and the wording should be more 
like ... reload into Leo?"

- just touching the file (ie changing the timestamp) externally doesn't 
seem to be noticed by leo, at least not consistently.

- Leo also fails to restart sometimes after answering 'yes'

HTH
Jon



On Thursday, December 10, 2020 at 9:59:44 PM UTC jkn wrote:

> OK, I'll give that branch a try. I think I was confused because the 
> comments on #1240 did not seem to indicate recent substantive work (ie. in 
> a none-devel branch).
>
> Thanks, Jon
>
>
> On Thursday, December 10, 2020 at 9:40:09 PM UTC Edward K. Ream wrote:
>
>> On Thu, Dec 10, 2020 at 2:08 PM jkn  wrote:
>>
>>> Hi Edward
>>> your explanation of the difference between #1240 and #1771 does, 
>>> thanks. I think my issue is unrelated to any recent insights re. git 
>>> branches etc.
>>>
>>> I have tried the smallest example I could to illustrate what behaviour I 
>>> see, and hope for. This is on:
>>>
>>> Leo 6.4-devel, devel branch, build 30ca7ea314
>>> 2020-12-05 09:26:07 -0600
>>> Python 3.6.9, PyQt version 5.9.5
>>> linux
>>>
>>
>> The ekr-change branch contains the work. See PR #1771 
>> . I'll merge the 
>> branch into devel later today or tomorrow.
>>
>> Edward
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/68d0bd0a-ae3a-4398-9818-545352ff88d5n%40googlegroups.com.

Re: About the default behavior for externally modifying a .leo file while it's opened in Leo

[jkn]

OK, I'll give that branch a try. I think I was confused because the 
comments on #1240 did not seem to indicate recent substantive work (ie. in 
a none-devel branch).

Thanks, Jon


On Thursday, December 10, 2020 at 9:40:09 PM UTC Edward K. Ream wrote:

> On Thu, Dec 10, 2020 at 2:08 PM jkn  wrote:
>
>> Hi Edward
>> your explanation of the difference between #1240 and #1771 does, 
>> thanks. I think my issue is unrelated to any recent insights re. git 
>> branches etc.
>>
>> I have tried the smallest example I could to illustrate what behaviour I 
>> see, and hope for. This is on:
>>
>> Leo 6.4-devel, devel branch, build 30ca7ea314
>> 2020-12-05 09:26:07 -0600
>> Python 3.6.9, PyQt version 5.9.5
>> linux
>>
>
> The ekr-change branch contains the work. See PR #1771 
> . I'll merge the 
> branch into devel later today or tomorrow.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ab5afab8-7097-4efd-89c6-fb79c575b0f9n%40googlegroups.com.

Re: About the default behavior for externally modifying a .leo file while it's opened in Leo

[Edward K. Ream]

On Thu, Dec 10, 2020 at 2:08 PM jkn  wrote:

> Hi Edward
> your explanation of the difference between #1240 and #1771 does,
> thanks. I think my issue is unrelated to any recent insights re. git
> branches etc.
>
> I have tried the smallest example I could to illustrate what behaviour I
> see, and hope for. This is on:
>
> Leo 6.4-devel, devel branch, build 30ca7ea314
> 2020-12-05 09:26:07 -0600
> Python 3.6.9, PyQt version 5.9.5
> linux
>

The ekr-change branch contains the work. See PR #1771
. I'll merge the branch
into devel later today or tomorrow.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1PokQaL7MsVL5avL9rkuhY%2BFzQq0_xFCn3YSbaTaktjw%40mail.gmail.com.

Re: About the default behavior for externally modifying a .leo file while it's opened in Leo

[jkn]

Hi Edward
your explanation of the difference between #1240 and #1771 does, 
thanks. I think my issue is unrelated to any recent insights re. git 
branches etc.

I have tried the smallest example I could to illustrate what behaviour I 
see, and hope for. This is on:

Leo 6.4-devel, devel branch, build 30ca7ea314
2020-12-05 09:26:07 -0600
Python 3.6.9, PyQt version 5.9.5
linux

Steps:

1) In leo, create a new outline, say with a couple of nodes. save as 
myfile.leo.

2) keeping in leo, switch to a console, say. Edit the leo file  (or just 
'touch' it) in a text editor, save & exit

3) switch focus back to leo

4a) hoped for/expected: Leo notices the change and says "do you want me to 
reload the file into Leo?"

4b) observed: leo does not notice the change (yet)

4c) observed: if I then (or, later, after some leo editing activity) try to 
save the file in Leo, the fact that the underlying file has changed *is* 
noticed. I get a dialog box:

dialog title: "Overwrite the version in Leo": dialog text: 
" has changed in leo\n Overwrite it?"

4d) observation: regardless, the text of this dialog is confusing.

I guess there are two non-usual situations here:

A) When acquiring focus (or through periodic checks), Leo notices that the 
file on disk has been changed somehow. It asks whether I want to reload the 
new file into Leo

B) before attempting to write the file, Leo notices that there is a 
discrepancy. It asks for confirmation whether I want to overwrite the file 
on disk

I would expect (A) to be the most usual/useful case; Leo currently seems to 
try for (B)

Does that help/make sense?

thanks

Jon N







On Monday, December 7, 2020 at 7:34:55 PM UTC Edward K. Ream wrote:

> On Mon, Dec 7, 2020 at 10:53 AM jkn  wrote:
>
> > I am not very clear about the differences between #1240 and #1771.
>
> #1240  is an old 
> issue. It may have been inspired by your request, but I don't have any 
> memories. #1771  is 
> simply the corresponding pull request.
>
> There are subtle, useful, differences between the descriptions (first 
> comments) of issues and pull requests. Pull requests are oriented towards 
> diffs. The corresponding issue is focused more on the big picture. But this 
> varies according to circumstance.
>
> Does this make sense?
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6b132e3a-d9fc-41de-8fea-0b902034n%40googlegroups.com.

Re: #1772: (git-pr-diff support) is complete in devel

[Edward K. Ream]

On Thursday, December 10, 2020 at 12:03:36 PM UTC-6 Edward K. Ream wrote:

> > *Warning*:  at present the script shown [in #1772 
> ] can corrupt the 
> @button node from which it is run.
>
> I have just created #1777 
>  for this.
>

The fix has been merged into devel.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/176c70b8-410c-4c85-bdb5-508de4be231fn%40googlegroups.com.

Re: #1772: (git-pr-diff support) is complete in devel

[Edward K. Ream]

> *Warning*:  at present the script shown [in #1772 
] can corrupt the 
@button node from which it is run.

I have just created #1777 
 for this.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0d7e508f-0d5c-4cd7-8124-0c4fb98a2526n%40googlegroups.com.

Re: #1772: (git-pr-diff support) is complete in devel

[Edward K. Ream]

On Tuesday, December 8, 2020 at 3:31:10 PM UTC-6 Edward K. Ream wrote:

#1772  explains how 
> to use the new method in simple scripts. Imo, this is a great new addition 
> to Leo.


*Warning*:  at present the script shown can corrupt the @button node from 
which it is run.

I'll fix this asap.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/53f0adfc-da8a-4331-b06a-4a88168fb253n%40googlegroups.com.

Re: #1772: (git-pr-diff support) is complete in devel

[Edward K. Ream]

On Tuesday, December 8, 2020 at 3:31:10 PM UTC-6 Edward K. Ream wrote:

#1772  explains how 
> to use the new method in simple scripts. Imo, this is a great new addition 
> to Leo.
>

#1772 has just been updated. It is no longer necessary to specify the 
branch name. By defaults, diffs compare the current branch with devel.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3220d476-325e-4375-b915-ec575c4fd3d2n%40googlegroups.com.