On 2021-11-08, Dave Froble <davef@tsoft-inc.com> wrote:
> On 11/8/2021 1:25 PM, Simon Clubley wrote:
>> On 2021-11-08, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>>> In article <b6c4a416-0ccf-4518-b5fa-039d8d23f88cn@googlegroups.com>,
>>> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:
>>>
>>>> On Monday, November 8, 2021 at 6:27:48 PM UTC+13, Phillip Helbig (undress to reply) wrote:
>>>>> It is the most efficient, not the most powerful. :-)
>>>>
>>>> As in helping you to be the most productive?
>>>
>>> Exactly.
>>>
>>
>> How exactly ?
>>
>> By today's standards, EDT's limited functionality makes it the
>> assembly language version of editors when compared to other editors
>> which are fully featured editors.
>>
>> EDT can't even show more than one window on the screen at the same
>> time. How does that make EDT the most productive editor ?
>>
>> Even EVE can do that, which makes even EVE much more productive than EDT.
>>
>> Simon.
>>
>
> If it is all I need and use ....
>
> Which part of that was not understood?
>

The bit you missed above where Phillip claims EDT is the most productive
editor, even in the face of all the much more powerful alternatives. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-11-09, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>
> Even on really fast hardware, I am always annoyed with how slow the
> cursor movement is with EVE. And then it reads in the whole huge file
> even if I just want to edit the first few lines.
>

I don't notice any slow cursor movement with EVE.

With large files, you are talking about something that might have been
a problem in the era of MicroVax II machines but it simply isn't a
problem these days. EVE is also one hell of a lot more efficient at
handling large files overall anyway because it doesn't need an EDT-style
workfile.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/9/21 1:38 PM, Dave Froble wrote:
> On 11/9/2021 10:57 AM, Bill Gunshannon wrote:
>> On 11/9/21 10:21 AM, Arne Vajhøj wrote:
>>> On 11/9/2021 9:57 AM, VAXman-@SendSpamHere.ORG wrote:
>>>> In article <smbq3b$o9$1@dont-email.me>, Simon Clubley
>>>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>> On 2021-11-08, Phillip Helbig (undress to reply)
>>>>> <helbig@asclothestro.multivax.de> wrote:
>>>>>> In article <b6c4a416-0ccf-4518-b5fa-039d8d23f88cn@googlegroups.com>,
>>>>>> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com>
>>>>>> writes:
>>>>>>> On Monday, November 8, 2021 at 6:27:48 PM UTC+13, Phillip Helbig
>>>>>>> (undress to reply) wrote:
>>>>>>>> It is the most efficient, not the most powerful. :-)
>>>>>>>
>>>>>>> As in helping you to be the most productive?
>>>>>>
>>>>>> Exactly.
>>>>>
>>>>> How exactly ?
>>>>>
>>>>> By today's standards, EDT's limited functionality makes it the
>>>>> assembly language version of editors when compared to other editors
>>>>> which are fully featured editors.
>>>>
>>>> Where is the list of *today's standards* for editors?
>>>
>>> "today's standard" does not imply a formal (ANSI/ISO) standard just
>>> some relative vague general expectations.
>>
>> It's called "de facto" and it has been around a lot longer than
>> "today".
>
> Is your "de facto" the same as my "de facto"?  I bet not.
>

Probably not, but we don't get to set it anyway, the industryh
does. :-)

Personally, my favorite editor depends entirely on what system
I am working on. On RSTS it's EDT. On Unix it's vi. And, on
any system that supports it, MicroEMACS. VMS I would have to say
LSE.

bill

On 11/9/2021 1:37 PM, Dave Froble wrote:
> On 11/9/2021 10:21 AM, Arne Vajhøj wrote:
>> What is the general expectations from an editor today?
>>
>> I would say:
>> - GUI
>> - standard menus with at least File, Edit and Help in the menu bar
>> - at least Open, Save, Save As and Exit in the File menu
>> - at least Copy, Cut, Paste, Search and Replace in the Edit menu
>> - common shortcuts CTRL/A, CTRL/C, CTRL/X and CTRL/V
>> - ability to mark blocks with mouse
>> - certain edit function available via right click
>> - ability to have multiple files open
>> - ability to show multiple buffers simultaneously
>> - some language specific color highlighting
>> - some smart indenting
>
> In other words, WEENDOZE ...

