From e0bf13622b0922252439e3fa8b43df9877678d75 Mon Sep 17 00:00:00 2001 From: Robin Haberkorn Date: Sun, 25 Oct 2026 02:39:11 +0100 Subject: numbers are separate parser states and there are syntactic octal and hexadecimal constants now * Instead of every digit being a stack-modifying standalone command, there is a single continuous parser state (teco_state_number) now - even though it has certain unique characteristics. They are consequently documented in the ARITHMETICS AND EXPRESSIONS chapter of sciteco(7). * A number will therefore be rubbed out entirely by CTRL+W, including a possible @-modifier. * (!) Spaces within constants are no longer ignored, but will push separate numbers to the stack instead (`1 2 3` pushes 3 numbers). The significance of the `,` operator is thus further reduced. * (!) You can no longer "append" to numbers on the stack as in `Qa001` - this was never actually used and caused more confusion. * (!) Digits outside the current radix are no longer accepted. E.g. digit 2 after `2^R`. This feature was also never used. * (!) Octal constants are supported with leading zeros as in C. This works regardless of the current radix set via `8^R` or `^O`. It remains to see whether this is actually useful or is rather annoying (since every constant beginning with 0 is automatically octal, you cannot left-pad arbitrary numbers with 0). * Hexadecimal constants are supported by at-modifying them as in `@0ff`. They must still begin with a digit 0-9 and since A-F are valid SciTECO commands, you may need additional spaces to separate hexadecimal constants from regular commands as in `@0ff D`. During syntax highlighting the number style is extended back to the at-sign. Note: Hexadecimal constants couldn't have been realized via `16^R` (or some shortcut) since that depends on runtime state, but we must know during parsing whether symbols A-F are part of the number of regular SciTECO commands. * The new hexadecimal constants are used in the color schemes now. Thanks to them, we no longer need workarounds like the "color.rgb" macro. * Since numbers don't have a dedicated terminator character, but any letter may terminate it, the number state must behave similar to a start state. Consequently, hexadecimal constants will currently be auto-case-folded if you enabled this feature. I recommend not to write hex constants in upper-case, though. Perhaps this should be worked around with a custom process_edit_cmd() callback. * Test suite updated --- doc/sciteco.7.template | 40 ++++++++++++++++++++++++++++++++++------ 1 file changed, 34 insertions(+), 6 deletions(-) (limited to 'doc/sciteco.7.template') diff --git a/doc/sciteco.7.template b/doc/sciteco.7.template index 0ff3f51..fd909f9 100644 --- a/doc/sciteco.7.template +++ b/doc/sciteco.7.template @@ -1009,7 +1009,6 @@ preference are supported. Since the same stack is used for arithmetics and command arguments, arithmetics and arbitrary code may be freely mixed like in expression-centered languages and some classic TECOs. -In fact, in \*(ST digits are basically stack-operating commands. For the sake of macro portability all integers are 64-bit signed integers regardless of the host's architecture. The integer storage size may be changed at \*(ST build time @@ -1029,6 +1028,37 @@ binary (bit by bit) negation for instance using the .B ^_ command. . +.SS Constants +.SCITECO_TOPIC constants decimal octal hexadecimal +. +All integer constants have to begin with a digit from 0 to 9. +Constants beginning with 0 are octal constants where every digit +represents 3 bits \(em similar to C (e.g. \(lq033\(rq is decimal 27). +Digits 8 and 9 are not allowed in octal constants. +If the constant is at-modified, the subsequent constant is hexadecimal +(e.g. \(lq@0ff\(rq is decimal 255). +It must still always begin with a digit from 0 to 9 and ends with any +symbol other than 0-9 or A-F. +Since many \*(ST commands begin with letters A-F, you may have to separate +hexadecimal constants with an explicit space or even braces from its +subsequent command (e.g. as in \(lq@0ff D\(rq, which is equivalent to +\(lq255D\(rq). +.LP +All remaining numbers (not at-modified and beginning with 1-9) are +interpreted according to the current radix, as configured by the +\fB^R\fP, \fB^D\fP and \fB^O\fP commands. +The default radix is 10, so all remaining constants are usually +decimal. +Digits larger than or equal to the current radix are not allowed in +constants. +.LP +A complete constant is pushed on the number stack. +\# Mention the minus operator? +\# It's not technically part of the number syntax. +Since whitespace characters will also terminate integer constants +you can push a sequence of integers by space-separating them +(i.e. \(lq0 1 2 3\(rq is equivalent to \(lq0,1,2,3\(rq). +. .SS Operators .SCITECO_TOPIC operators . @@ -1115,9 +1145,10 @@ governing braces might be made stricter in a future release of \*(ST. Another construct that may be used as an argument barrier to explicitly separate arguments is the comma (\(lq,\(rq). It is obligatory when trying to push a sequence of number constants -like in \(lq1,2\(rq but is optional in many contexts where it is +like in \(lq1,2\(rq (although \(lq1 2\(rq will also work) +but is optional in many contexts where it is mandatory in classic TECO, like in \(lq.ZD\(rq. -I recommend to use it as much as possible in code where clarity +It is recommended to use it as much as possible in code where clarity matters. .LP The arithmetic evaluation order established by the operator precedence @@ -1137,9 +1168,6 @@ default value if the argument stack is empty so that expressions like However in front of opening brackets, like in \(lq-(1+2)\(rq, it is roughly equivalent to \(lq-1*(1+2)\(rq so that values calculated in brackets can be easily negated. -In front of digits the prefix sign specifies whether the digit is -added or subtracted from the value on the stack so that in front of -numbers the result is a negative number. . . .SH BUFFER RING -- cgit v1.2.3