[9.0b12] multiple commands in custom command (em_X, em_Y)

[sirksel]

When one builds a custom command from multiple other custom commands in a comma series, it only works when a BUILT-IN command begins the series. If one begins with a harmless built-in command (with no side effects to the intended purpose) as the first in the series, everything works fine. Given that this workaround functions properly, it seems like the current behavior is not the intended behavior. It seems like if you are using valid commands, built-in or custom, they are intended to be able to be chained with commas.

EXAMPLE (DOES NOT WORK):
[em_ComboCommand]
cmd=em_Command1, em_Command2
; where em_Command1 and em_Command2 are properly defined

WORKAROUND (DOES WORK):
[em_ComboCommand]
cmd=cm_RereadSource, em_Command1, em_Command2
; where em_Command1 and em_Command2 are properly defined
; and cm_RereadSource has no effects to the contrary other than as a workaround

(This inconsistency is also present in prior versions, and not new to 9.0b12, although I only incrementally tested 9.0b11.)

Mr. Ghisler, thank you again for all your great work on this great program. This is just a small nit in what is otherwise a best-in-class, very well-thought-out program.

[ghisler(Author)]

Yes, this was to prevent careless people from adding a recursion by mistake, e.g.
[em_ComboCommand]
cmd=em_ComboCommand

This was before I added the possibility of multiple commands. I will add more sophisticated recursion detection and lift this limit. But I will not look for cross calls, e.g.
[em_ComboCommand1]
cmd=em_ComboCommand2

[em_ComboCommand2]
cmd=em_ComboCommand1

[ghisler(Author)]

This should be fixed in beta 13, please try it!

[sirksel]

Fix confirmed. Custom commands can now consist of a chain of other custom commands, and they do not require an initial built-in command (as described in the original post). Thank you, Mr. Ghisler, for taking time to make this change.