On 30/08/2024 01:03, Lawrence D'Oliveiro wrote:
> On Thu, 29 Aug 2024 14:01:05 +0200, David Brown wrote:
>
>> On 29/08/2024 02:23, Keith Thompson wrote:
>>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>
>>>> On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:
>>>>>
>>>>> But ok, I found your post and removed all the #end comments. I found
>>>>> it just as readable without them as with them.
>>>>
>>>> You know what? You are right. That example was just too
>>>> well-structured.
>>
>> So why not try to write /all/ your code in a well-structured manner, so
>> that you don't feel the need to add these "#end" comments?
>
> Because not all examples can be made that neat, as I demonstrated.

Your example could easily have been written in a more structured manner
than you did. Keith and I both demonstrated that. (And when you remove
the useless stuff from your function, it's even simpler.)

I agree that not /all/ code can easily be written in a neat,
well-structured manner - and that occasionally breaking your normal
coding convention rules can bring out patterns in the code that make it
easier to understand, and easier to write correctly. But the solid
majority of code /can/ be written in a well-structured manner, for most
languages.

>
>> def register_additional_standard(self, managed_objects) :
>> """
>> registers additional standard interfaces that are not
>> automatically installed at Connection creation time. Currently
>> the only one is the object-manager interface, registered with
>>
>> «conn».register_additional_standard(managed_objects = True)
>> """
>
> Note that Python’s indentation rules don’t apply to multiline string
> literals -- don’t you wish they did? So you end up with all that extra
> space within the literal. Do you see why I prefer to avoid that?

No - or at least, it is very hard to comprehend why you might prefer the
mess you gave. It is correct that Python multiline strings include any
indentation in the strings. There are three possibilities here -
sometimes you want the indents (and thus include them), sometimes you
don't want them (and thus you align them at the left of the text), and
sometimes you don't care (and thus put them wherever seems neatest).
Most function docstrings fall into that third category, since they are
mostly used as comments in the code and for the "help" command which
ignores the leading indents.

It is probably most common to have multiline docstrings at the left of
the file. I have never before seen a silly mess with manual \n line
breaks and line continuation characters, and I hope never to see it again.

>
>> Line continuation characters in Python are usually an indicator of poor
>> formatting, or an unhealthy obsession with line length limits.
>
> I like to keep within a line length limit of about 100 characters.
>

That's a reasonable limit, but does not change my observation.

>> I don't know if I am more experienced than you in Python (I may have
>> been using Python for longer, but you may have worked with it more), but
>> I would say that the "#end" comments directly detract from readability.
>
> Think about why you bother to indent code in languages where the compiler
> ignores such indentation anyway: it means you are expressing the structure
> of code in two different ways, one via statement brackets, and the other
> via indentation. This redundancy aids in understanding that the code does
> what you think it does.
>

In languages with explicit blocking, the delimiters determine what the
code does. The indents show the human reader what the code is supposed
to do. These are, hopefully, the same thing - but they might not be.
In Python, as there is only one source of blocking, there is no
possibility of such an error (once you have ensured you have no mix of
tabs and spaces).

Redundancy is only a help if there is a way to automatically check and
enforce consistency. Without that, redundancy can be worse than useless
- if the two methods get out of sync, the casual reader will
misunderstand the code, and the careful reader will see there is a
problem but not know what it is.

So for languages with explicit blocking, you need to be absolutely
committed to keeping consistency, and use the tools you have - editors
with automatic indents, gcc's "-Wmisleading-indentation" warning, and
anything else to ease the cognitive burden and reduce the risk of
inconsistencies.

With Python, that is simply not an issue.

(Another example of such redundancy is when people put comments saying
what a piece of code does, rather than making the code itself clear.
Changes to the code can easily lead to comments getting out of sync with
the code, leading to confusion and misunderstanding.)

> Python gets rid of this redundancy, by having the compiler take notice of
> the whitespace and removing the statement bracketing symbols. So I put it
> back, by adding statement bracketing symbols that the compiler ignores.

And that is worse than useless.

At least with languages that have explicit block delimiters, the
compiler will always have some checks on consistency. And tools (either
compiler warnings, advanced editors, linters, etc.) can do more advanced
checks. With comments, you have nothing.