There are a lot of editors available on Windows that provide that.

But it is not specific for Windows. Linux editors will be the same.
I suspect that macOS editors will be the same. Heck even VMS GUI editors
will behave somewhat like this.

> Perhaps my usage is too focused.  When I think of text editor, I think of
> working on programs.  Basic, Macro-32, and (hawk, spit, gag) C.  Maybe
> some DCL.
>
> I'm sure there can be other uses and my focus is too narrow.  But for
> what I
> use EDT on VMS, it is what I listed above.  Others may have different
> needs.

The above is what most will use for light code editing.

For heavy code editing most will switch to a full blown IDE and
add features like:
- integration with source control
- integration with build system
- integration with debugger
- integration with help for programming language and RTL
- refactoring support
- suggestions as you write

But unless one work for a company with strict tool policies then one can
always pick the tool that one prefer.

If you like EDT then you just use EDT.

Arne

On 11/9/2021 2:08 PM, Bill Gunshannon wrote:
> On 11/9/21 1:38 PM, Dave Froble wrote:
>> On 11/9/2021 10:57 AM, Bill Gunshannon wrote:
>>> On 11/9/21 10:21 AM, Arne Vajhøj wrote:
>>>> On 11/9/2021 9:57 AM, VAXman-@SendSpamHere.ORG wrote:
>>>>> In article <smbq3b$o9$1@dont-email.me>, Simon Clubley
>>>>>> By today's standards, EDT's limited functionality makes it the
>>>>>> assembly language version of editors when compared to other editors
>>>>>> which are fully featured editors.
>>>>>
>>>>> Where is the list of *today's standards* for editors?
>>>>
>>>> "today's standard" does not imply a formal (ANSI/ISO) standard just
>>>> some relative vague general expectations.
>>>
>>> It's called "de facto" and it has been around a lot longer than
>>> "today".
>>
>> Is your "de facto" the same as my "de facto"?  I bet not.
>>
>
> Probably not, but we don't get to set it anyway, the industryh
> does.  :-)
>
> Personally, my favorite editor depends entirely on what system
> I am working on.  On RSTS it's EDT.  On Unix it's vi.  And, on
> any system that supports it, MicroEMACS. VMS I would have to say
> LSE.

It is worth nothing that it is increasingly common that code
get actual written on a different platform than destination
platform.

Arne

On 2021-11-09, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <smbq3b$o9$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>On 2021-11-08, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>>> In article <b6c4a416-0ccf-4518-b5fa-039d8d23f88cn@googlegroups.com>,
>>>=?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:
>>>
>>>> On Monday, November 8, 2021 at 6:27:48 PM UTC+13, Phillip Helbig (undress to reply) wrote:
>>>> > It is the most efficient, not the most powerful. :-)
>>>>
>>>> As in helping you to be the most productive?
>>>
>>> Exactly.
>>>
>>
>>How exactly ?
>>
>>By today's standards, EDT's limited functionality makes it the
>>assembly language version of editors when compared to other editors
>>which are fully featured editors.
>
> Where is the list of *today's standards* for editors?
>

Some examples are:

Multiple buffers showing in multiple windows on the screen.

A programming language for the editor so you can write extensions
and add additional functionality in general.

Brace and bracket matching.

Lots of editing utility and other built-in functions.

