@vnikolov @dougmerritt @screwlisp @oantolin @northernlights @chiply @nosrednayduj

For all its Spartan nature, a Turing machine can test things. TECO has the ability to test. It left a lot of that behind in becoming real time. Instead, for the most part, judgment has been outsourced to the human user. I don't mean to say that there's nothing available, because probably there is. And Turing machines have a way of showing themselves even when the capability is obscure, as at least a theoretical matter. But that's also one reason that Turing machines are not a very good metric.

Maybe something has been done since the time when I use them a lot, but I was surprised at how little support there was for programming in keyboard macros back in the TECO days. The ability was there to do control-x q, which inserts a yes/no query about whether to do the remaining part of the macro. That's extremely important if you're going to iterate the macro because then you can build something like query replace.

I remember making several other suggestions, some of which I implemented and some of which I don't know that were ever implemented.

I wanted to control-x q to be something that allowed me to respond with other than just space, as I recall. Instead with control-r, giving me a recorded excursion into the buffer at this particular point to do an alternate ending to the plot for that iteration. Then it could pop up a menu the next time, or perhaps just use space again but allow me to type m for menu to see the menu that I knew was there because I interactively wrote another option. Then I could iteratively learn a variety of situations as I was making a big code change by hand.

But this is a place where Omar's embark stuff might be interesting. Because it might be able to infer something from where it landed and there might be a way instead of saying control-x q to inject an embark operation, whether one that did prompting, or a dwim one.

In the long ago days, it might have been impractical to save these things across sessions, but an option variable could allow all such macros to be saved in a history, and that history to be reviewed, edited and named, so that later on one didn't have to reteach the same things.

I had an extension on control-x # that would keyboard macro insert a number with a default value probably of one, I could look it up. But the important thing is that you could give it an argument of what the default value was and on the first iteration of the keyboard macro it would use that and on subsequent interations it would bump the value by one. And then you could write something that created a numeric version of a bullet list.

But you could write something that allowed you to say, while defining the keyboard macro, let me mark a region, and then that prompted you for some way of saying whether it was what you wanted. Perhaps you could say it was a certain type that would be useful to embark. Perhaps you could say it was a regular expression that controlled whether to do the rest of the macro or chose which of several branches you had created in the macro. To do the latter you would have to know that the branches were there, so the test would have to be injected in response to the query about whether to do it.

If you were doing it a definition time initially, you would probably want it to prompt you for one branch, and then restore the state back to that branch and prompt you for the other branch and then restore the state back to that and ask you if you were done. Each pattern except for the last would need to match whatever it's associated test was. And if there was more than one branch, you need to present a menu saying which one do you want to do in this case. A variation on this would be to insist that there was only a matching pattern and a non-matching pattern and then that could be executed automatically without a menu.

That last part about prompting for patterns is something I'm just thinking of now, not something I had thought about at the time, but it's in the context of this discussion about editors being Turing machines. They need to be able to ask questions in other words.

Just having the ability to count the number of times you've entered a certain branch seems useful, so you could have a command that counted silently and a companion that retrieved that number into the buffer, or did a test on that. If the place that that number wanted to be stored had a name of some sort, you could have an array of other kinds of names of such things, and things that did various kinds of tests on what was in that storage, like what happens in bash with its various tests. At that point you would have a pretty rich set of testing capabilities and then the rest of this conversation above would make more sense to me.

Of course if you're only talking teco, it was able to substantially, though not completely, introspect and redefine the great deal of itself because such capability was built in.