On 30/08/2024 00:57, Lawrence D'Oliveiro wrote:
> On Thu, 29 Aug 2024 14:24:01 +0200, David Brown wrote:
>
>> def foo(a, b, c) :
>> if a :
>> if b :
>> if c :
>> doThis()
>>
>> That looks unfinished to me. So I will add a "return" at the end (with
>> a single tab indent, in this case).
>
> A redundant “return” ... kind of like my redundant “#end” comments, except
> yours work in a more restricted set of places ...

Yes - the restriction is a major advantage. Python can check it, and
there are far fewer ways for the programmer to get it wrong.

>
>> Don't you ever just accept that a language is the way it is, and it is
>> perfectly useable that way?
>
> Of course not.

How silly. You should work to improve the things you can, instead of
wasting effort arguing with brick walls. If you want to get involved in
the design and future of a language, that's fine, but few people have
the time and skills needed or the opportunity to do it as serious paid
work. Getting worked up about the way Python blocking works is about as
productive as getting worked up about the way English language spelling
works. There are countless other more useful ways to spend your time -
and certainly many more enjoyable ways.

>
>> Or think that perhaps other people in the world know better than you do
>> about how they want their language to work?
>
> And vice versa.

It's not your language, so there is no "vice versa".

>
>> Has it never occurred to you that the people behind a given
>> language - such as Python - considered various alternatives and decided
>> that making it the way they did was the best choice overall for the
>> language they wanted?
>
> Barring a few obvious stupidities, yes of course they were, and are, smart
> people.

When there are a number of smart, experienced and educated people
involved in the decisions, "obvious stupidities" are extremely unlikely.
That's the point of involving multiple people and gathering opinions
from many in the field.

There can be design decisions that don't suit /you/ - but they were not
designing a language for /you/. There can be design decisions that made
sense at the time, but turned out to be unwise in the end. Those are
not "obvious stupidities", even with 20/20 hindsight. And there can be
compromises where it is known that a decision is bad in at least some
ways, because it allows other better things to be done - again, not a
"stupidity" even if the one aspect in isolation looks bad.

