[email protected] (Kenny McCormack) writes:

In article <v3g9tp$30ko4$[email protected]>,
Lawrence D'Oliveiro <[email protected]d> wrote:

On Sat, 1 Jun 2024 19:11:43 -0000 (UTC), Spiros Bousbouras wrote:

Scripting language , not macro language.

In Emacs, there is no difference: the macro language is the scripting >>language.

I don't care about "Emacs", but there *is* a difference.

Vim has both - a macro langauge and a scripting language - and they are different things that do different things.

In fact, Vim has many different scripting languages - including a brand new one in Vim9 - that I know next to nothing about.

Interesting. I read some more about languages in vi and clones. It seems
that there is still the old "ex" style (giving commands with ":" as
prefix). This of course was very limited, so VimL or Vim script extended
this (YASL, Yet Another Scripting Language) in a more powerful, but
quite ideosyncratic way. Vim9 script tries to sanitize the language
somewhat (and includes compilation to byte code), but in the meantime
Neovim was forked, which includes Lua as extension language.

(Please excuse if this brief and cursory summary is way off, it was
written by an outsider with feet firmly planted in Emacs country. Feel
free to correct/comment.)

From my Emacs point of view, this all seems quite familiar. Emacs had
very early a very capable Lisp (which was a much more common language
back then) dialect for extension, which spawned tons of packages, to the
point that package managers and package repository servers were
necessary.

So no need to reinvent the editor wheel if you are unhappy, just extend
Emacs. I assume that this very early powerful extensibility caused Emacs
fans to go wild with configuration, while the more mundane extensibility
caused vi fans to stay more vanilla (sane?). This might apply to
veterans more than to newbies who came to scene later, when Vimscripting
was already firmly established. The posts of Anthony and Janis at least
point into this direction.

Years later, when even Emacs Lisp was perceived as too limiting by some hackers, discussion about replacing Emacs Lisp by something even more
capable (Scheme, in form of the Guile dialect, or Common Lisp). This has
led to some new branches/rewrites/dead ends.

Now the "Eastern Orthodox Editors" I referred to else-thread were
extended using Rexx, also a quite fully-fledged language, and, back in
the days, rather common on OS/2 and Amiga. This choice, however, even
though there seem to be quite a lot of programmed extensions, obviously
has not prevented a slow dying of these editors, maybe because the
critical mass was too small from the start.

In my professional context (simulation of structural mechanics) the
situation is similar: There were tools with proprietary extension
languages (typically rather crippled) and others with more common/powerful/generic ones (Lisp, Tcl, Python). The former tools over
the decades have often changed to these "better" languages as well.

From a business point of view, users who invested heavily in customizing/extending a tool (because it is easy with a well-chosen
language) will not run to other tools as easily. This can ensure
live-long loyalty.

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 02 Jun 2024 07:42:09 +0200, Axel Reichert wrote:

Emacs had very early a very capable Lisp ...

Fun fact: the very earliest versions of Emacs predated Lisp. They were
built on a different language--TECO. If you thought Lisp syntax was weird,
TECO was even weirder.

Now the "Eastern Orthodox Editors" I referred to else-thread were
extended using Rexx, also a quite fully-fledged language, and, back in
the days, rather common on OS/2 and Amiga.

Didn’t have proper regular expressions, though.

In my professional context (simulation of structural mechanics) the
situation is similar: There were tools with proprietary extension
languages (typically rather crippled) and others with more common/powerful/generic ones (Lisp, Tcl, Python). The former tools over
the decades have often changed to these "better" languages as well.

Moral: proprietary tools tend to be a dead end, while open-source ones are
more future-proof.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02.06.2024 07:42, Axel Reichert wrote:

Interesting. I read some more about languages in vi and clones. It seems
that there is still the old "ex" style (giving commands with ":" as
prefix). This of course was very limited, [...]

Don't understate the 'ex' editor (or 'ex'-mode in Vi). You can do
powerful things out of the box that you cannot do in normal mode!

Here's a sample from a lecture I once gave (just to illustrate)[*]

:/^Start$/,$g/^# Key//Control-Key/s/Hello/Hello World/

The point of the example was editing in certain sectors and change
text only in specific text contexts across lines and sections, and
leaving other appearances untouched.

