aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/stdio-commands.c
AgeCommit message (Collapse)AuthorFilesLines
40 hoursrevised and improved the Unicode glyph-to-byte conversion heuristicsRobin Haberkorn1-1/+1
Previously almost all glyph-to-byte offset conversions consulted Scintilla's line index and counted characters on the resulting line. For instance a simple expression like `.+1J` would scan the same line twice completely, which would be very slow on pathologically long lines. Even insertions did that due to having to update the ^Y ranges. If you repeat such an operation over all characters as in `<.+1:J;>` you would have complexity O(n^2) for n = line length. Only commands with an explicit relative nature like `C` and `A` would use teco_view_glyph2bytes_relative() which scans beginning at dot as long as the relative movement is less than 1024 glyphs. Wit the new heuristics almost all glyph-to-byte and byte-to-glyph conversions can make use of that optimization. This requires that dot must at all times be known in glyphs as well - the byte position is managed by Scintilla (SCI_GETCURRENTPOS). We therefore introduced teco_current_doc_set_dot() and teco_current_doc_get_dot() to update dot in the current buffer or Q-Register -- it cannot be stored along with the view since Q-Registers share a single view. A number of auxiliary functions have been introduced for converting relative to a known (glyphs,bytes) offset pair and for converting absolute and relative positions with regard to the current doc and SCI_GETCURRENTPOS position. Of course this is error-prone since the glyph and dot positions are interdependant - they must always be kept in sync. With these new optimizations even pathologically long lines can (usually) be managed even in UTF-8 documents. It does not address slow-downs in Scintilla's line layout, yet. grosciteco.tes for instance runs twice as fast now.
2026-04-20do not execute `^A` in parse-only modeRobin Haberkorn1-0/+3
This was especially dangerous since the introduction of a message level parameter, which could still be popped from the expression stack in parse-only mode or during lexing. This effectively broke n^A interactively in GTK.
2026-04-14`^A` now accepts an optional integer to specify the message severityRobin Haberkorn1-6/+28
* I.e. you can now log warnings and errors from SciTECO code as well. * We do not need a version of ^A accepting code points, since this is supported by ^T already.
2026-01-01updated copyright to 2026Robin Haberkorn1-1/+1
2025-12-28teco_string_t is now passed by value like a scalar if the callee isn't ↵Robin Haberkorn1-2/+2
expected to modify it * When passing a struct that should not be modified, I usually use a const pointer. * Strings however are small 2-word objects and they are often now already passed via separate `gchar*` and gsize parameters. So it is consistent to pass teco_string_t by value as well. A teco_string_t will usually fit into registers just like a pointer. * It's now obvious which function just _uses_ and which function _modifies_ a string. There is also no chance to pass a NULL pointer to those functions.
2025-12-26TECO_DEFINE_STATE() no longer constructs callback names for mandatory ↵Robin Haberkorn1-3/+6
callbacks, but tries to use static assertions * Requiring state callbacks by generating their names (e.g. NAME##_input) has several disadvantages: * The callback is not explicitly referenced when the state is defined. So an unintroduced reader will see some static function, which is nowhere referenced and still doesn't cause "unused" warnings. * You cannot choose the name of function that implements the callback freely. * In "substates" you need to generate a callback function if you want to provide a default. You also need to provide dummy wrapper functions whenever you want to reuse some existing function as the implementation. * Instead, we are now using static assertions to check whether certain callbacks have been implemented. Unfortunately, this does not work on all compilers. In particular GCC won't consider references to state objects fully constant (even though they are) and does not allow them in _Static_assert (G_STATIC_ASSERT). This could only be made to work in newer GCC with -std=c2x or -std=gnu23 in combination with constexpr. It does work on Clang, though. So I introduced TECO_ASSERT_SAFE() which also passes if the expression is *not* constant. These static assertions are not crucial - they do not check anything that can differ between systems. So we can always rely on the checks performed by FreeBSD CI for instance. Also, you will of course quickly notice missing callbacks at runtime - with and without additional runtime assertions. * All mandatory callbacks must still be explicitly initialized in the TECO_DEFINE_STATE calls. * After getting rid of generated callback implementations, the TECO_DEFINE_STATE macros can finally be qualified with `static`. * The TECO_DECLARE_STATE() macro has been removed. It no longer abstracts anything and cannot be used to declare static teco_state_t anyway. Also TECO_DEFINE_UNDO_CALL() also doesn't have a DECLARE counterpart.
2025-11-08the command line macro is now managed by a Scintilla viewRobin Haberkorn1-1/+1
* Instead of rendering a teco_string_t into a Scintilla view (GTK) and an ncurses window (Curses), it is now a Scintilla view and document that is modified directly. * Reduces redundancies between GTK and Curses UIs. * It will be more efficient on very large command lines, especially on GTK. * We can now redirect Scintilla messages to the command line view in order to configure syntax highlighting, the margin, rubout indicator style and scroll behavior (TODO). * This will also simplify the configuration of multi-line command lines (TODO). * Since INDIC_PLAIN is not supported by Scinterm, rubbed out command lines are now styled with INDIC_STRAIGHTBOX (background color).
2025-07-31implemented ^T command: allows typing by code and getting characters from ↵Robin Haberkorn1-1/+81
stdin or the user * n:^T always prints bytes (cf. :^A) * ^T without arguments returns a codepoint or byte from stdin. In interactive mode, this currentply places a cursor in the message line and waits for a keypress.
2025-07-28=/==/===: fixed detection of execution from the end of the command-lineRobin Haberkorn1-6/+29
In particular, fixes the test case `3<255=>` which would print only one number in interactive mode.
2025-07-26implemented the <T> (typeout) command for printing to the terminal from the ↵Robin Haberkorn1-0/+36
current buffer * refactored some code that is common with Xq into teco_get_range_args().
2025-07-26support <:^A> to force raw ANSI outputRobin Haberkorn1-3/+15
* ^A uses the default code page without colon, just like ^U/EU. This is usually UTF8, unless you run with --8bit. It would make just as little sense to inherit the codepage from the current document. * Ensures that code like `:^A^E<0xFF>^A` really outputs byte 0xFF. * DEC TECO doesn't have the colon modifier, but it has a colon modifier for ^T to enforce raw output. In SciTECO, the ^T vs. :^T distinction will also be between default codepage and ANSI. It makes sense because ^T should treat its numeric arguments like <I> for consistency.
2025-07-26support :=/:==/:=== commands: print number without trailing linefeedRobin Haberkorn1-19/+29
2025-07-26implemented the <^A> command for printing arbitrary stringsRobin Haberkorn1-4/+48
* Greatly improved usability as a scripting language. * The command is in DEC TECO, but in contrast to DEC TECO, we also support string building constructs in ^A. * Required some refactoring: As we want it to write everything verbatim to stdout, the per-interface method is now teco_interface_msg_literal() and it has to deal with unprintable characters. When displaying in the UI, we use teco_curses_format_str() and TecoGtkLabel functions/widgets to deal with possible control codes. * Numbers printed with `=` have to be written with a trailing linefeed, which would also be visible as a reverse "LF" in the UI. Not sure whether this is acceptable - the alternative would be to strip the strings before displaying them. * Messages written to stdout are also auto-flushed at the moment. In the future we might want to put flushing under control of the language. Perhaps :^A could inhibit the flushing.
2025-07-22refactored =/==/=== command into stdio-commands.cRobin Haberkorn1-0/+197
There will be a lot more commands for terminal/message input and output soon.