aboutsummaryrefslogtreecommitdiffhomepage
AgeCommit message (Collapse)AuthorFilesLines
2024-12-09prepared v2.2.0 releasev2.2.0Robin Haberkorn3-31/+107
This release is mainly for the upcoming FreeBSD package.
2024-12-08fixed rubbing out file open with glob patternsRobin Haberkorn1-5/+4
* This would crash if <EB> opened more than one file, e.g. EB*.c$. The reason is that teco_current_doc_undo_edit() must be called before every teco_ring_edit(). * Unfortunately, this is not reproduceable with sciteco --no-profile --fake-cmdline '@EB"foo*.txt"{HK}' since the crashes actually happen when printing messages in interactive mode. That's why no test case has been added.
2024-12-08implemented the ^Q command for converting between line and glyph positionsRobin Haberkorn4-7/+76
* As known from DEC TECO, but extended to convert absolute positions to line numbers as well. :^Q returns the current line. * Especially useful in macros that accept line arguments, as it is much shorter than something like ^E@ES/LINEFROMPOSITION//+Q.l@ES/POSITIONFROMLINE//:^E-. * On the other hand, the fact that ^Q checks the line range means we cannot easily replace lexer.checkheader with something like [:J 0,^Q::S...$ ]: Using SCI_POSITIONFROMLINE still has the advantage that it returns `Z` for out-of-bounds ranges which would be cumbersome to write with the current ^Q. * Perhaps there should be a separate command for converting between absolute lines and positions and :^Q should be repurposed to return a failure boolean for out-of-range values? * fnkeys.tes could be simplified.
2024-12-06support the ::S anchored search (string comparison) command (and ::FD, ::FR, ↵Robin Haberkorn15-72/+130
::FS as well) * The colon modifier can now occur 2 times. Specifying `@` more than once or `:` more than twice is an error now. * Commands do not check for excess colon modifiers - almost every command would have to check it. Instead, a double colon will simply behave like a single colon on most commands. * All search commands inherit the anchored semantics, but it's not very useful in some combinations like -::S, ::N or ::FK. That's why the `::` variants are not documented everywhere. * The lexer.checkheader macro could be simplified and should also be faster now, speeding up startup. Eventually this macro can be made superfluous, e.g. by using 1:FB or 0,1^Q::S.
2024-12-05nightly builds: use Mac OS 13 instead of the deprecated version 12Robin Haberkorn1-1/+1
* 13 is now the oldest supported version
2024-12-05updated NEWS: mention the chatroom pollRobin Haberkorn1-2/+2
2024-12-04use the new ^Y, ^S and @Xq commands in tedoc.tes and string.tesRobin Haberkorn2-7/+7
2024-12-04the <Xq> command now supports the @ modifier for cutting into the registerRobin Haberkorn6-12/+79
* Can be freely combined with the colon-modifier as well. :@Xq cut-appends to register q. * This simply deletes the given buffer range after the copy or append operation as if followed by another <K> command. * This has indeed been a very annoying missing feature, as you often have to retype the range for a K or D command. At the same time, this cannot be reasonably solved with a macro since macros do not accept Q-Register arguments -- so we would have to restrict ourselves to one or a few selected registers. I was also considering to solve this with a special stack operation that duplicates the top values, so that Xq leaves arguments for K, but this couldn't work for cutting lines and would also be longer to type. * It's the first non-string command that accepts @. Others may follow in the future. We're approaching ITS TECO madness levels.
2024-12-04implemented ^Y/^S commands for receiving pattern match/insertion ranges and ↵Robin Haberkorn8-25/+224
lengths (refs #27) * Allows storing pattern matches into Q-Registers (^YXq). * You can also refer to subpatterns marked by ^E[...] by passing a number > 0. This is equivalent to \0-9 references in many programming languages. * It's especially useful for supporting TECO's equivalent of structural regular expressions. This will be done with additional macros. * You can also simply back up to the beginning of an insertion or search. So I...$^SC leaves dot at the beginning of the insertion. S...$^SC leaves dot before the found pattern. This has been previously requested by users. * Perhaps there should be ^Y string building characters as well to backreference in search-replacement commands (TODO). This means that the search commands would have to store the matched text itself in teco_range_t structures since FR deletes the matched text before processing the replacement string. It could also be made into a FR/FS-specific construct, so we don't fetch the substrings unnecessarily. * This differs from DEC TECO in always returning the same range even after dot movements, since we are storing start/end byte positions instead of only the length. Also DEC TECO does not support fetching subpattern ranges.
2024-11-30sciteco(7): fixed outdated information about the STYLE_CALLTIP default colorsRobin Haberkorn1-3/+3
2024-11-30updated Scinterm to the official v5.2 releaseRobin Haberkorn1-0/+0
This does not change anything functionally.
2024-11-25fixed operator precedence application (fixup ↵Robin Haberkorn2-7/+12
5597bc72671d0128e6f0dba446c4dc8d47bf37d0) * Using teco_expressions_eval() is wrong since it does not pay attention to precedences. If you have multiple higher precedence operators in a row, as in 2+3*4*5, the lower precedence operators would be resolved prematurely. * Instead we now call teco_expressions_calc() repeatedly but only for lower precedence operators on the stack top. This makes sure that as much of the expression as possible is evaluated at any given moment.
2024-11-25avoid dynamic stack allocation in teco_expressions_brace_return()Robin Haberkorn1-4/+1
* This is not safe since the size of the stack object comes from the "outside" world, so stack overflows can theoretically be provoked by macros.
2024-11-25fixed subtle operator precedence bugRobin Haberkorn2-1/+7
* It was possible to provoke operator right-associativity when placing a high-precedence operator between two low-precedence operators. 1-6*5-1 evaluated to -28 instead of the expected -30. * The reason is that SciTECO relies on operators to be resolved from left-to-right as soon as possible. The higher precedence operator prevents that and pushing the 2nd "-" only evaluated 6*5. At the end 1-30-1 would be left on the stack. teco_expressions_eval() however evaluates from right-to-left which is wrong in this case. * Instead, we now do a full eval on every operator with a lower precedence, making sure that 1-30 is evaluated first.
2024-11-24sciteco(7): minor documentation fixRobin Haberkorn1-1/+1
2024-11-24lexer.auto: use case-sensitive searchesRobin Haberkorn1-0/+0
* lexer.checkheader is therefore case-sensitive now as well
2024-11-24added special Q-Register ":" for accessing dotRobin Haberkorn9-15/+76
* We cannot call it "." since that introduces a local register and we don't want to add an unnecessary syntactic exception. * Allows the idiom [: ... ]: to temporarily move around. Also, you can now write ^E\: without having to store dot in a register first. * In the future we might add an ^E register as well for byte offsets. However, there are much fewer useful applications. * Of course, you can now also write nU: instead of nJ, Q: instead of "." and n%: instead of "nC.". However it's all not really useful.
2024-11-24minor documentation changes: use typographic quotes instead of "Robin Haberkorn2-3/+3
2024-11-23string building: ^c (caret+c) does no longer expand to data garbage for ↵Robin Haberkorn1-0/+9
non-control characters, but to the literal caret, followed by c * For instance `^$` would insert two characters. * The alternative would have been to throw an error.
2024-11-23disallow setting the radix to values lower than 2Robin Haberkorn3-8/+34
* This would actually causes crashes when trying to format numbers. * The ^R local register has a custom set_integer() method now, so that the check is performed also when using nU.^X.
2024-11-23the search mode and current radix are mapped to __local__ Q-Registers ^X and ↵Robin Haberkorn12-56/+185
^R now (refs #17) * This way the search mode and radix are local to the current macro frame, unless the macro was invoked with :Mq. If colon-modified, you can reproduce the same effect by calling [.^X 0^X ... ].^X * The radix register is cached in the Q-Reg table as an optimization. This could be done with the other "special" registers as well, but at the cost of larger stack frames. * In order to allow constructs like [.^X typed with upcarets, the Q-Register specification syntax has been extended: ^c is the corresponding control code instead of the register "^".
2024-11-23implemented search mode flag (^X): allow case-sensitive searches (closes #17)Robin Haberkorn5-6/+41
* Usually you will only want -^X for enabling case sensitive searches and 0^X for case-insensitive searches (which is also the default). * An open question is what happens if the user sets -^X and then calls a macro. The search mode flag should probably be stacked away along with the search-string. This means we'd need a ^X special Q-Reg as well, so you can write [^X[_ 0^X S...$ ]_]^X. Alternatively, the search mode flag should be a property of the macro frame, along with the radix.
2024-11-19minor documentation fixesRobin Haberkorn2-3/+5
* also explicitly mention -%q
2024-11-18fixed some common typos: "ie." and "eg.", "ocur" instead of "occur"Robin Haberkorn14-36/+36
2024-11-18Debian/Ubuntu, FreeBSD and website updates for v2.1.1 releaseRobin Haberkorn4-5/+11
2024-11-17updated TODO and ChangeLog for v2.1.1 releasev2.1.1Robin Haberkorn2-1/+62
2024-11-11session.tes: store the current tab style (width and hard-tabs); fixed for ↵Robin Haberkorn2-0/+5
filenames containing ASCII 27 * You can now set a per-file tab style, that differs from the defaults established in the ED hook. This is important especially since we do not yet support per-project .teco_ini scripts where you could establish differing policies depending on the VCS repository. (The latter would be easy to implement, but we cannot currently easily extend the existing ED hooks.) * It's unlikely that files contain an ASCII 27, but not impossible. Therefore we now use ASCII 0 (^@) as a terminator. This indeed be safe under UNIX. Even better would be a string building construct for escaping ASCII 27 ($), though, as that would work with arbitrary bytes.
2024-11-10Win32: fixed Unicode commandlines with newer MinGW runtimesRobin Haberkorn3-5/+18
* should also fix Win32 nightly builds * Even though we weren't using main's argv, but were using glib API for retrieving the command line in UTF-8, newer MinGW runtimes would fail when converting the Unicode command line into the system codepage would be lossy. * Most people seem to compile in a "manifest" to work around this issue. But this requires newer Windows versions and using some Microsoft tool which isn't even in $PATH. Instead, we now link with -municode and define wmain() instead, even though we still ignore argv. wmain() proabably get's the command line in UTF-16 and we'd have to convert it anyway. * See https://github.com/msys2/MINGW-packages/issues/22462
2024-11-10fixed installation with absolute "scitecodatadir" (ie. if building ↵Robin Haberkorn1-2/+2
non-relocatable binary) * This was accidentally installing into $bindir/usr (usually /usr/local/bin/usr/...) You might want to check whether SciTECO accidentally installed something there.
2024-11-10changed target release to v2.1.1Robin Haberkorn1-1/+1
The next release will include almost exclusively bug fixes.
2024-11-10updated grosciteco.tes(1): mention new macros, changed command lines and ↵Robin Haberkorn2-1/+19
restrictions
2024-11-10updated TODORobin Haberkorn2-4/+24
2024-11-10grosciteco: basic support for GNU pic graphicsRobin Haberkorn1-26/+52
* The line drawing algorithm currently works only with tbl, though. * Also only straight lines are currently supported. * This was meant for rendering presentations in SciTECO - it's not currently used or planned to be used in the manpages. Although we might well add pic graphics to the manpages in the future.
2024-11-10grosciteco: support .SCITECO_STARTSTYLING and .SCITECO_SETSTYLING macrosRobin Haberkorn2-1/+21
This could theoretically be used to apply Scintilla styles not natively and easily supported by grosciteco, eg. different fonts and font sizes.
2024-11-10grosciteco: added some more quote glyphsRobin Haberkorn1-0/+2
2024-11-07if a macro ends without finding a goto label, always throw a 'Label "..." ↵Robin Haberkorn1-7/+7
not found' error * This is important with gotos in loops as in <@O/x/> where, we would otherwise get a confusing "Unterminated loop" error. * This in particular fixes the error thrown in grosciteco.tes when encountering a new unknown command.
2024-11-07grosciteco: fixed the CuXXXX postprocessor command, ie. insertion of ↵Robin Haberkorn1-1/+1
characters by unicode, ie. typesetting of most non-latin text * This was broken at least for characters that happened to contain hexadecimal digits > 9 since "D does not detect hexadecimal digits.
2024-11-07grosciteco: fixed styling of multi-byte text (ie. non-latin characters)Robin Haberkorn1-1/+1
* We just passed the length in glyphs to SCI_SETSTYLING.
2024-11-07test suite: fixed failure detection in the commandline-editing test casesRobin Haberkorn3-3/+17
* The program exit code will usually not signal failures since they are caught earlier. * Therefore, we always have to capture and check stderr.
2024-11-06fixed the Q-Reg spec machine used for implementing S^EGq$ (match one of ↵Robin Haberkorn4-21/+33
characters in Q-Register) * It was initialized only once, so it could inherit the wrong local Q-Register table. A test case has been added for this particular bug. * Also, if starting from the profile (batch mode), the state machine could be initialized without undo, which then later cause problems on rubout in interactive mode. For instance, if S^EG[a] fails and you would repeatedly type `]`, the Q-Reg name could grow indefinitely. There were probably other issues as well. Even crashes should have been possible, although I couldn't reproduce them. * Since the state machine is required only for the pattern to regexp translation and is performed anew for every character in interactive mode, we now create a fresh state machine for every call and don't attempt any undo. There might be more efficient ways, like reusing the string building's Q-Reg parser state machine.
2024-11-06fixed possible crashes during --fake-cmdlineRobin Haberkorn2-4/+6
* A test case has been added, although it might have been accidental that on caused crashes.
2024-11-05fixup: fixed Windows buildsRobin Haberkorn1-1/+1
2024-11-05fully support relocatable binaries, improving AppImagesRobin Haberkorn11-64/+153
* You can now specify `--with-scitecodatadir` as a relative path, that will be interpreted relative to the binary's location. * Win32 binaries already were relocatable, but this was a Windows-specific hack. Win32 binaries are now built with `--with-scitecodatadir=.` since everything is in a single directory. * Ubuntu packages are now also built `--with-scitecodatadir=../share/sciteco`. This is not crucial for ordinary installations, but is meant for AppImage creation. * Since AppImages are now built from relocatable packages, we no longer need the unionfs-workaround from pkg2appimage. This should fix the strange root contents when autocompleting in AppImage builds. * This might also fix the appimage.github.io CI issues. I assume that because I could reproduce the issue on FreeBSD's Linuxulator in dependence of pkg2appimage's "union"-setting. See https://github.com/AppImage/appimage.github.io/pull/3402 * Determining the binary location actually turned out be hard and very platform-dependant. There are now implementations for Windows (which could also read argv[0]), Linux and generic UNIX (which works on FreeBSD, but I am not sure about the others). I believe this could also be useful on Mac OS to create app bundles, but this needs to be tested - currently the Mac OS binaries are installed into fixed locations and don't use relocation.
2024-11-04monkey-test.apl: avoid some bogus failures due to insufficient handling of ↵Robin Haberkorn2-6/+6
the pclose() return value
2024-11-03fixed assertions in ^EGq search construct for Q-Registers with uninitialized ↵Robin Haberkorn2-1/+6
string cells Found thanks to the "infinite monkey" test.
2024-11-03Added "infinite monkey"-style test (refs #26)Robin Haberkorn6-0/+129
Supposing that any monkey hitting keys on a typewriter, serving as a hardcopy SciTECO terminal, will sooner or later trigger bugs and crash the application, the new monkey-test.apl script emulates such a monkey. In fact it's a bit more elaborate as the generated macro follows the frequency distribution extracted from the corpus of SciTECO macro files (via monkey-parse.apl). This it is hoped, increases the chance to get into "interesting" parser states. This also adds a new hidden --sandbox argument, but it works only on FreeBSD (via Capsicum) so far. In sandbox mode, we cannot open any file or execute external commands. It is made sure, that SciTECO cannot assert in sandbox mode for scripts that would run without --sandbox, since assertions are the kind of things we would like to detect. SciTECO must be sandboxed during "infinite monkey" tests, so it cannot accidentally do any harm on the system running the tests. All macros in sandbox mode must currently be passed via --eval. Alternatively, we could add a test compilation unit and generate the test data directly in memory via C code. The new scripts are written in GNU APL 1.9 and will probably work only under FreeBSD. These scripts are not meant to be run by everyone.
2024-10-30CI: disabled Valgrind altogetherRobin Haberkorn1-2/+2
* Apparently it's not possible to run it as part of CI.
2024-10-30CI: Valgrind does not work in the Ubuntu runners, so let's try it under Mac OSRobin Haberkorn1-4/+4
2024-10-30fixup: make sure the correct PCs, pointing directly at the command that ↵Robin Haberkorn1-2/+7
failed, get assigned to error frames
2024-10-30fixed invalid memory access when executing the F< command (but only when ↵Robin Haberkorn3-6/+6
jumping to the beginning of the macro) * I am not sure whether this feature is really that useful... * teco_machine_main_t::macro_pc is now pointing to the __next__ character to execute, therefore it's easier to manipulate by flow control commands. Also, it can now be unsigned (gsize) like all other program counters. * Detected thanks to running the testsuite under Valgrind.