Request to put tested and ready made upgrades into DASM

[appleonedoc-tech]

For my current project, I had to add a few features to DASM which may be useful for other DASM users:

• source files now can have line numbers starting at first character. These are ignored / skipped.
  As DASM required labels to begin at the first position in a line, here is the remedy for that:

• Labels terminated with a colon ':' are now recognized anywhere in first part of the line, before
  any mnemonic or directive, but after the (optional) line numbers and '|' characters:

• a sequence of '|' characters (ASCII $7C) after the (optional) line number or at the beginning
  of a line are ignored. The sequence can be of any length, but can't contain any other characters
  nor any white space. This feature is meant to make nesting levels of .IF / .ENDIF blocks human
  readable.

Yet another added feature:

• DCX directive added to automatically invert the MSB of the last byte of a string. This was a common
  trick used, for instance, in the Microsoft BASIC interpreter.

This feature involves adding only one (!) line of code each in the files globals.c and ops.c

You might ask why I needed these extra features. Well, a few weeks ago, Microsoft has published their
original source code for Microsoft 6502 BASIC, see here:

https://github.com/microsoft/BASIC-M6502

... but this source won't assemble with any 6502 assembler I tried. I had to edit the original source to make it fit to assemble with DASM which involved adding lines and I wanted to keep track of which lines came from the original source and which were added by me. Hence, the line number feature. It also turned out that the deep nesting levels of their conditional assembly blocks are unfathomable for humans, so I made a machine do the tedious job to add the '|' indicating nesting levels. The added DCX is needed for their peculiar way to terminate strings. Which saves one byte per string. Some strings terminate with a zero, though, which is easy to implement, so no added DC variant for this.

The tgz file with my mods is attached. An example ('test.asm') showing all the new features is included.

I would appreciate if you could put these features into DASM as soon as possible, because I can release my edited Microsoft 6502 BASIC source code only when DASM has been upgraded to be able to handle it.

I think these added features are also useful for other developers, not only for those who want to explore Microsoft's 6502 BASIC.

• Uncle Bernie

Attachment: rename the file to UB_DASM_mods.tgz --- github refused this so I changed it to .zip

UB_DASM_mods.zip

[GrantMTG]

Very interesting! I'm sure a lot of folks using DASM are reverse engineering code from either binary (ERPOMs) or from other assemblers.

[andrew-davie]

Thanks for the details on your work. I’m still contemplating the update and implications of these changes. On the one hand, it’ nice to see new capabilities; on the other, changes that are unlikely to find any use other than a specific use-case are problematic. I’d like to hear/see what others think on this update, before approving.

• source files now can have line numbers starting at first character. These are ignored / skipped.

Personally I see no need/use for this.

As DASM required labels to begin at the first position in a line, here is the remedy for that: • Labels terminated with a colon ':' are now recognized anywhere in first part of the line, before any mnemonic or directive, but after the (optional) line numbers and '|' characters: • a sequence of '|' characters (ASCII $7C) after the (optional) line number or at the beginning of a line are ignored. The sequence can be of any length, but can't contain any other characters nor any white space. This feature is meant to make nesting levels of .IF / .ENDIF blocks human readable.

Well, I’d use comments for that. So I’m very much against this addition. It’s an esoteric, very much non-standard, and individualistic solution to the problem you describe. Personally I don’t feel these belong in a generic assembler. I really dislike the breaking of the hard and fast rule that labels start at the beginning of a line, always.

• DCX directive added to automatically invert the MSB of the last byte of a string. This was a common trick used, for instance, in the Microsoft BASIC interpreter. This feature involves adding only one (!) line of code each in the files globals.c and ops.c You might ask why I needed these extra features. Well, a few weeks ago, Microsoft has published their original source code for Microsoft 6502 BASIC, see here: https://github.com/microsoft/BASIC-M6502 ... but this source won't assemble with any 6502 assembler I tried. I had to edit the original source to make it fit to assemble with DASM which involved adding lines and I wanted to keep track of which lines came from the original source and which were added by me. Hence, the line number feature. It also turned out that the deep nesting levels of their conditional assembly blocks are unfathomable for humans, so I made a machine do the tedious job to add the '|' indicating nesting levels. The added DCX is needed for their peculiar way to terminate strings. Which saves one byte per string. Some strings terminate with a zero, though, which is easy to implement, so no added DC variant for this.

Again, a lot of this stuff could be handled with comments and simple changes in the source code.