Janis

[*] Yes, it appears cryptic, but it's composed of building blocks,
and if you've learned the three concepts used in the sample it's
simply constructed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <[email protected]> writes:

:/^Start$/,$g/^# Key//Control-Key/s/Hello/Hello World/

A little sed/awk knowledge helps. But that is the group next door. (-:

Sure, ex is the line-editing version of vi, and I have used it
occasionally, but only when forced to, because, say, the terminal was
screwed up.

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 3 Jun 2024 23:18:35 +0200, Janis Papanagnou wrote:

On 03.06.2024 21:45, Axel Reichert wrote:

A little sed/awk knowledge helps. But that is the group next door.
(-:

An Awk solution of this 'ex' one-liner would be quite bulky.

Whenever somebody mentions “Awk”, I immediately think “Perl does everything that Awk does, just as concisely, and more besides”.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03.06.2024 21:45, Axel Reichert wrote:

Janis Papanagnou <[email protected]> writes:

:/^Start$/,$g/^# Key//Control-Key/s/Hello/Hello World/

A little sed/awk knowledge helps. But that is the group next door. (-:

An Awk solution of this 'ex' one-liner would be quite bulky.
Feel free to try that out. :-)

Also interested in provision of a 'sed' version. (Just for
comparison.)

Sure, ex is the line-editing version of vi, [...]

It's two individual (but interconnected) modes of the editor,
but their command capabilities are quite different (as can
be seen with this example).

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04.06.2024 00:07, Lawrence D'Oliveiro wrote:

On Mon, 3 Jun 2024 23:18:35 +0200, Janis Papanagnou wrote:

On 03.06.2024 21:45, Axel Reichert wrote:

A little sed/awk knowledge helps. But that is the group next door.
(-:

An Awk solution of this 'ex' one-liner would be quite bulky.

Whenever somebody mentions “Awk”, I immediately think “Perl does everything that Awk does, just as concisely, and more besides”.

While I have a clear idea how it would look in Awk I cannot say
anything about how it would look in Perl. (I suppose the "Perl
is a functional superset of Awk" wouldn't imply that the bulky
Awk code [for the 'ex'-sample] would be more terse in Perl?)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/02/2024 02:01 AM, Lawrence D'Oliveiro wrote:

On Sun, 02 Jun 2024 07:42:09 +0200, Axel Reichert wrote:

Emacs had very early a very capable Lisp ...

Fun fact: the very earliest versions of Emacs predated Lisp. They were
built on a different language--TECO. If you thought Lisp syntax was weird, TECO was even weirder.
[SNIP]

Down memory lane ;}
I ran into TECO as an engineering tech at DEC in the 70's. Though an
analog hardware person, I was engulfed by computer nuts. A web search
turned up https://almy.us/teco.html which links to versions of TECO for
Linux and other current systems. May recreationally investigate later.

In a more practical vein, later in this thread awk is discussed. Sounded vaguely familiar. Found that Gawk is installed on my Debian system.

Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an appropriate tool for a personal project [removing featuritis of a large
set of HTML files].

Its been so long since I last used awk, I'll effectively be starting
from scratch. Can anyone recommend a suitable tutorial?
[many many hits on a web search ;]

TIA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04.06.2024 13:43, Richard Owlett wrote:

In a more practical vein, later in this thread awk is discussed. Sounded vaguely familiar. Found that Gawk is installed on my Debian system.

Yes, POSIX standard asks for availability of Awk; you find it
on any standard Unix.

GNU Awk is a quality tool.

Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an appropriate tool for a personal project [removing featuritis of a large
set of HTML files].

Its been so long since I last used awk, I'll effectively be starting
from scratch. Can anyone recommend a suitable tutorial?

The book you mentioned above doesn't suit you?

[many many hits on a web search ;]

I have bad experience with Web tutorials and their quality. :-/

Personally I got the first edition of the original book on The
Awk Programming Language, from Weinberger, Kernighan, and Aho
(from around 1988, I think). Meanwhile there's a recent 2nd ed.
It is well written (but quite expensive). The 200 page 1st ed.
had a 20 pages tutorial and a 45 pages language description,
which had been all I needed.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou wrote:

Don't understate the 'ex' editor (or 'ex'-mode in Vi). You can do
powerful things out of the box that you cannot do in normal mode!

Indeed, and if you combine the two you can do some amazing things.

I wrote some vi macros in 1991 for manipulating rectangular blocks.
They relied heavily on a technique whereby an ex command is
constructed on the fly using normal commands and then deleted into
a buffer and the buffer is executed. (I know vim has a built-in
feature to do this, but I wrote the macros a couple of years before
vim was ported to UNIX.)

Here's the "block delete" macro which deletes a rectangular block
from marked position `a as top left to `b as bottom right (ESC
represents an escape character):

map *d =*I:'a,'bs/ESCA\(.*\)/\1\3/ESC"xdd@x

It uses this =* helper macro (which also uses the same technique)
to create a "line divider" of the form \(...\)\(...\) :

map =* `a=.xI:s/^ESCA/\\(&\\)\\(/ESC"xdd`b=.@xA\)ESC

and this in turn uses an =. helper macro to create a line of "."s of
length equal to the current column position (^M is a RETURN character):

map =. mx:t.^M`xjaxESCD:s/././g

The "block copy" macro is even more complicated. It constructs a set
of ex commands to be applied, one per line, to a set of target lines,
and executes them using a single ex command of this form ('y marks the
line to which the next command should be applied):

:{range}g/^/d x|'y@x|'y+ma y

The full set of macros, along with many other sets of amazing vi macros,
were in the "comp.editors VI Archives" which can probably still be found
at one or more of the sites listed at

http://www.faqs.org/faqs/editor-faq/VI-Archive-filelist/

--
Geoff Clare <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Geoff Clare <[email protected]d> writes:

Here's the "block delete" macro which deletes a rectangular block
from marked position `a as top left to `b as bottom right

Cool!

But I understand that this was not available out of the box in vi? I am
very sure that vim can do all this (very handy!) rectangular magic, as
can Emacs. I cannot say since when for the latter.

Many advanced features start out as a keyboard macro, which then can be
cast into the extension language of choice. For Emacs, there is even a
package which translates a keyboard macro into the equivalent Lisp
code. After all (as in vi), the keystrokes are just bound to some
low-level function call.

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04.06.2024 18:17, Axel Reichert wrote:

Geoff Clare <[email protected]d> writes:

Here's the "block delete" macro which deletes a rectangular block
from marked position `a as top left to `b as bottom right

Cool!

But I understand that this was not available out of the box in vi? I am
very sure that vim can do all this (very handy!) rectangular magic, as
can Emacs. I cannot say since when for the latter.

Yes, Vim supports visual modes where you can with Ctrl-V start spanning
a rectangular area, then typing the operator (for delete, copy, etc.).

(I think Geoff was just trying to show the possibilities of 'ex' and Vi
in general and how the modes cooperate.)

It's nonetheless an interesting sample how he uses the markers `a etc.

Many advanced features start out as a keyboard macro, which then can be
cast into the extension language of choice. For Emacs, there is even a package which translates a keyboard macro into the equivalent Lisp
code. After all (as in vi), the keystrokes are just bound to some
low-level function call.

I have a different feeling how to accurately describe how Vi operates.
Consider a command like "A 5 d 2 f* (I inserted spurious spaces just
for an easier detection of the parts). As "low-level function" we can
consider just the operator 'd' (delete). This is more like a language
[buffer] [count] {operator} [movement] with 'movement' being another
language entity like, say, [count] {move}. It's not that any keystroke
will trigger a low-level function (move or edit) as you see in other
editor designs. The example I showed activates buffer A for appending
the text that gets to be deleted, from the current cursor position up
to the target of the movement, which here is the second '*' found on
the rest of the line. This orthogonality with building-blocks is an
essential constituent of the power of Vi editing.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04.06.2024 19:31, Spiros Bousbouras wrote:

On Tue, 4 Jun 2024 19:06:55 +0200
Janis Papanagnou <[email protected]> wrote:

[... about "A ...]

Register a , not buffer A .

Yes, "register" not "buffer". - Thanks!

Note that :registers shows them in low case letters.

Yes, they can only use one representation for the register name
since "a and "A respectively identify the _same_ register,
there's only a functional difference that using the lower case
letters will set the respective register while using the upper
case letter will append to that register.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04.06.2024 20:28, Janis Papanagnou wrote:

On 04.06.2024 19:31, Spiros Bousbouras wrote:

On Tue, 4 Jun 2024 19:06:55 +0200
Janis Papanagnou <[email protected]> wrote:

[... about "A ...]

Register a , not buffer A .

Yes, "register" not "buffer". - Thanks!

Sorry, audience! I got confused Spiros' post. - Despite Vim's
'registers' command it's officially called "buffer".[*]

The term "register" isn't mentioned at all in the POSIX document.

And don't confuse the term "buffer" with the term "edit buffer".
(POSIX differentiates these.)

In my Vi/Vim lecture document I used (coined?) the term "paste-
buffer" to better differentiate it from "buffer" or "edit buffer".

Janis

[*] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 4 Jun 2024 06:43:11 -0500, Richard Owlett wrote:

Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an appropriate tool for a personal project [removing featuritis of a large
set of HTML files].

I wouldn’t bother. Having spent some time learning Perl, I would say Perl does everything Awk/Gawk can do, just as concisely, and it can do more
besides.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 4 Jun 2024 17:31:29 -0000 (UTC), Spiros Bousbouras wrote:

Register a , not buffer A .

Interesting that Emacs also uses the term “register”. Here the term actually came from TECO, where they were called “Q-registers” because they were accessed with the “Q” command. There were 26 of them, and each one held an integer and a string. Notice that this matches the Emacs concept,
too.

Does vi/vim also derive its terminology from the same source, I wonder?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05.06.2024 01:19, Lawrence D'Oliveiro wrote:

On Tue, 4 Jun 2024 06:43:11 -0500, Richard Owlett wrote:

Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an
appropriate tool for a personal project [removing featuritis of a large
set of HTML files].

I wouldn’t bother. Having spent some time learning Perl, I would say Perl does everything Awk/Gawk can do, just as concisely, and it can do more besides.

Yes, "it can do more"; but this is not necessarily a determining
argument for Richard (or for other folks new to Awk or Perl).

If all he wants to do is text processing why learn a tool (Perl)
that
* has a much more cryptic syntax
* is much more complex[*]
* requires a lot more time learning[**]
* is non-standard (may not be available on POSIX systems)[***]

It's certainly good to know a text processing tool like Awk.

Janis

[*] Richard already identified Awk to be the "appropriate tool",
so obviously no need for additional complexity or more features.

[**] Richard also said he already used Awk in the past, which is
an additional time saver beyond the inherent huge effort to learn
a large tool like Perl.

[***] Richard works on his his own Debian, so being non-standard
is no problem. But for people on standard POSIX systems it may be.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05.06.2024 01:18, Lawrence D'Oliveiro wrote:

On Tue, 4 Jun 2024 17:31:29 -0000 (UTC), Spiros Bousbouras wrote:

Register a , not buffer A .

Interesting that Emacs also uses the term “register”. Here the term actually came from TECO, where they were called “Q-registers” because they
were accessed with the “Q” command. There were 26 of them, and each one held an integer and a string. Notice that this matches the Emacs concept, too.

Does vi/vim also derive its terminology from the same source, I wonder?

Can't tell for [origin of] Vim terminology. But for Vi, as already
said, the official (POSIX) terminology is "buffer" (not "register").
It's likely, though, that Bram has chosen Vim terminology from some
existing source since the official term "buffer" may be confusing.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/05/2024 03:54 AM, Janis Papanagnou wrote:

On 05.06.2024 01:19, Lawrence D'Oliveiro wrote:

On Tue, 4 Jun 2024 06:43:11 -0500, Richard Owlett wrote:

Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an
appropriate tool for a personal project [removing featuritis of a large
set of HTML files].

I wouldn’t bother. Having spent some time learning Perl, I would say Perl >> does everything Awk/Gawk can do, just as concisely, and it can do more
besides.

Yes, "it can do more"; but this is not necessarily a determining
argument for Richard (or for other folks new to Awk or Perl).

If all he wants to do is text processing why learn a tool (Perl)
that
* has a much more cryptic syntax
* is much more complex[*]
* requires a lot more time learning[**]
* is non-standard (may not be available on POSIX systems)[***]

It's certainly good to know a text processing tool like Awk.

Janis

[*] Richard already identified Awk to be the "appropriate tool",
so obviously no need for additional complexity or more features.

Referring to my post earlier this this morning, Awk is demoted to
a "possible tool" ;/ Suspect I was conflating features of Awk and TECO.

Currently investigating sed. I don't recall having used sed but have
used something "sed-like".

[**] Richard also said he already used Awk in the past, which is
an additional time saver beyond the inherent huge effort to learn
a large tool like Perl.

[***] Richard works on his his own Debian, so being non-standard
is no problem. But for people on standard POSIX systems it may be.

Debian is less restrictive than M$.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/04/2024 07:53 AM, Janis Papanagnou wrote:

On 04.06.2024 13:43, Richard Owlett wrote:

In a more practical vein, later in this thread awk is discussed. Sounded
vaguely familiar. Found that Gawk is installed on my Debian system.

Yes, POSIX standard asks for availability of Awk; you find it
on any standard Unix.

GNU Awk is a quality tool.

Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an
appropriate tool for a personal project [removing featuritis of a large
set of HTML files].

Its been so long since I last used awk, I'll effectively be starting
from scratch. Can anyone recommend a suitable tutorial?

The book you mentioned above doesn't suit you?

In a way it's too much of a good thing.
Its goal is to be an exhaustive reference for Gawk.
[note terms used: "exhaustive" AND "reference"]
I was looking for something to give "the lay of the land".

[many many hits on a web search ;]

I have bad experience with Web tutorials and their quality. :-/

*ROFL*!!!
Been there done that ... ;}
That's why I looked for guidance.
For perspective:
1. I had contact with TECO because of my analog hardware experience.
2. I was entering construction management when the 8086 was popular.
3. I was no longer in a computer environment when i486 PCs arrived.

Personally I got the first edition of the original book on The
Awk Programming Language, from Weinberger, Kernighan, and Aho
(from around 1988, I think). Meanwhile there's a recent 2nd ed.
It is well written (but quite expensive). The 200 page 1st ed.
had a 20 pages tutorial and a 45 pages language description,
which had been all I needed.

Janis

In my search for a suitable tool I started reading about sed.
Debian manpages on awk and sed are illuminating:
1. awk - pattern-directed scanning and processing language [1]
2. sed - stream editor for filtering and transforming text [2]

The featuritis laden HTML files are chapters of the KJV Bible.
My goal is a pleasant reading experience a set of Senior Citizens with
mild vision impairment [including myself]. As "everyone" has a browser,
HTML is a logical choice. By avoiding JavaScript/CSS/etc and using only
about a half-dozen tags, compatibility issues are all but eliminated.

There are many _study_ oriented tools available.
I didn't find something that met all my idiosyncratic preferences.
Rolling my own allows me to:
1. learn HTML by doing.
2. have a pleasant reading reading experience.
3. create something useful to others.

[ https://ebible.org/Scriptures/eng-kjv2006_html.zip as starting point]







[1] https://manpages.debian.org/bookworm/9base/awk.1plan9.en.html
[2] https://manpages.debian.org/bookworm/sed/sed.1.en.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05.06.2024 23:31, Spiros Bousbouras wrote:

On Tue, 4 Jun 2024 21:00:09 +0200
Janis Papanagnou <[email protected]> wrote:

The term "register" isn't mentioned at all in the POSIX document.

Interesting. I wonder which vi clones call it "buffer" and which
"register". There may even exist more terminologies for all I know.

Personally I think that both terms are no good choice; in my ears they
appear like a low-level and _too generic_ technical term. That's why:

In my Vi/Vim lecture document I used (coined?) the term "paste-
buffer" to better differentiate it from "buffer" or "edit buffer".

Also; generally I consider a "register" (in IT context) a small entity
and "buffer" as something large (certainly larger than a "register").
And the "paste buffer" ("register", "buffer") in Vi/Vim can hold very
large entities, so some sort of "buffer" fits better (IMO).

I used the "paste" prefix to remove the unfortunate genericity of the
term (as POSIX used the "edit" prefix for the edit buffer).

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)