On Thu, 29 Aug 2024 16:57:21 -0700, Keith Thompson
<Keith.S.Thompson+u@gmail.com> wrote in
<87zfou9926.fsf@nosuchdomain.example.com>:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> [...]
>> Think about why you bother to indent code in languages where the
>> compiler ignores such indentation anyway: it means you are expressing
>> the structure of code in two different ways, one via statement
>> brackets, and the other via indentation. This redundancy aids in
>> understanding that the code does what you think it does.
>>
>> Python gets rid of this redundancy, by having the compiler take notice
>> of the whitespace and removing the statement bracketing symbols. So I
>> put it back, by adding statement bracketing symbols that the compiler
>> ignores.
>
> You might find Bython useful.
>
> https://github.com/mathialo/bython
>
> (I don't, but you might.)

Thank you for the pointer.

(Had been wondering if there was something like "ratfor
for python", and here it is. :) )

--
-v

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:
>
>> Vim is an editor that has the most simple and also very powerful
>> indenting for well structured data and programs I've yet seen. (Not
>> mentioning its equally powerful other editing facilities.)
>
>Vim is only good for text-editing, though

Again, L'D'O' is wrong.

On Thu, 29 Aug 2024 21:27:36 +0200
David Brown <david.brown@hesbynett.no> wrote:

> /All/ languages, except perhaps Bart's private language that is only
> used by him, have their annoyances. I have worked at least a little
> with a fair number of languages, and I've never seen one that I
> thought was "perfect". But different people have different things
> that the like and dislike about any given language.
>
> So if you have the choice of which language to use (many programmers
> do not), you pick one that has more things you like for the task in
> question in comparison to the things you don't like.

Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just
weird.

> But it's important to understand that these are opinions - the
> designers of Python were /not/ stupid to have made the language that
> way. They just had different opinions from you, and the had a much
> better basis for forming those opinions than you or I.

Yeah, well, your opinion that my opinion is just, like, my opinion is
just, like, your opinion, man.

On Fri, 30 Aug 2024 11:38:05 +0200
David Brown <david.brown@hesbynett.no> wrote:

> Getting worked up about the way Python blocking works is about as
> productive as getting worked up about the way English language
> spelling works. There are countless other more useful ways to spend
> your time - and certainly many more enjoyable ways.

Some people actually enjoy arguing on the Internet, y'know.

> When there are a number of smart, experienced and educated people
> involved in the decisions, "obvious stupidities" are extremely
> unlikely. That's the point of involving multiple people and gathering
> opinions from many in the field.

You may consider it as "unlikely" as you wish, but the fact is that
literal whitespace has been considered Obviously Stupid in the computer-
programming world for so long that it was the subject of a joke re: JCL
in "Real Programmers Don't Use Pascal," published in 1983.

That's not to say that "considered Obviously Stupid" is the same thing
as "objectively wrong" - but if your argument is that all of this is on
equal footing as Just Opinions, discounting decades of established
opinion across the industry in preference to the opinions of the subset
of Python developers & advocates who believe in literal whitespace as
Unambiguously Good rather gives the lie to that.

On 30/08/2024 17:14, John Ames wrote:
> On Thu, 29 Aug 2024 21:27:36 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> /All/ languages, except perhaps Bart's private language that is only
>> used by him, have their annoyances. I have worked at least a little
>> with a fair number of languages, and I've never seen one that I
>> thought was "perfect". But different people have different things
>> that the like and dislike about any given language.
>>
>> So if you have the choice of which language to use (many programmers
>> do not), you pick one that has more things you like for the task in
>> question in comparison to the things you don't like.
>
> Sure - but picking one that best suits your needs doesn't mean you
> can't critique its annoyances/flaws. This team-sports mentality is just
> weird.

(I gather the politically correct response to that is "I'm not weird -
/you/ are weird" :-) )

There's a difference between critiquing something and saying the
language designers were stupid. I can say I prefer explicit blocking
delimiters. I can give reasons why I think those are better than
white-space based blocks. But to have any kind of useful discussion,
you need to be able to consider what advantages the alternatives have,
and think about why some people might have different opinions. Writing
"I get lost with white-space indentation and have to add lots of
comments - therefore the language is flawed and the designers made
stupid decisions" is not helpful critique - it's just ranting.

Of course you will find things you dislike about any language you use.
And discussing those things, and ways to mitigate their impact, is also
fine. It's the "this language is fundamentally flawed because /I/
dislike a particular aspect of it" attitude I disagree with.

>
>> But it's important to understand that these are opinions - the
>> designers of Python were /not/ stupid to have made the language that
>> way. They just had different opinions from you, and the had a much
>> better basis for forming those opinions than you or I.
>
> Yeah, well, your opinion that my opinion is just, like, my opinion is
> just, like, your opinion, man.
>

On 30/08/2024 17:28, John Ames wrote:
> On Fri, 30 Aug 2024 11:38:05 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> Getting worked up about the way Python blocking works is about as
>> productive as getting worked up about the way English language
>> spelling works. There are countless other more useful ways to spend
>> your time - and certainly many more enjoyable ways.
>
> Some people actually enjoy arguing on the Internet, y'know.

Up to a point, I agree. Where would the internet be without arguments?
Cat videos and porn, I suppose.

But sometimes I think discussions could be a little more informative and
a little less repetitive ranting. Occasionally it is also nice to learn
something new from the internet. (I actually learned from this thread
that Python 3 is better at checking for mixed tabs and spaces than
Python 2 was.)

>
>> When there are a number of smart, experienced and educated people
>> involved in the decisions, "obvious stupidities" are extremely
>> unlikely. That's the point of involving multiple people and gathering
>> opinions from many in the field.
>
> You may consider it as "unlikely" as you wish, but the fact is that
> literal whitespace has been considered Obviously Stupid in the computer-
> programming world for so long that it was the subject of a joke re: JCL
> in "Real Programmers Don't Use Pascal," published in 1983.
>
> That's not to say that "considered Obviously Stupid" is the same thing
> as "objectively wrong" - but if your argument is that all of this is on
> equal footing as Just Opinions, discounting decades of established
> opinion across the industry in preference to the opinions of the subset
> of Python developers & advocates who believe in literal whitespace as
> Unambiguously Good rather gives the lie to that.
>

Python is a hugely popular language, with whitespace for blocks. C, C++
and Java are hugely poplar languages with braces as delimiters. I don't
see how anyone can get an "established opinion" from that.

But to be fair, the worst case of significant whitespace /was/ obviously
stupid - that is makefiles treating tabs and spaces differently. The
original author of make said himself that it was a daft idea, but
unfortunately the utility took off in popularity so quickly that it
could not be rectified.

On Thu, 29 Aug 2024 21:36:08 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 29/08/2024 18:44, Janis Papanagnou wrote:
>> On 29.08.2024 14:30, David Brown wrote:
>>> On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
>>>> [...]
>>>
>>> Then don't use vim - use an editor that suits your needs.
>>
>> LOL. (You appear to be joking. - If not, continue reading...)
>>
>
>I was not joking.
>
>> But what makes you think that his needs are not covered by Vim?
>
>You seem to have missed the point - sorry if I was not clear.

The irony :)

On Fri, 30 Aug 2024 08:14:21 -0700
John Ames <commodorejohn@gmail.com> gabbled:
>On Thu, 29 Aug 2024 21:27:36 +0200
>David Brown <david.brown@hesbynett.no> wrote:
>
>> /All/ languages, except perhaps Bart's private language that is only
>> used by him, have their annoyances. I have worked at least a little
>> with a fair number of languages, and I've never seen one that I
>> thought was "perfect". But different people have different things
>> that the like and dislike about any given language.
>>
>> So if you have the choice of which language to use (many programmers
>> do not), you pick one that has more things you like for the task in
>> question in comparison to the things you don't like.
>
>Sure - but picking one that best suits your needs doesn't mean you
>can't critique its annoyances/flaws. This team-sports mentality is just
>weird.

Some insecure people feel an attack on their favourite language is some kind
of attack or slight against them personally. Its a pathetic and juvenile trait
that unfortunately is found a lot amongst IT types.

On Fri, 30 Aug 2024, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:
>>
>>> Vim is an editor that has the most simple and also very powerful
>>> indenting for well structured data and programs I've yet seen. (Not
>>> mentioning its equally powerful other editing facilities.)
>>
>> Vim is only good for text-editing, though
>
> Again, L'D'O' is wrong.
>

