From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024 10:34:15 +0300, Robin Haberkorn wrote:

... in the end I am trying to sell the
idea that it went into the wrong direction and we should all be using interactive TECOs nowadays. ;-)

Surely Lisp is a much more versatile and extensible language than TECO. I
just wish ELisp had continuations, but you canrCOt have everything. ;)

Those who grew up on 8-bit micros will tell you the joy of switching the machine on and be instantly at a prompt from the ROM where you can type
BASIC code -- either a line at a time for immediate execution, or
(prefixed with a line number) to be saved as part of a longer program.

There is a modern system that does this sort of thing in a slicker way, I think, than any ROM BASIC: that is a Jupyter notebook.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024 22:19:26 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

There is a modern system that does this sort of thing in a slicker
way, I think, than any ROM BASIC: that is a Jupyter notebook.

My C64's zero-to-READY. time is about three seconds. How long does it
take your machine to boot, log in, launch a browser, and load up
Jupyter? ;P

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024 14:34:56 -0800, John Ames wrote:

On Thu, 14 Nov 2024 22:19:26 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

There is a modern system that does this sort of thing in a slicker way,
I think, than any ROM BASIC: that is a Jupyter notebook.

My C64's zero-to-READY. time is about three seconds. How long does it
take your machine to boot, log in, launch a browser, and load up
Jupyter? ;P

My machine is always running. Jupyter can start in three seconds. But I donrCOt need that, either, because its overhead is so low I always leave it running.

And it supports multiple notebooks open at once.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

Surely Lisp is a much more versatile and extensible language than TECO. I just wish ELisp had continuations, but you canrCOt have everything. ;)

https://www.emacswiki.org/emacs/GuileEmacs
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024 16:23:17 -0800, Paul Rubin wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

Surely Lisp is a much more versatile and extensible language than TECO.
I just wish ELisp had continuations, but you canrCOt have everything. ;)

https://www.emacswiki.org/emacs/GuileEmacs

Oh yeah!

The sooner we get rid of dynamic binding, the happier IrCOll be. ;)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-1840825859-1731677219=:12521
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 14 Nov 2024, Lawrence D'Oliveiro wrote:

On Thu, 14 Nov 2024 10:34:15 +0300, Robin Haberkorn wrote:

... in the end I am trying to sell the
idea that it went into the wrong direction and we should all be using
interactive TECOs nowadays. ;-)

Surely Lisp is a much more versatile and extensible language than TECO. I just wish ELisp had continuations, but you can=E2=80=99t have everything.=

;)

With "interactive TECO" I don't just mean some REPL prompt, even not in=20 video mode while showing the buffer contents. I mean immediate execution=20
of source code while you type it and see the results immediately -- the=20
way it was realized in Video TECO and later by me in SciTECO.
For such an approach, you don't want a verbose language like Lisp. That=20 wouldn't work of course. You want a terse language like TECO, where the=20
most frequently used commands are just one or two letters/key presses.
Just like in the modern screen editors. They are also operating on=20
commands, very short ones, one or two key presses or short key chords. But=
=20
they don't show them to you on a command line, and their "language" is not=
=20
Turing complete.
So I thought, why not take this lovely language we have -- TECO -- and=20
turn it into the screen editor language by immediately executing it, thus=
=20
abolishing the difference between movement and editing commands and editor=
=20
scripting.

And while I had to extend the language significantly, it grew nicely.=20 Further extensions are planned, like floating point integers as a second=20 numeric data type. Lots of commands are still missing as well - most of=20
that will be adressed in the next major release, which will also move it=20
a bit closer to the DEC TECOs.
A language design problem is also that it's not straight forward to write=
=20
macros that receive string arguments, which will furthermore require to=20
turn macros into something like coroutines, at least if you want=20
immediate execution as we are used to in SciTECO. Not to mention that=20 SciTECO syntax prescribes the number of string arguments, so you will never=
be able=20
to write MqSTRING ARG$. There would have to be ugly E1qFOO$ and=20
E2qFOO$BAR$ hacks. But we might allow @Mq/FOO/ since @ gives enough hints=
=20
to the parser.
It's also problematic to *return* strings from macros.
Currently, you can push the codepoints on the stack (yes, it's stack based=
=20
and yes, it supports Unicode).
But that's cumbersome. ITS TECO used pointers. Perhaps that's a solution.=
=20
It can be made safe as well, just opaque pointers as a new data type. But=
=20
it requires a significant departure from TECO-11 and its modern clones,
which I still try to be similar to, even if not aiming for compatibility.

Best regards,
Robin

PS: I of course know why back in the 1970s nobody tried anything similar.=
=20
You do need additional memory to maintain the undo structures. By modern=20 standards very modest amounts, but considering minimal available RAM sizes=
=20
back then, probably too much.
A few years later, it was already possible as demonstrated Video TECO,=20
which ran on VMS.
--4092542851-1840825859-1731677219=:12521--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

And while I had to extend the language significantly, it grew
nicely. Further extensions are planned, like floating point integers

1. Floating point "integers"???

2. TECO is historically important and interesting, and I can sort of
understand wanting to re-implement it as a retrocomputing hack, or maybe
even use it for nerd factor or because you were used to it. But,
extending it seems pretty niche. Does SciTECO have more than one user?

The DEC TECOs were themselves very limited compared to the MIT versions
that I guess culminated in the versions underpinning ITS Emacs.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024 16:26:55 +0300, Robin Haberkorn wrote:

You want a terse language like TECO, where the
most frequently used commands are just one or two letters/key presses.
Just like in the modern screen editors.

By rCLmodern screen editorsrCY I hope you donrCOt mean the vi/vim family ... --- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024 22:13:03 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

You want a terse language like TECO, where the
most frequently used commands are just one or two letters/key
presses. Just like in the modern screen editors.

By rCLmodern screen editorsrCY I hope you donrCOt mean the vi/vim family ...

I mean, it's also true of nano.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024, Paul Rubin wrote:

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

And while I had to extend the language significantly, it grew
nicely. Further extensions are planned, like floating point integers

1. Floating point "integers"???

"Numbers" I meant. We already have integers obviously. Signed 64-bit
integers to be precise. Floats I would add separately instead of making them the
numeric base type (cf. Lua) - that would IMHO be less intrusive. The
operators would be the same on all numbers, but they will behave
differently depending on the number type (int/float) on the stack.

2. TECO is historically important and interesting, and I can sort of understand wanting to re-implement it as a retrocomputing hack, or maybe
even use it for nerd factor or because you were used to it. But,
extending it seems pretty niche. Does SciTECO have more than one user?

A handful of permanent users perhaps. Hard to know exactly.
It's not super popular obviously. I was hoping for wider adoption, at
least by the nerdier audience. Perhaps it draws more attention once I get the FreeBSD package into ports (if ever!)
Or once I produce more educational material. People do in fact complain sometimes, that there aren't any video tutorials.
I guess, it's quite a learning curve.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-1915680382-1731723078=:63587
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 15 Nov 2024, John Ames wrote:

On Fri, 15 Nov 2024 22:13:03 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

You want a terse language like TECO, where the
most frequently used commands are just one or two letters/key
presses. Just like in the modern screen editors.

By =E2=80=9Cmodern screen editors=E2=80=9D I hope you don=E2=80=99t mean=

the vi/vim family ...

I mean, it's also true of nano.

It's true of *all* modern editors. And historic ones as well. I believe=20 there were some verbose early line editors, but even ed has a terse=20
command syntax.
--4092542851-1915680382-1731723078=:63587--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sat, 16 Nov 2024 05:11:15 +0300, Robin Haberkorn wrote:

... even ed has a terse command syntax.

I donrCOt understand the point of that. Elisp is terse enough as it is,
would you really want a more cryptic version of such custom
programming as

(set-buffer tempbuf)
(insert-buffer-substring-no-properties curbuf beg end)
; Multiline search seems to be troublesome (e.g. slow, stack overflow),
; so find opening and closing tags using separate searches.
(funcall delete-between ; Get rid of commented-out sections.
(lambda () (search-forward "<!--" nil t))
(lambda () (search-forward "-->" nil nil))
)
(dolist (tag '("head" "style" "script"))
; Gobble entire content for these tags, up to and including closing tags
; (luckily they donrCOt nest).
(funcall delete-between
(lambda () (re-search-forward (concat "<" tag "\\b[^>]*>") nil t))
(lambda () (re-search-forward (concat "</" tag "\\b[^>]*>") nil nil))
)
) ; dolist
(goto-char (point-min))
(perform-replace "<[^>]+>" "" nil t nil)
(setq count (count-words (point-min) (point-max)))
(kill-buffer tempbuf)
(message (format "Words: %d" count))

That is, assuming your editor language can express such things?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-720467657-1731742401=:23622
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sat, 16 Nov 2024, Lawrence D'Oliveiro wrote:

I don=E2=80=99t understand the point of that. Elisp is terse enough as it=

is,

would you really want a more cryptic version of such custom
programming as

Elisp is a scripting language. It's not the "language" you are using to=20
edit text directly. I am considering the key presses to navigate around=20
and invoke special functions also as a language. You don't want to type=20
an S-expression like (move-to-next-line), you want something short like=20 CTRL+N.

That is, assuming your editor language can express such things?

Not 100% sure what your code does, but it looks like SciTECO could do it=20
as well. Sure, it's arguably not the easist language to maintain code in.=
=20
But doing everything in one language has its own beauty. Among other=20
things, every ad-hoc scripting on the command line can - with some=20 discipline - be turned into a macro afterwards. And that very same macro=20
can be turned into a stand-alone script when using SciTECO with --mung.
And you can use the very same language for sed-like scripts directly on=20
the UNIX command line.

To get an impression what can currently be done, have a look at my macro=20 page:
https://github.com/rhaberkorn/sciteco/wiki/Useful-Macros

Or into the lib/ subdirectory. SciTECO currently contains 5000 lines of=20
TECO code. There are code generators and even a Groff postprocessor=20
written in SciTECO. So it's already quite powerful.


--4092542851-720467657-1731742401=:23622--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sat, 16 Nov 2024 10:33:16 +0300, Robin Haberkorn wrote:

Elisp is a scripting language. It's not the "language" you are using to
edit text directly.

It is, actually. In Emacs, every key has a binding to an ELisp command. So
all you are doing when you type is invoking ELisp commands. Even keys that insert literal text are just invoking the rCLself-insert-commandrCY command. Keystrokes are just another data type in the ELisp language.

... every ad-hoc scripting on the command line can - with some
discipline - be turned into a macro afterwards.

What TECO calls a rCLmacrorCY is what other languages call a rCLsubroutinerCY or
rCLfunctionrCY. In Lisp, a rCLmacrorCY is an entirely separate concept -- which it
also has.
--- Synchronet 3.21d-Linux NewsLink 1.2