<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bert Freudenberg wrote:
<blockquote
 cite="mid:00EAB382-3B2F-4F7C-B68E-800B08821E59@freudenbergs.de"
 type="cite">
  <pre wrap="">On 2013-10-04, at 17:45, Chris Muller <a class="moz-txt-link-rfc2396E" href="mailto:asqueaker@gmail.com">&lt;asqueaker@gmail.com&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">Compare

       [ undeclared at: sym put: nil ]
               on: AttemptToWriteReadOnlyGlobal
               do: [ :noti | noti resume: true ]

to:

       [ undeclared
               at: sym
               put: nil ]
               on: AttemptToWriteReadOnlyGlobal
               do: [ :noti | noti resume: true ]

Isn't the first one much more "rectangular" and easier to read? I find the
indentation in the second one irritating.
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">Yes, I agree with you for that one case.  RB, Indented Control Flow,
etc. do not specify how to handle keywords sent to Blocks.  One
suggestion is to add a blank line, as in:

        [ undeclared
                at: sym
                put: nil ]

                on: AttemptToWriteReadOnlyGlobal
                do: [ :noti | noti resume: true ]

Or, an extra indention:

        [ undeclared
                at: sym
                put: nil ]
                     on: AttemptToWriteReadOnlyGlobal
                     do: [ :noti | noti resume: true ]

The important thing to handle the _general_ case, so the computer can
do at least 97% of the formatting.  If we had a larger keyword
message, your rule would look like this:

          [ mySoundRecorder copyTo: resultBuf from: j to: (j + n - 1)
from: buf startingAt: firstInBuf normalize: nFactor dcOffset: dcOffset
]
                  on: AttemptToWriteReadOnlyGlobal
                  do: [ :noti | noti resume: true ]
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You're misinterpreting my "rule" ;)

My rule is more like: If it clearly fits on one line then do not spread it over multiple lines. Otherwise, use your best judgement. :)

For your example I would probably end up with something like

        [ mySoundRecorder
                copyTo: resultBuf from: j to: (j + n - 1)
                from: buf startingAt: firstInBuf
                normalize: nFactor dcOffset: dcOffset
        ]
                on: AttemptToWriteReadOnlyGlobal
                do: [ :noti | noti resume: true ]

even if it's not "agile". Source code is read way more often than written, so IMHO it is worth spending some time formatting it to make the meaning as obvious as possible. 

That said, I could live with your version below, in particular if it was automatically produced. It just doesn't feel as nice as the hand-formatted one which even takes into account the semantics of keywords to find suitable breaks.

  </pre>
  <blockquote type="cite">
    <pre wrap="">which, clearly, is a mess compared to:

          [ mySoundRecorder
                copyTo: resultBuf
                from: j
                to: (j + n - 1)
                from: buf
                startingAt: firstInBuf
                normalize: nFactor
                dcOffset: dcOffset ]
                     on: AttemptToWriteReadOnlyGlobal
                     do: [ :noti | noti resume: true ]

I would LOVE to make pretty print use RB formatting in a way that's
acceptable to the wider community, so we can be developers and not
formatting slaves.
    </pre>
  </blockquote>
  <pre wrap=""><!---->

- Bert -

  </pre>
</blockquote>
Bert, I like your vertical alignment of square braces for blocks.&nbsp; For
myself, this is my only absolute formatting rule, excepting only when
opposing braces fit the same line.&nbsp; Unfortunately most Smalltalk code
puts the closing brace as soon as possible at the end of the last
statement of the block.&nbsp; Sometimes three or four closing braces pile up
together at the end of a line, and it is slow to isolate the matching
open braces. (Maybe that indicates other architectural issues with the
code, but the reality is these situations occur.)&nbsp; As a slight twist of
my own to your last example, I indent the first statement one tabstop. <br>
<br>
<pre wrap="">        [         mySoundRecorder
                        copyTo: resultBuf from: j to: (j + n - 1)
                        from: buf startingAt: firstInBuf
                        normalize: nFactor dcOffset: dcOffset
        ]        on: AttemptToWriteReadOnlyGlobal do: 
                [         :noti |
                        noti someOtherMethod. 
                        noti resume: true 
                ]

cheers -ben
</pre>
<br>
</body>
</html>