All Lisp indentation schemes are ugly

> This post misses the IMO best indentation scheme for lisp [...]

Likewise, a lispier(?) and more compact compromise?:

    (define (match:element variable restrictions)
        (define (ok? datum)
            (every 
                (lambda (restriction)
                    (restriction datum))
                restrictions))
        (define (element-match data dictionary succeed)
            (and 
                (ok? data)
                (let ((vcell (match:lookup variable dictionary)))
                    (if vcell
                        (and 
                            (equal? (match:value vcell) data)
                            (succeed dictionary))
                        (succeed (match:bind variable data dictionary))))))
        element-match)

For Lisp users this is 35% extra vertical space for zero readability benefit. Or negative readability rather. When I see this formatting style I have to fix it before I can read it. It's like trying to read C code with an extra blank line after every single closing brace.

As a hobbyist that keeps trying to break into lisp, I think the absence of an obviously good formatter for lisps has made things much harder.

This looks like how I've naively tried to format things, and having started with python kind of makes sense.

But trying to read / edit code with 5 parentheses bunched together, I have the hardest time telling if they are matched or where. Thank goodness for vim / helix auto-matching.

Admit you posted this only to trigger lispers.

That is blasphemy.

More of an allman Lisp guy myself

  (
  define (match:element variable restrictions)
    (
    define (ok? datum)
      (
      every 
        (
        lambda (restriction)
          (restriction datum)
        )
        restrictions
      )
    )
  (
    define (element-match data dictionary succeed)
      (
      and 
        (ok? data)
        (
        let ((vcell (match:lookup variable dictionary)))
          (
          if vcell
            (
            and 
             (equal? (match:value vcell) data)
             (succeed dictionary)
            )
            (succeed (match:bind variable data dictionary))
          )
        )
      )
    )
    element-match
  )

I’ve been in too many arguments about Lisp indentation but that actually comes close to decent with a couple of changes: move the singleton closing parens up, and reduce to, say, 2 spaces.

I am sure there are some Emacs modes or plugins for other editors that could go back and forth between this and the more commonly-seen style.

That's a point too!

Well, it's all based on my experience. In two Lisp companies I worked in, colleagues complained or even were trying to fix how I indent things. So it's not just some anxiety whatever, it's experience that needs explanation and justification.

I'm aware of arrow-macros/diamond wands, and am using them myself. But I often have to write dependency-less libraries for moderately complicated algos, and that's where indentation style is the only thing I can rely on.

The second Python method that uses intermediary variable is what I use because it works much better with a debugger

I also like this trick to avoid nested for loops:

  import itertools 
  names = ['Bob', 'Sam']
  nums = [1,2]
  letters = ['A','B']
  for name,num,letter in itertools.product(names,nums,letters):
      print(f"{name} {num} {letter}")

  Bob 1 A
  Bob 1 B
  Bob 2 A
  Bob 2 B
  Sam 1 A
  Sam 1 B
  Sam 2 A
  Sam 2 B

You can have the same step-by-step in Lisp via LET*. The problem outlined by the author happens when you have a function call where 1) the operator has a long name, 2) there are many arguments. The TREE-TRANSFORM-IF is such a case and you can't solve it by just "going step by step".

That deep nest of function calls is why I love languages that have bash-style pipelining as a built in feature, either with explicit shell piping features, or where everything Function(myObj) is also implicitly myObj.Method()

Then it becomes (eg PowerShell, a language I hate but use constantly)

  Faz | 
      Far |
      Baz |
      Bar |
      Foo

  Faz()
      .Far()
      .Baz()
      .Bar()
      .Foo()

I don't know why we're so stuck on prefix notation for function calls. Postfix is just easier to read in long chains.

I prefer a third approach - chaining method calls via `.method()`. C#'s LINQ extension methods and Rust's iterator methods do it and I find it to be the best of both worlds most of the time.

I literally program in Lisp for five years now, and I ain't going anywhere.

...the author is using ed scripts as a static site generator, in a way completely unrelated to the post content. People are allowed to do oddball things.

Humans read code. I'd like to become a machine someday, but alas, I still am human and I need to read mine/others' code. Lisp code too.

For matching parentheses, Emacs users can use a package called rainbow-delimiters that colors matching delimiters. Different levels of enclosure use different colors. I've found this to be too much visual noise -- I am usually just interested on the delimiters for the current s-expressions. In this vein, having multiple different colored backgrounds would be garish and distracting for me.

I have seen it done with foreground colours: https://github.com/alphapapa/prism.el

I think I once saw a project turning Scheme into a visual block-based representation, but I can't find it again.