Language modes for those who use them (I don't, except in special cases).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/9/21 2:17 PM, Arne Vajhøj wrote:
> On 11/9/2021 2:08 PM, Bill Gunshannon wrote:
>> On 11/9/21 1:38 PM, Dave Froble wrote:
>>> On 11/9/2021 10:57 AM, Bill Gunshannon wrote:
>>>> On 11/9/21 10:21 AM, Arne Vajhøj wrote:
>>>>> On 11/9/2021 9:57 AM, VAXman-@SendSpamHere.ORG wrote:
>>>>>> In article <smbq3b$o9$1@dont-email.me>, Simon Clubley
>>>>>>> By today's standards, EDT's limited functionality makes it the
>>>>>>> assembly language version of editors when compared to other editors
>>>>>>> which are fully featured editors.
>>>>>>
>>>>>> Where is the list of *today's standards* for editors?
>>>>>
>>>>> "today's standard" does not imply a formal (ANSI/ISO) standard just
>>>>> some relative vague general expectations.
>>>>
>>>> It's called "de facto" and it has been around a lot longer than
>>>> "today".
>>>
>>> Is your "de facto" the same as my "de facto"?  I bet not.
>>>
>>
>> Probably not, but we don't get to set it anyway, the industryh
>> does.  :-)
>>
>> Personally, my favorite editor depends entirely on what system
>> I am working on.  On RSTS it's EDT.  On Unix it's vi.  And, on
>> any system that supports it, MicroEMACS. VMS I would have to say
>> LSE.
>
> It is worth nothing that it is increasingly common that code
> get actual written on a different platform than destination
> platform.
>

I've done that for decades. Especially with machines with really
poor editors. Like OS9 and TRSDOS. :-)

bill

On 11/9/21 8:08 PM, Bill Gunshannon wrote:
> Personally, my favorite editor depends entirely on what system
> I am working on.  On RSTS it's EDT.  On Unix it's vi.  And, on
> any system that supports it, MicroEMACS. VMS I would have to say
> LSE.

Which version of MicroEMACS? It is available for VMS. It was the first
editor running on VMS/Alpha and x86.

On 11/9/21 3:00 PM, hb wrote:
> On 11/9/21 8:08 PM, Bill Gunshannon wrote:
>> Personally, my favorite editor depends entirely on what system
>> I am working on.  On RSTS it's EDT.  On Unix it's vi.  And, on
>> any system that supports it, MicroEMACS. VMS I would have to say
>> LSE.
>
> Which version of MicroEMACS?

Different versions on different machines. Been a long time and I really
don't remember version numbers anyway.

> It is available for VMS. It was the first
> editor running on VMS/Alpha and x86.
>

I'm sure it was but VMS had suitable editors at the time I was using it.
I do find it hard to believe it was the first editor on VMS/Alpha. No
EDT?

And, anyway, real emacs has been available on VMS pretty much from the
beginning.

bill

On 11/9/2021 3:09 PM, Bill Gunshannon wrote:
> On 11/9/21 3:00 PM, hb wrote:
>> On 11/9/21 8:08 PM, Bill Gunshannon wrote:
>>> Personally, my favorite editor depends entirely on what system
>>> I am working on.  On RSTS it's EDT.  On Unix it's vi.  And, on
>>> any system that supports it, MicroEMACS. VMS I would have to say
>>> LSE.
>>
>> Which version of MicroEMACS?
>
> Different versions on different machines. Been a long time and I really
> don't remember version numbers anyway.
>
>>                              It is available for VMS. It was the first
>> editor running on VMS/Alpha and x86.
>>
>
> I'm sure it was but VMS had suitable editors at the time I was using it.
> I do find it hard to believe it was the first editor on VMS/Alpha.  No
> EDT?

If Hartmut states it, it's almost certainly correct; he doesn't make
unsubstantiated claims.

--

-- Rob

On Tuesday, November 9, 2021 at 3:09:55 PM UTC-5, Bill Gunshannon wrote:
> I'm sure it was but VMS had suitable editors at the time I was using it.
> I do find it hard to believe it was the first editor on VMS/Alpha. No
> EDT?

Did the RSX EDT image run under AME?

On Wednesday, November 10, 2021 at 8:22:47 AM UTC+13, Simon Clubley wrote:
> Brace and bracket matching.

What about indentation matching?

I write a lot of Python code, and as you may know, that eschews statement brackets in favour of using indentation to indicate nesting level. So while commands for jumping between matching bracketing symbols are still useful within expressions, they are less so for navigating around compound statements.