The tgz file with my mods is attached. An example ('test.asm') showing all the new features is included. I would appreciate if you could put these features into DASM as soon as possible, because I can release my edited Microsoft 6502 BASIC source code only when DASM has been upgraded to be able to handle it.

The dependency is created by your decisions as to how to proceed; as noted lots of the changes could have been handled with commenting instead of modifications to DASM. I’m not rejecting anything; I’m just in a phase of contemplation and hopefully discussions with others in the community to see what the consensus is. A big plus, of course, is that this doesn’t *break* anything.

I think these added features are also useful for other developers, not only for those who want to explore Microsoft's 6502 BASIC.

I look forward to others’ views on this. Thanks again for your contribution/work; let’s give it a week and make a call then. Unless someone else approves it pre-emptively. I’m not on top of who the admins are as I write this. Cheers A

[thrust26]

I agree with Andrew here. We shouldn't make the code more complex for a single use case (and thus compromise maintainability).

[appleonedoc-tech]

*Hi *,* *I'm not so apt with citations of emails (too old to learn new tricks) so I have copied your response and added my comments / suggestions in boldface:*

• source files now can have line numbers starting at first character.

These are ignored / skipped. Personally I see no need/use for this. *The use case is if you merge or modify source code from various sources, you can have a tool put in line numbers in the original pieces, and then do manual edits / add-ons, and afterwards you still have “hooks” which help to identify which part of the code came from where. It's also useful during the work to immediately jump to the place in the original sources, if needed to look what came from where (in the original source code). Note that even DASM spits out line numbers in its assembly listing. Which serves the same purpose but at a lower level.* *In my current work, I used a tool to remove all the original comments in the original Microsoft source code to have leaner code to work with (less distractions / more efficient to work with) but the line numbers will be used by another tool to put the comments back.* *(There might be IDEs which have source code editors that can keep track of which line of code came from where, and this feature is extremely important, especially when working from copyrighted third party code used under license. No professional software developer can afford to lose track which parts of the final product belong to the third party and which he added and owns himself / or his company owns)*

As DASM required labels to begin at the first position in a line, here is

the remedy for that:

• Labels terminated with a colon ':' are now recognized anywhere in first

part of the line, before

any mnemonic or directive, but after the (optional) line numbers and '|'

characters:

• a sequence of '|' characters (ASCII $7C) after the (optional) line

number or at the beginning

of a line are ignored. The sequence can be of any length, but can't

contain any other characters

nor any white space. This feature is meant to make nesting levels of .IF

/ .ENDIF blocks human

readable.

Well, I’d use comments for that. So I’m very much against this addition. It’s an esoteric, very much non-standard, and individualistic solution to the problem you describe. Personally I don’t feel these belong in a generic assembler. I really dislike the breaking of the hard and fast rule that labels start at the beginning of a line, always. *First, you can't use comments to untangle /.IF/.ELSE/.ENDIF blocks nested 6 levels or more deep. I've attached an example how it looks with the '|' option.* *Second, IMHO, and may scholars of Computer Science would agree with me and have voiced similar criticisms: any computer language which insists on positioning certain constructs on predefined tabulator positions as syntactical elements is obsolete, outdated, and garbage. * *I am well are that there are recently developed 'computer languages' which insist on that but I refuse to use them, as I said, they are garbage, just because of their stupid rules. * *If you have ever studied Compiler Construction or related topics, you would have learned that any good computer language definition will allow “white space” anywhere between keywords, constants, logical blocks, etc., and the lexer and the grammar should be designed to fully support this. The ability to use added “whitespace” and indentations to make code more human readable is one of the key features of modern computer languages. * *I think we should not insist on rules which IBM invented for their 80 column punched cards. This is computer stone age !* *I can't understand why you insist, in the 21**st** Century, on the “hard and fast rule that labels start at the beginning of a line, always” which dates back in the computer stone age / punched cards, and don't get me wrong, when I had to learn FORTRAN I had to use these long obsolete IBM card punchers with their terrible keyboards (teletype style round keys not suited for fast touch typists like me) to prepare my source code. At least these dinosaurs of the computer age were able to do “corrections” --- they would punch a new card from your old card up to the point of the end of the deleted characters. Do you really want that DASM users live in the computer stone age ?*

• DCX directive added to automatically invert the MSB of the last byte of

a string. This was a common

trick used, for instance, in the Microsoft BASIC interpreter. This feature involves adding only one (!) line of code each in the files

globals.c and ops.c

