﻿The default mode of process is equivalent to writing to a buffer __default__, and at the end executing the file
	= = = = = filterbuffer(raw) __default__
Doing the same abstraction once more, the buffer with that contents may be also created dynamically, then loaded via filterbuffer().
On the gripping hand, this may be also
	= = = = = filterbuffer(raw) __default__pre
	= = = = = filterbuffer(raw) __default__
	= = = = = filterbuffer(raw) __default__post
With (initially) empty buffers __default__pre and __default__post (to which one has a chance to write later!).  And what one
writes to these buffers may be triplicated likewise.  Etc.

For postponed actions need an extra argument "ignore errors": with 2 would just put into eval, with 1 converted to a warning,
negative values stop the remaining undo actions for that many frames (with -2 stopping for the current frame and one more).

One needs to prohibit __get()ing a reference.  Use __getref() when you expect a reference (but no checks for reference are
performed).

MISS: input__end($n) with $n==0 ending the current input stream, or also $n enclosing streams.

MISS: need to specify what happens with a group on input__end(): survives / should be closed before / close-if-still-open.

MISS: input__end_to($group_type): end input of the files opened up to the the opened-latest-group of the given type.

  Likewise for “closing enclosed groups”???  Join together into 1 API by introducing suitable groups???

    May run forever???  Even the language if group__start, group_end, group__postpone (with the arguments to the last command
    restricted to these 3 calls) is probably Turing complete???

MISS: _-prefixed versions of config__*() which check the prefix _ __ ___ of the key and make it read/write only.

MISS: pipelining preprocessor with “filters”: filters consists of 3 components: preprocessor, massaging of promises, and the
      concatenator of the resulting candidates-for-sections.

Uplevel w.r.t. the recursion stack should be recalculated into the usual uplevels; a special do-nothing group may be used.

allow not 1 active preprocessor engine, but a stack of them, chained, and have a cfg__pop() primitive method.

Macros are templates marked as OK-to-be-ignored.

Hash to mark macros as “types”, with per-type-warning configurable?  Which way to hash, types to macros, or macros to types, or
pairs???

An extra parameter $is_replay for the syntax callbacks for the non-first pass.  (Probably, the boundary of the preceding pass cannot
be part of this???

hash keys.  Setting/getting them employs a serialization method, by default JSON???
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!	THIS IS TOO DANGEROUS.
					Access control to Fab/* keys should be guarded by ungettable/settable types of values ???

#unset — but maybe it is going to make undo harder???

Recursive invocation is needed for massaging data between different levels:
  • The hash
  • Input file names
  • Input strings
  • Output sections

A top→down approach to recognizing the “reconfiguration directives”: but cannot
we support a bottom→up approach too, when the preprocessor recognizes interlaced
directives?  How to deal with recursion: return an indicator that the state
changed?  But it is changing permanently, one needs to filter out changes — but how
the internal calls know the filters needed for the enclosing calls???

the preprocessor needs a guarantee that it is going to be reentered

=========================== DONE/OBSOLETE beyond this point

Docs are not cleaned up (mark these by “???”!); and parts are still missing.

cfg__set() with a scalar key should fail with more than 1 values to set.

What if no $offset and list???
	Passing C<$offset> on a non-list key halts with C<E_TYPE_MISMATCH>.

When undoing, undo data should be guarded, at least up to the exit.

====================

uplevel should allow execution AFTER the group is closed

There should be an indicator that a method is called “from” before/after uplevel.  If uplevel is called “uplevel”ed, it should
only register the requests,; at end of the enclosing processing of the uplevevel-ed stuff, these postponed commands should be
executed (reversing order again???).

  Should reversing of order be customizable, and in which order one should put the inverted group and the non-inverted group????
  Probably better to have more than 2 types, and for every “type” have the pre/post specified, and whether upleveling from the
  group reverses the order???

  The type is a Unicode string starting with either PRE-, or post-, and sorting as if it is appended by ".000"… with an infinite
  number of characters '0' (but before the possible suffix "-inv".  Then sorting lexicographically (with actual closing happening
  between PRE- and post-, and -inv groups inverted gives the order of execution.  (Still: inversion of postponed postpones???)

  When sorting, one can literally pad by ".0"* up to the maximal length of the name of existening groups + 1!

    Note that "string#" comes before "string" for any value of "string", and different strings “sort differently”!

  The current docs mix pre/post semantics.

    Status Details:
      • DONE: Clean, non-heuristic API: group__postpone($depth, $priority, $how, $method, @args).
      • DONE: Real-number priority: < 0 executes PRE-undo (before rollback), 0.0 is the
        rollback point, >= 0 executes POST-undo (in restored enclosing scope).
      • DONE: User-selected 'append' vs 'prepend' controls execution order within equal priorities.
      • DONE: Two-level execution architecture:
          - Level 1: Sorted array of priority indices (@priorities).
          - Level 2: Hash of internal arrays ($top->{postponed_by_prio}).
          - Fast path: sequential shift from current internal array. Insertions into existing
            present/future buckets push/unshift directly without recalculation.
          - Slow path: insertions in the past (time machine) or into newly created future priorities
            route to $top->{extra_prio} and trigger index recalculation on demand.