This is the truth! Nothing of value in his posts.

On Fri, 30 Aug 2024 11:38:05 +0200, David Brown wrote:

> You should work to improve the things you can, instead of
> wasting effort arguing with brick walls.

Which is exactly what I have been doing. You are just another of those
trying to dispute my techniques.

> It's not your language, so there is no "vice versa".

It’s open source. It’s *everybody*’s language.

>> Barring a few obvious stupidities, yes of course they were, and are,
>> smart people.
>
> When there are a number of smart, experienced and educated people
> involved in the decisions, "obvious stupidities" are extremely unlikely.

Now I know you haven’t used Python that much.

On Thu, 29 Aug 2024 14:05:41 +0200, David Brown wrote:

> ... put in so much extra
> crap and silliness that readers get caught up in that instead of
> noticing that most of the function is meaningless.

Interesting. Now you are trying to claim that, because you don’t
understand what the code does, that makes it somehow “meaningless”?

On Wed, 28 Aug 2024 19:19:38 -0700, Keith Thompson wrote:

> My impression is that your unconventional style indicates a relative
> lack of experience in Python.

You think maybe I should practise by writing more Python code?

OK, how about your thoughts on comparing this

for attrname in obj.tag_attrs :
attr = getattr(obj, attrname)
if attr != None :
if isinstance(attr, enum.Enum) :
attr = attr.value
elif isinstance(attr, Type) :
attr = unparse_signature(attr)
elif not isinstance(attr, str) :
raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
out.write(" " * indent + "<" + tag_name)

with this

for attrname in obj.tag_attrs :
attr = getattr(obj, attrname)
if attr != None :
if isinstance(attr, enum.Enum) :
attr = attr.value
elif isinstance(attr, Type) :
attr = unparse_signature(attr)
elif not isinstance(attr, str) :
raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
out.write(" " * indent + "<" + tag_name)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 28 Aug 2024 19:19:38 -0700, Keith Thompson wrote:
>> My impression is that your unconventional style indicates a relative
>> lack of experience in Python.
>
> You think maybe I should practise by writing more Python code?

And you snipped the part where I acknowledged that might be an invalid
conclusion. I have no opinion on what you should do.