You might ask why I needed these extra features. Well, a few weeks ago,

Microsoft has published their

original source code for Microsoft 6502 BASIC, see here: https://github.com/microsoft/BASIC-M6502 ... but this source won't assemble with any 6502 assembler I tried. I had

to edit the original source to make it fit to assemble with DASM which involved adding lines and I wanted to keep track of which lines came from the original source and which were added by me. Hence, the line number feature. It also turned out that the deep nesting levels of their conditional assembly blocks are unfathomable for humans, so I made a machine do the tedious job to add the '|' indicating nesting levels. The added DCX is needed for their peculiar way to terminate strings. Which saves one byte per string. Some strings terminate with a zero, though, which is easy to implement, so no added DC variant for this. Again, a lot of this stuff could be handled with comments and simple changes in the source code. *I don't see a way how to use a comment to reach into a string being assembled to set the MSB of the last character in the string. The only way to achieve the same effect as DCX is to manually edit each and every string which needs the feature, strip away the last character, put it as an individual character, and OR it with $80 … this is extremely error prone and clumsy, and the code is hard to read and even harder to extend the texts later.* *'ATASM' had this 'MSB' setting feature and this is why I used ATASM before DASM. Alas 'ATASM' has a bug which causes a 'segmentation fault' if any code is assembled into the zero page. And I don't have the time to hunt down that bug. So I decided to switch to DASM, which is close enough to ATASM to be able to digest my source code base (huuuuge, maybe > 1 Million lines of 6502 source code, Microsoft 6502 BASIC alone, when fully worked out with all Applesoft additions, may have 15000 lines of source code).* The dependency is created by your decisions as to how to proceed; as noted lots of the changes could have been handled with commenting instead of modifications to DASM. I’m not rejecting anything; I’m just in a phase of contemplation and hopefully discussions with others in the community to see what the consensus is. A big plus, of course, is that this doesn’t *break* anything. *Even more so if you turn the added module in the parse() function only on if a command line option is set. This practically guarantees that none of the existing assembly language source code out there for DASM ever is affected by the added features.*

I think these added features are also useful for other developers, not

only for those who want to explore Microsoft's 6502 BASIC. I look forward to others’ views on this. Thanks again for your contribution/work; let’s give it a week and make a call then. Unless someone else approves it pre-emptively. I’m not on top of who the admins are as I write this. Cheers A *I think that at the moment there will not be many people out there in the world which would want the added DASM features I proposed to you. Because so far I did not release my edited & expanded version of the original MICROSOFT 6502 BASIC source code, for which these additions are necessary to a) identify which parts came from the original source code published by Microsoft, and b) which parts I added (no line numbers), and c) better human readability of the deeply nested .IF/.ELSE/.ENDIF constructs.* *Keep in mind that there are 10's of millions of people out there in the world who learned BASIC on a computer which had Microsoft BASIC inside, Apple II, Commodore PET/CBM/C-64, OSI, etc. etc. and some of these will want to revisit Microsoft 6502 BASIC based on my ongoing work to be published maybe in Y2026. * *They need an assembler (DASM ?) which is able to digest my code.* *So if you don't put my extensions into DASM, then all I can do is to fork DASM into another github project and add my extensions. Or, include the current version of DASM with my extensions as source code into my tarball given to the public.* *I hate both of these options because it means that this forked version of DASM will never be maintained and kept up to snuff.* *This issue can only be avoided if you chose to adopt my extensions to DASM. My goal is that when I publish my rendering of the Microsoft BASIC source code (as open source of course) that there is a companion macro assembler which can digest it and generate binaries.* *I did not choose DASM because I like it, I chose it because it is still actively being maintained. There are lots and lots of “open source software corpses” out there which are not maintained anymore, and “ATASM” is one of these, and hence can't be used for my Microsoft BASIC project. (The original source code they released this September also is a “corpse” because no open source assembler can digest it, and it's V1.1 which can't produce the binaries of legacy computers which used V1.0.)* *Here is a snippet of my rendered source code of 6502 Microsoft BASIC which shows my points made above:* 6900 .IF REALIO == 3 6901 | JMP READY .ENDIF 6902 .IF !APPLE2 && [REALIO != 3] 6903 | LDWDI STROUT 6904 | STWD RDYJSR+1 |.IF OSI || JSR SCRATH |.ENDIF 6905 | LDWDI READY 6906 | STWD START+1 6907 | JMP (START+1) 6909 |.IF !ROMSW || OSI 6910 || FNS: .DC "WANT SIN-COS-TAN-ATN" 6911 || .BYTE 0 |.ENDIF 6912 |.IF !KIMROM 6913 || AUTTXT: ACRLF 6914 || .BYTE 12 6915 ||| .DC "WRITTEN " ||.IF !OSI 6916 ||| .DC "BY WEILAND & GATES" 6917 ||| ACRLF ||.ELSE ; OSI has a different message: ||| .DC "BY RICHARD W. WEILAND." . . . *All the line numbers refer to the line number of the original Microsoft source code. This allows us to see which parts came from there and which parts I did add to be able to generate matching binaries. The line numbers will later be used to automatically add the comments of the original Microsoft source code back, but they will stay there as a cross reference to the original source code.* *Hope you now understand what I mean.* *All this work hinges on the extra features I have proposed for DASM.* *You can choose to be with me and support my work, or be against me and keep DASM as “clean” (and utterly useless for my noble purpose) as you please. * *I would prefer that you choose to join me in this effort to preserve the original Microsoft 6502 BASIC source code as a “living” assembler source which actually can generate matching binaries (using a good assember as DASM) and not as the sad “corpse” which Microsoft so generously has thrown over the “fence”, to us (the open source community).* *- 'Uncle' Bernie*