Any editor you know of that has built-in commands for easing that? Even Emacs didn’t (that I know of), so I had to define my own.

On Wednesday, November 10, 2021 at 7:37:16 AM UTC+13, Dave Froble wrote:
> In other words, WEENDOZE ...

Interesting to note that, since most business-based apps run in the cloud these days, and the cloud is predominantly Linux, that is where the developers are going, too. This is why Microsoft introduced WSL (Linux-on-Windows, either emulated -- WSL 1.0 -- or genuine Linux -- WSL 2.0), to try to stem the flow of desertions.

In article <smeeme$5mg$1@dont-email.me>, Dave Froble <davef@tsoft-inc.com> writes:
>On 11/9/2021 9:57 AM, VAXman-@SendSpamHere.ORG wrote:
>> In article <smbq3b$o9$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> On 2021-11-08, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>>>> In article <b6c4a416-0ccf-4518-b5fa-039d8d23f88cn@googlegroups.com>,
>>>> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:
>>>>
>>>>> On Monday, November 8, 2021 at 6:27:48 PM UTC+13, Phillip Helbig (undress to reply) wrote:
>>>>>> It is the most efficient, not the most powerful. :-)
>>>>>
>>>>> As in helping you to be the most productive?
>>>>
>>>> Exactly.
>>>>
>>>
>>> How exactly ?
>>>
>>> By today's standards, EDT's limited functionality makes it the
>>> assembly language version of editors when compared to other editors
>>> which are fully featured editors.
>>
>> Where is the list of *today's standards* for editors?
>>
>
>Now Brian, you know that a standard is what Simon says it is ...

I don't play Simon Says at my age.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

In article <smef4p$9u8$1@dont-email.me>, Dave Froble <davef@tsoft-inc.com> writes:
>On 11/9/2021 10:21 AM, Arne Vajhøj wrote:
>> On 11/9/2021 9:57 AM, VAXman-@SendSpamHere.ORG wrote:
>>> In article <smbq3b$o9$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>> On 2021-11-08, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>>>>> In article <b6c4a416-0ccf-4518-b5fa-039d8d23f88cn@googlegroups.com>,
>>>>> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:
>>>>>> On Monday, November 8, 2021 at 6:27:48 PM UTC+13, Phillip Helbig (undress to reply) wrote:
>>>>>>> It is the most efficient, not the most powerful. :-)
>>>>>>
>>>>>> As in helping you to be the most productive?
>>>>>
>>>>> Exactly.
>>>>
>>>> How exactly ?
>>>>
>>>> By today's standards, EDT's limited functionality makes it the
>>>> assembly language version of editors when compared to other editors
>>>> which are fully featured editors.
>>>
>>> Where is the list of *today's standards* for editors?
>>
>> "today's standard" does not imply a formal (ANSI/ISO) standard just
>> some relative vague general expectations.
>>
>> What is the general expectations from an editor today?
>>
>> I would say:
>> - GUI
>> - standard menus with at least File, Edit and Help in the menu bar
>> - at least Open, Save, Save As and Exit in the File menu
>> - at least Copy, Cut, Paste, Search and Replace in the Edit menu
>> - common shortcuts CTRL/A, CTRL/C, CTRL/X and CTRL/V
>> - ability to mark blocks with mouse
>> - certain edit function available via right click
>> - ability to have multiple files open
>> - ability to show multiple buffers simultaneously
>> - some language specific color highlighting
>> - some smart indenting
>
>In other words, WEENDOZE ...

Gack, I just vomited a bit into my mouth.

>Perhaps my usage is too focused. When I think of text editor, I think of
>working on programs. Basic, Macro-32, and (hawk, spit, gag) C. Maybe some DCL.
>
>I'm sure there can be other uses and my focus is too narrow. But for what I
>use EDT on VMS, it is what I listed above. Others may have different needs.
>
>> If any of that is missing then I think eyebrows will be raised.
>
>Not here. My eyebrows are raised because we're talking about this.
>
>> Several of these are just conventions. But it is conventions that
>> ensures that you can open an editor that you have never used
>> before and do some basic editing because the basic stuff is the
>> same.
>
>Good way to make mistakes ...

