Replying to several good posts without quoting:

I, too, utterly and completely detest the format standard chosen for some languages. I was surprised (although I shouldn't be) that Wikipedia has an article on indent styles. (Thanks, Ed.) I like a language that has very few parentheses, brackets, and braces (which is one of many reasons I like Forth). Assembly language generally only uses these in the operands, for indirects and for equations in forming operands; but it can certainly benefit from indentation like HLLs. My assembly-language use of indentation went way up when I started using the structure macros, as shown in the routine about a page from the bottom of http://wilsonminesco.com/multitask/#cycexec where you see the nested IF statements, CASE structure, etc., in assembly. (In most cases, these assemble exactly the same thing you would if you wrote the instructions all out by hand, but the macros just make it more clear.) When you have multiple levels of indentation, and/or lists of input parameters for macros, for example
and/or long variable names or operand-forming clauses like
or

the comments might get pushed way out; so you can't just dictate that all comments will start in a particular column. For visual factoring, the comments for the section, whether it's five lines or fifty, need to be lined up (as opposed to all starting all over the place). Automatically starting them all way out to the right just to allow for long instruction lines may deprive shorter instruction lines of their needed comment space, and also make it hard to visually follow the line over across a lot of blank space.

The solution then might be to have some defaults, but allow the user to tell it to deviate from those under specified conditions or areas of the code. Never lock him into a predefined way of doing things.

I use the MultiEdit programmer's text editor which offers smart indenting, construct matching, and syntax highlighting; but I've never used those options. Another great editor on the market today is UltraEdit which I think BDD uses.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I do use UltraEdit, but have the auto-formatting functions disabled, as they really don't work well with assembly language source code. I do my own indentation when needed.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I couldn't figure out how to get Emacs to indent my source correctly, and I didn't really want to install .NET just to run the formatter, so I went ahead and whipped up my own python script. It's very quick and dirty and probably quite brittle, but it does what I need. I've attached it in case anyone else finds it useful.

It doesn't work for normal notation, sorry, I should have made that more clear. Short version is I find the official 65816 notation baroque, confusing, annoying to type, error-prone, and full of visual clutter, and created my own, called "Typist's Assembler Notation" (TAN) because it is optimized for ten-finger typing. The long version is here: https://docs.google.com/document/d/16Sv ... Tm4SQ/edit (I'll be moving it to GitHub at some point).

However, in the end, tinkfmt doesn't do stuff that much differently from your script, so I doubt it would be worth your while to convert it for your needs.

As for the wider discussion on indentation: Google has lots of experience with Python, and based on that experience claims that with large projects that lots of different people are working on, it becomes too much of a problem (https://talks.golang.org/2012/splash.article): Having just rewritten about 2,500 lines of Python code, I admit I had two or three cases where I screwed up the indentation level moving or pasting code; however, I'm not sure I wouldn't have done the same thing with braces. I prefer Python's way because it is just cleaner, the "executable pseudocode" effect.

It's nice that the Go people had a good look and a think before rejecting Python's approach.

Over the years, I've peered into blurry terminals and stared at Tele-Type® hardcopy studying any number of programs written in a number of assembly languages. My opinion is the 65C816 assembly language is pretty clean compared to a few others, especially x86 assembly language and even worse, the code used with the U.S. Postal Service's ZIP Mail Translator (ZMT). This is not to say that the various methods by which one specifies operands to '816 instructions are ideal. However, the '816 versions for dealing with 16 and 24 bit operands are derivatives of the official 6502 notation that has been with us for some 40 years. The use of <, >, ^, etc, to pick which parts of a multibyte operand get assembled makes complete sense to me. Some of the notation is not intuitive, but given that there are only so many characters on a standard QWERTY keyboard that are not alphanumeric, coming up with alternatives is difficult.

As I'm sure you know, the 6502 assembly language is essentially the Motorola 6800 assembly language, with suitable changes to reflect the characteristics of the 6502. The model adopted by Motorola and MOS Technology is that the three-character mnemonic tells the programmer the basic operation (load, store, add, etc.) and the register on which the basic operation occurs. The rest of the instruction tells the assembler how the instruction is to address memory. Three character mnemonics are easily processed, as a uniformity of field size reduces search and match algorithms to a simple form. That basic model was endorsed by the IEEE in the 1970s, although never formally ratified as a standard.

The MC68000 assembly language continues to use many of the 6800 assembly language elements, but obviously had to be expanded quite a bit to work with the much greater scope of the 68K's capabilities. Having been fluent in 6800 assembly language at one time, I had little trouble making the transition to the 68K. In other words, a commonality of dialect was a significant factor in being able to work with the assembly languages of three different processors.

As an aside, when I developed the macros I use to assemble '816 instructions and native addressing modes in the Kowalski simulator I faced a similar challenge. How can I name the macros so they are close enough to real mnemonics that they make sense to me? Some macros are just the names of the instructions they synthesize, such as BRL and TCD. Others, especially those that involve an addressing mode not known to the 65C02, were more difficult. However, where there's a will there's a way.

Immediate mode instructions that are to be assembled with a 16 bit operand are the same as the parent instruction, with a W tacked on the end. So LDA #$1234, which cannot be assembled as written, becomes LDAW $1234. The macro "knows" that it is an immediate mode instruction and hence assembles A9 34 12. Another interesting one is JSR (<addr>,X), which is unique to the 65C816. Originally that was synthesized in a macro named JSX. I have since changed it to JSRX. So the instruction JSR ($1234,X) is written as JSRX $1234 and assembles FC 34 12.

Ultimately, the purpose of an assembly language is to make it reasonably easy for the programmer to remember the instructions and what they do. Microprocessor manufacturers have historically dictated the syntax to be used with their creations' assembly language in the interests of maintaining a form of standardization. This became especially important with the 6502 because it was used in so many different computer systems, not to mention machine controllers, modems, dumb terminals, etc. Deviating from the manufacturer's standard is not something to be lightly considered, as doing so may make the resulting code opaque to others. Obviously, my use of macros to assemble '816 code in a 65C02 assembler makes me guilty of that very transgression.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!