…

On Fri, Nov 28, 2025 at 12:45 AM Thomas Jentzsch ***@***.***> wrote: *thrust26* left a comment (dasm-assembler/dasm#157) <#157 (comment)> I agree with Andrew here. We shouldn't make the code more complex for a single use case (and thus compromise maintainability). — Reply to this email directly, view it on GitHub <#157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B2TCW6ZJSEMR5EH5QY67JA33674SHAVCNFSM6AAAAACNFZ6BGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOBYGI3DAOBQGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[thrust26]

I can understand that you want DASM accept differently formatted code. And suppose I get some of your arguments.

E.g. the label stuff would be OK for me, as it would allow formatting code using indentions, without having labels sticking out to the very left.

But for the other parts, there are alternatives.

• Why don't you use indentions instead of '|'? Maybe I miss something, but I cannot see any reason for your suggestion here.
• For the line numbers, which you need as reference, there are alternatives outside DASM. E.g. a good file compare tool can align old and new code.
• Regarding DXC, this seems to be an indicator that DASM's e.g. macro and EQM/DV functionality need to be enhanced. I regularly have to work against such DASM limitations, but I got used to that and my time is limited. Else I would have worked on that part. So making DASM more flexible in general here seems like the much better approach.

Finally, regarding the fork, you can maintain it and pull all changes from the master. And if you stop pulling it, then this indicates that there is no need for your fork anymore.

[dionoid]

Thanks for sharing your work. I agree with Andrew and Thomas: these changes are highly specific to your use case and would add unnecessary complexity to DASM. Features like line-number prefixes, | nesting markers, and DCX string handling probably better belong in a personal fork or a preprocessing step.

I also want to note that the “garbage languages” remarks and the unstructured reply don’t help the technical discussion.

A maintained fork seems the most practical solution, and you can always sync upstream changes as needed.

[appleonedoc-tech]

Dionoid wrote: " A maintained fork seems the most practical solution, and you can always sync upstream changes as needed." A: Alas, I don't have the time to maintain such a fork. Does the "sync upstream changes" you suggest imply that this "sync" process is automatically done by github ? Or do I need to push a button ? Who pushes that button after I croak and push up daisies ?

…

--- Hope you can see that forking code has many complications. The added block in DASM's parse() function is much less of a hassle, especially if you add a command line option to activate it, and keep it turned off until wanted by the user. - Uncle Bernie (As for the "garbage languages", I accept that there a strong opinions on that, and I don't want to argue about this any further than this: I do belong to those who insist that added "white space" never should have any syntactical meaning in any computer language. Simply because "white space" can't be easily discerned by human eyes, especially when aged, and many OCR scanners also have trouble with getting that right. For instance, try to OCR a few pages of PYTHON code from a book and have fun trying to get the result to work. Why not using a little helper like '|' ? Then, even OCR would work, and the language as such would be perfectly fine and less prone to errors / mistakes).

On Sun, Nov 30, 2025 at 8:05 AM Dionoid ***@***.***> wrote: *dionoid* left a comment (dasm-assembler/dasm#157) <#157 (comment)> Thanks for sharing your work. I agree with Andrew and Thomas: these changes are highly specific to your workflow and would add unnecessary complexity to DASM. Features like line-number prefixes, | nesting markers, and DCX string handling really belong in a personal fork or a preprocessing step. I also want to note that the “garbage languages” remarks and the unstructured reply don’t help the technical discussion. A maintained fork seems the most practical solution, and you can always sync upstream changes as needed. — Reply to this email directly, view it on GitHub <#157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B2TCW64VPRSYQYFGMDNFIUL37MBSJAVCNFSM6AAAAACNFZ6BGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOJSGY2TCMZXHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[appleonedoc-tech]

To respond to "thrust26": Q: "Why don't you use indentions instead of '|' ?" A: Better human readabilily, you can immediately scroll down and up to see where the bracketing level you are interested in starts and end. At an older age you will find it more difficult to estimate bracketing levels from white space indentions. This may apply even to younger people with varifocal glasses. Printable characters are more easily counted (at a glance). "For the line numbers, which you need as reference, there are alternatives outside DASM. e.g. a good file compare tool can align old and new code." Q: Which tool do you mean ? Hopefully, not "diff". The proposed use of line numbers is not about helping machines to track lines back to the original source, but for humans who want to do this cross-lookup manually. You wrote on DCX: "So making DASM more flexible in general here seems like the much better approach." Agree, but keep in mind that a "general solution" which would allow powerful manipulation of strings to be turned into object code is complex to implement. What I did propose is a simple solution which only requires addition of two (!) lines to the DASM source code. A more sophisticated solution would not use DCX but allow macros to manipulate strings passed to them as parameters. So DCX could be replaced by a macro called DCX which would access the last character of a string parameter and manipulate it before using the regular DC to emit the string. But I don't see a way to put this capability into DASM without a lot of work. Adding the two lines of code to implement "DCX" would be much more efficient ... - Uncle Bernie

…

On Sun, Nov 30, 2025 at 3:57 PM Uncle Bernie ***@***.***> wrote: Dionoid wrote: " A maintained fork seems the most practical solution, and you can always sync upstream changes as needed." A: Alas, I don't have the time to maintain such a fork. Does the "sync upstream changes" you suggest imply that this "sync" process is automatically done by github ? Or do I need to push a button ? Who pushes that button after I croak and push up daisies ? --- Hope you can see that forking code has many complications. The added block in DASM's parse() function is much less of a hassle, especially if you add a command line option to activate it, and keep it turned off until wanted by the user. - Uncle Bernie (As for the "garbage languages", I accept that there a strong opinions on that, and I don't want to argue about this any further than this: I do belong to those who insist that added "white space" never should have any syntactical meaning in any computer language. Simply because "white space" can't be easily discerned by human eyes, especially when aged, and many OCR scanners also have trouble with getting that right. For instance, try to OCR a few pages of PYTHON code from a book and have fun trying to get the result to work. Why not using a little helper like '|' ? Then, even OCR would work, and the language as such would be perfectly fine and less prone to errors / mistakes). On Sun, Nov 30, 2025 at 8:05 AM Dionoid ***@***.***> wrote: > *dionoid* left a comment (dasm-assembler/dasm#157) > <#157 (comment)> > > Thanks for sharing your work. I agree with Andrew and Thomas: these > changes are highly specific to your workflow and would add unnecessary > complexity to DASM. Features like line-number prefixes, | nesting > markers, and DCX string handling really belong in a personal fork or a > preprocessing step. > > I also want to note that the “garbage languages” remarks and the > unstructured reply don’t help the technical discussion. > > A maintained fork seems the most practical solution, and you can always > sync upstream changes as needed. > > — > Reply to this email directly, view it on GitHub > <#157 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/B2TCW64VPRSYQYFGMDNFIUL37MBSJAVCNFSM6AAAAACNFZ6BGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOJSGY2TCMZXHA> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[thrust26]

To respond to "thrust26":

Q: "Why don't you use indentions instead of '|' ?"

A: Better human readabilily, you can immediately scroll down and up to see
where the bracketing level
you are interested in starts and end. At an older age you will find it more
difficult to estimate bracketing levels from white space indentions. This
may apply even to younger people with varifocal glasses.
Printable characters are more easily counted (at a glance).

I (60+) strongly disagree here. I find them very irritating. And completely uncommon.

"For the line numbers, which you need as reference, there are alternatives
outside DASM. e.g. a good file compare tool can align old and new code."

Q: Which tool do you mean ? Hopefully, not "diff". The proposed use of line
numbers is not about helping machines to track lines back to the original
source, but for humans who want to do this cross-lookup manually.

E.g. Compare It! or WinMerge for Windows.

You wrote on DCX: "So making DASM more flexible in general here seems like
the much better approach."

Agree, but keep in mind that a "general solution" which would allow
powerful manipulation of strings
to be turned into object code is complex to implement. What I did propose
is a simple solution which only requires addition of two (!) lines to the
DASM source code. A more sophisticated solution would not use DCX but allow
macros to manipulate strings passed to them as parameters. So DCX could be
replaced by a macro called DCX which would access the last character of a
string parameter and manipulate it before using the regular DC to emit the
string. But I don't see a way to put this capability into DASM without a
lot of work.

Yup, a good solution sometimes requires more work. It is up to you to invest time here.

Adding the two lines of code to implement "DCX" would be much more
efficient ...

That's the usual (bad) excuse for a hack.

[andrew-davie]

Q: "Why don't you use indentions instead of '|' ?" A: Better human readabilily, you can immediately scroll down and up to see where the bracketing level

Many, if not most modern IDE editors allow you to actually show whitespace as visible characters. For example, in VSCode/VSCodium, just select “Toggle Render Whitespace”. With this enabled, you can achieve all that you seem to need.

you are interested in starts and end. At an older age you will find it more Q: Which tool do you mean ? Hopefully, not "diff". The proposed use of line numbers is not about helping machines to track lines back to the original source, but for humans who want to do this cross-lookup manually. E.g. Compare It! or WinMerge for Windows.

I have used “Beyond Compare” for many years. It does an excellent visual job of showing exactly what’s new, what’s moved and from where, and what’s been deleted. Using line numbers for this is not necessary with such tools available.

You wrote on DCX: "So making DASM more flexible in general here seems like the much better approach."

I think the string handling/options could be improved somewhat. I, too, would like to see a generic solution.

Yup, a good solution sometimes requires more work. It is up to you to invest time here. Adding the two lines of code to implement "DCX" would be much more efficient ...

I’m not against this addition so much. But it is still a single-project use-case and that does not really belong in a generic assembler.

[andrew-davie]

" A maintained fork seems the most practical solution, and you can always sync upstream changes as needed." A: Alas, I don't have the time to maintain such a fork. Does the "sync upstream changes" you suggest imply that this "sync" process is automatically done by github ? Or do I need to push a button ? Who pushes that button after I croak and push up daisies ?

I concur with @dionoid that these changes belong in a fork of the project. If there are features that prove useful for other projects, then they can be ported to the main project. DASM has so few changes these days that maintaining a fork should be a rather straightforward task, especially for the author of the fork’s changes.

(As for the "garbage languages", I accept that there a strong opinions on that, and I don't want to argue about this any further than this: I do belong to those who insist that added "white space" never should have any syntactical meaning in any computer language. Simply because "white space" can't be easily discerned by human eyes, especially when aged, and many OCR scanners also have trouble with getting that right. For instance, try to OCR a few pages of PYTHON code from a book and have fun trying to get the result to work. Why not using a little helper like '|' ? Then, even OCR would work, and the language as such would be perfectly fine and less prone to errors / mistakes).

Python is an awesome language; the “hardwired” requirements for formatting and whitespace actually make it much easier to use and maintain consistency between different programmers. It makes the source code look very clean, consistent, and immediately apparent as to nesting levels. I disliked this “feature” when I first started using it, bu now I think it’s an awesome “feature” of the language. Compatibility with OCR is an interesting requirement for a language :) In any case, I agree with @dionoid that emotive stuff inside pull requests for DASM is unlikely to sway moderators positively. At this point, I think the consensus from the moderators who have replied appears to be 0) we appreciate you working on DASM and submitting changes for review 1) These changes could/should be implemented as a fork to DASM 2) They are too specific to one use-case to belong in DASM proper 3) Many of the changes can be achieved in other ways; specifically the line numbering (using a visual file-compare tool), the indentation (using a visual display of whitespace in your editor), and the string terminator (can be done manually pretty easily). 3) The DASM string handling is sub-par and could use update/improvements At this stage, my intention is to decline the changes, with respect. I do understand how frustrating it can be submitting significant changes/improvement to an open source project. I have had my own major improvement to OsmAnd rejected basically because they were in the middle of a major version change. They never got added, in the end, which is a great shame. Such is life. Cheers A