When 'vi' has an updated set of these WEENDOZE "features", I may, then, consider
the need for them in EDT.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 11/9/2021 3:09 PM, Bill Gunshannon wrote:
> And, anyway, real emacs has been available on VMS pretty much from the
> beginning.

I don't think beginning is the problem more the end.

As far as I can see then for GNU Emacs then:
- current version is 27
- last version supposed to support VMS was 22
- supposedly version 21 was actually ported to VMS
- Freeware CD seems to have version 19

Arne

On 11/9/2021 1:56 PM, Simon Clubley wrote:
> On 2021-11-08, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 11/8/2021 1:25 PM, Simon Clubley wrote:
>>> On 2021-11-08, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>>>> In article <b6c4a416-0ccf-4518-b5fa-039d8d23f88cn@googlegroups.com>,
>>>> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:
>>>>
>>>>> On Monday, November 8, 2021 at 6:27:48 PM UTC+13, Phillip Helbig (undress to reply) wrote:
>>>>>> It is the most efficient, not the most powerful. :-)
>>>>>
>>>>> As in helping you to be the most productive?
>>>>
>>>> Exactly.
>>>>
>>>
>>> How exactly ?
>>>
>>> By today's standards, EDT's limited functionality makes it the
>>> assembly language version of editors when compared to other editors
>>> which are fully featured editors.
>>>
>>> EDT can't even show more than one window on the screen at the same
>>> time. How does that make EDT the most productive editor ?
>>>
>>> Even EVE can do that, which makes even EVE much more productive than EDT.
>>>
>>> Simon.
>>>
>>
>> If it is all I need and use ....
>>
>> Which part of that was not understood?
>>
>
> The bit you missed above where Phillip claims EDT is the most productive
> editor, even in the face of all the much more powerful alternatives. :-)
>
> Simon.
>

If EDT is all I need and use, then it is the most productive for me.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 11/9/2021 2:17 PM, Arne Vajhøj wrote:
> On 11/9/2021 2:08 PM, Bill Gunshannon wrote:
>> On 11/9/21 1:38 PM, Dave Froble wrote:
>>> On 11/9/2021 10:57 AM, Bill Gunshannon wrote:
>>>> On 11/9/21 10:21 AM, Arne Vajhøj wrote:
>>>>> On 11/9/2021 9:57 AM, VAXman-@SendSpamHere.ORG wrote:
>>>>>> In article <smbq3b$o9$1@dont-email.me>, Simon Clubley
>>>>>>> By today's standards, EDT's limited functionality makes it the
>>>>>>> assembly language version of editors when compared to other editors
>>>>>>> which are fully featured editors.
>>>>>>
>>>>>> Where is the list of *today's standards* for editors?
>>>>>
>>>>> "today's standard" does not imply a formal (ANSI/ISO) standard just
>>>>> some relative vague general expectations.
>>>>
>>>> It's called "de facto" and it has been around a lot longer than
>>>> "today".
>>>
>>> Is your "de facto" the same as my "de facto"? I bet not.
>>>
>>
>> Probably not, but we don't get to set it anyway, the industryh
>> does. :-)
>>
>> Personally, my favorite editor depends entirely on what system
>> I am working on. On RSTS it's EDT. On Unix it's vi. And, on
>> any system that supports it, MicroEMACS. VMS I would have to say
>> LSE.
>
> It is worth nothing that it is increasingly common that code
> get actual written on a different platform than destination
> platform.
>
> Arne
>

Most definitely not here!

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <00B6B92D.D1BB8FAC@SendSpamHere.ORG>, VAXman-
@SendSpamHere.ORG writes:

> >In other words, WEENDOZE ...
>
> Gack, I just vomited a bit into my mouth.

Better than vomiting a byte. :-)