> OK, how about your thoughts on comparing this
>
> for attrname in obj.tag_attrs :
> attr = getattr(obj, attrname)
> if attr != None :
> if isinstance(attr, enum.Enum) :
> attr = attr.value
> elif isinstance(attr, Type) :
> attr = unparse_signature(attr)
> elif not isinstance(attr, str) :
> raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
> attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
> out.write(" " * indent + "<" + tag_name)
>
> with this
>
> for attrname in obj.tag_attrs :
> attr = getattr(obj, attrname)
> if attr != None :
> if isinstance(attr, enum.Enum) :
> attr = attr.value
> elif isinstance(attr, Type) :
> attr = unparse_signature(attr)
> elif not isinstance(attr, str) :
> raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
> attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
> out.write(" " * indent + "<" + tag_name)

The difference is obvious: the second calls attrs.append() even if attr
is None. I don't know what point you're trying to make.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Wed, 28 Aug 2024 19:19:38 -0700, Keith Thompson wrote:
>>> My impression is that your unconventional style indicates a relative
>>> lack of experience in Python.
>>
>> You think maybe I should practise by writing more Python code?
>
> And you snipped the part where I acknowledged that might be an invalid
> conclusion. I have no opinion on what you should do.

Let me amend that slightly. I suggest that you'd be better off writing
idiomatic Python code, at least if you want to share that code with
others. You are of course under no obligation to follow my advice, and
I won't spend any more time trying to persuade you.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On 31/08/2024 01:49, Lawrence D'Oliveiro wrote:
> On Thu, 29 Aug 2024 14:05:41 +0200, David Brown wrote:
>
>> ... put in so much extra
>> crap and silliness that readers get caught up in that instead of
>> noticing that most of the function is meaningless.
>
> Interesting. Now you are trying to claim that, because you don’t
> understand what the code does, that makes it somehow “meaningless”?

I covered that in an earlier post. If you didn't bother reading it
earlier, why should I bother posting it again?

To be fair, it's possible that what you posted was only part of a real
function.

On Sat, 31 Aug 2024 17:06:05 +0200, David Brown wrote:

> On 31/08/2024 01:49, Lawrence D'Oliveiro wrote:
>
>> Interesting. Now you are trying to claim that, because you don’t
>> understand what the code does, that makes it somehow “meaningless”?
>
> I covered that in an earlier post.

Maybe in your mind you thought you did. Nowhere in your comments on this
code did you say so, that I can find.

On 03/09/2024 02:09, Lawrence D'Oliveiro wrote:
> On Sat, 31 Aug 2024 17:06:05 +0200, David Brown wrote:
>
>> On 31/08/2024 01:49, Lawrence D'Oliveiro wrote:
>>
>>> Interesting. Now you are trying to claim that, because you don’t
>>> understand what the code does, that makes it somehow “meaningless”?
>>
>> I covered that in an earlier post.
>
> Maybe in your mind you thought you did. Nowhere in your comments on this
> code did you say so, that I can find.

To be accurate, the code in question was not actually /meaningless/ - it
was merely pointlessly complex, inefficient and unclear.

You wrote:

def register_additional_standard(self, **kwargs) :
for key in kwargs :
if kwargs[key] :
if key == "managed_objects" :
# ....
else :
raise TypeError("unrecognized argument keyword
“%s”" % key)

I changed it in a re-write to:

def register_additional_standard(self, managed_objects) :
if managed_objects :
# ....

That change, I think, was lost in the discussions about bizarre
formatting practices.

On Tue, 3 Sep 2024 10:46:55 +0200, David Brown wrote:

> I changed it in a re-write to:
>
> def register_additional_standard(self, managed_objects) :
> if managed_objects :
> # ....

My original was meant with future extensibility in mind. That was made
clear in the docstring. You *did* read the docstring, didn’t you?

On 03/09/2024 23:56, Lawrence D'Oliveiro wrote:
> On Tue, 3 Sep 2024 10:46:55 +0200, David Brown wrote:
>
>> I changed it in a re-write to:
>>
>> def register_additional_standard(self, managed_objects) :
>> if managed_objects :
>> # ....
>
> My original was meant with future extensibility in mind. That was made
> clear in the docstring. You *did* read the docstring, didn’t you?

Even if it was intended to be extendable, it would still be a /very/
silly way to write the code.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 22:57 this Thursday (GMT):
> On Thu, 29 Aug 2024 14:24:01 +0200, David Brown wrote:
>
>> def foo(a, b, c) :
>> if a :
>> if b :
>> if c :
>> doThis()
>>
>> That looks unfinished to me. So I will add a "return" at the end (with
>> a single tab indent, in this case).
>
> A redundant “return” ... kind of like my redundant “#end” comments, except
> yours work in a more restricted set of places ...
>
>> Don't you ever just accept that a language is the way it is, and it is
>> perfectly useable that way?
>
> Of course not.
>
>> Or think that perhaps other people in the world know better than you do
>> about how they want their language to work?
>
> And vice versa.
>
>> Has it never occurred to you that the people behind a given
>> language - such as Python - considered various alternatives and decided
>> that making it the way they did was the best choice overall for the
>> language they wanted?
>
> Barring a few obvious stupidities, yes of course they were, and are, smart
> people.

Subjectively, I prefer early returns over nested ifs:

def foo(a, b, c):
if !a: return
if !b: return
if !c: return

doThis()
--
user <candycane> is generated from /dev/urandom

On Sat, 7 Sep 2024 18:30:03 -0000 (UTC), candycanearter07 wrote:

> Subjectively, I prefer early returns over nested ifs:

Nested ifs nest, early returns don’t.

On 29.08.2024 21:36, David Brown wrote:
> On 29/08/2024 18:44, Janis Papanagnou wrote:
>> On 29.08.2024 14:30, David Brown wrote:
>>> On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
>>>> [...]
>>>
>>> Then don't use vim - use an editor that suits your needs.
>> [...]
>
>> But what makes you think that his needs are not covered by Vim?
>
> You seem to have missed the point - sorry if I was not clear.
>
> He complained that he didn't want to learn complicated macros in Vim
> just to be able to indent or un-indent lines of code. The solution is
> obvious - he should use an editor other than Vim.

This is not what I'd call a solution. I'd call it elusion; and in both
senses - if he didn't use his editor for that space-indenting because
he doesn't know how to do it he could look that up, but it is not any
issue to do that, only more laborious than indenting brace structures,
and the suggestion to switch to another tool is also elusive because
it doesn't address the issue (he would still have to learn how to do
it in any other tool). - But that was not the point.

>
> He could, of course, learn how to use Vim. It's a perfectly good editor
> with a lot of features. [...]

The point was about language design and (well known) problems with a
design that uses white-space for semantical purposes. That the brace
structures can usually be edited in better, simpler ways (beyond also
providing safety etc. using a more sophisticated designed language).

>
> There are more than enough decent editors to choose from, that cover the
> basic needs of programmers. Some people use one editor for everything,
> others use a range for different purposes - whatever suits you. But it
> is pretty absurd to complain that it is difficult to indent code just
> because you (i.e., Muttley) think it is hard to do in one particular
> editor.

As said; it was about "the language was designed properly"[Muttley].
And saying that switching the editor would solve something here is
just missing the point.

You can (also in Vim) write macros, as you correctly imply, or do
all the things that you can do with "other tools" (but only equally
laborious as in these other tools) as I already said. You can also
(for that specific IMO mis-designed language) enable "folding" (by
spaces) in Vim to not have to write macros (and not littering the
standard editor environment) that makes it comparably simply to do
the indentation more comfortably with less keystrokes. But nothing
beats the editing of parenthesized structures. (And doesn't change
any language mis-design.) YMMV.

Janis

On 30.08.2024 04:53, Lawrence D'Oliveiro wrote:
> On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:
>
>> Vim is an editor that has the most simple and also very powerful
>> indenting for well structured data and programs I've yet seen. (Not
>> mentioning its equally powerful other editing facilities.)
>
> Vim is only good for text-editing, though.

"Only"? - Yes, Vim is a text-editor. (With only few functions beyond.)
And it does that in an excellent most efficient way I've not yet seen
in any other text editor. (Exactly what I need for universal editing
of any text. YMMV.)

> It assumes a file is split into
> lines. Emacs makes no such assumption, and can also edit non-text files.

You have obviously no clue.

Janis