On 11/10/21 1:18 AM, Arne Vajhøj wrote:
> On 11/9/2021 3:09 PM, Bill Gunshannon wrote:
>> And, anyway, real emacs has been available on VMS pretty much from the
>> beginning.
>
> I don't think beginning is the problem more the end.
>
> As far as I can see then for GNU Emacs then:
> - current version is 27
> - last version supposed to support VMS was 22
> - supposedly version 21 was actually ported to VMS
> - Freeware CD seems to have version 19
>
> Arne
>
Emacs version 21.2 is available for VMS on VAX, Alpha and IA64. At least
one of the freeware CDs has the sources for this version.

I have local copies of the sources, which I used to build these
versions. I made the sources available here on c.o.v. They contain a few
minor changes/fixes. I didn't try to create a version for x86. As far
as I remember, there is a tool generated during the build to be used in
the build and that does not work out of the box in a cross build
environment. I expect that the sources used to build the Alpha version
will work for x86 as well. If I have time ...

On 11/10/2021 4:47 AM, hb wrote:
> On 11/10/21 1:18 AM, Arne Vajhøj wrote:
>> On 11/9/2021 3:09 PM, Bill Gunshannon wrote:
>>> And, anyway, real emacs has been available on VMS pretty much from the
>>> beginning.
>>
>> I don't think beginning is the problem more the end.
>>
>> As far as I can see then for GNU Emacs then:
>> - current version is 27
>> - last version supposed to support VMS was 22
>> - supposedly version 21 was actually ported to VMS
>> - Freeware CD seems to have version 19

> Emacs version 21.2 is available for VMS on VAX, Alpha and IA64. At least
> one of the freeware CDs has the sources for this version.

After checking the latest freeware CD I found it:

https://www.digiater.nl/openvms/freeware/v80/emacs/

21.2

Arne

In article <smg005$c0n$2@gioia.aioe.org>, helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
>In article <00B6B92D.D1BB8FAC@SendSpamHere.ORG>, VAXman-
>@SendSpamHere.ORG writes:
>
>> >In other words, WEENDOZE ...
>>
>> Gack, I just vomited a bit into my mouth.
>
>Better than vomiting a byte. :-)

LOL.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2021-11-09, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> On Wednesday, November 10, 2021 at 8:22:47 AM UTC+13, Simon Clubley wrote:
>> Brace and bracket matching.
>
> What about indentation matching?
>
> I write a lot of Python code, and as you may know, that eschews statement brackets in favour of using indentation to indicate nesting level. So while commands for jumping between matching bracketing symbols are still useful within expressions, they are less so for navigating around compound statements.
>
> Any editor you know of that has built-in commands for easing that? Even Emacs didn?t (that I know of), so I had to define my own.

That's the kind of thing that ends up in a language mode in Emacs.

I've just had a quick look around and found this:

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

No idea if it's any good for you.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Wednesday, November 10, 2021 at 10:47:56 PM UTC+13, hb wrote:
> Emacs version 21.2 is available for VMS on VAX, Alpha and IA64. At least
> one of the freeware CDs has the sources for this version.

Just a note that Emacs is not freeware <https://en.wikipedia.org/wiki/Freeware>, it is Free software <https://en.wikipedia.org/wiki/Free_software>.

On Thursday, November 11, 2021 at 7:37:59 AM UTC+13, Simon Clubley wrote:
> That's the kind of thing that ends up in a language mode in Emacs.
Which I prefer to avoid.
> I've just had a quick look around and found this:
>
> https://www.emacswiki.org/emacs/PythonProgrammingInEmacs
>
> No idea if it's any good for you.
Just a note that I write my Python code perhaps a little differently from how most people do it. I put in “#end” comments to mark the end of compound statements, e.g.
    @classmethod
    def create(celf, **kwargs) :
        "creates a new FontOptions object. See FontOptions.props for valid arg keywords."
        leftover = set(kwargs.keys()) - set(FontOptions.props)
        if len(leftover) != 0 :
            raise TypeError("unexpected arguments %s" % ", ".join(leftover))
        #end if
        result = celf()
        for k in celf.props :
            if k in kwargs :
                setattr(result, k, kwargs[k])
            #end if
        #end for
        return \
            result
    #end create
That way, jumping between lines with the same indent conveniently takes you to the start or end of a compound statement.