aboutsummaryrefslogtreecommitdiffhomepage
path: root/TODO
AgeCommit message (Collapse)AuthorFilesLines
2025-05-03updated TODORobin Haberkorn1-1/+43
2025-04-19updated ChangeLog and TODO for v2.4.0 releasev2.4.0Robin Haberkorn1-26/+77
* ChangeLogs now contain the dates of all releases. * The FreeBSD package must practically be updated after uploading the release tarball.
2025-03-29bumped target release to v2.4.0 and updated README and TODORobin Haberkorn1-30/+86
* Added a test case for the known bug of out-of-place modifiers. Well, this is a syntactic shortcoming rather than a true bug. But I did run into it more than once.
2025-03-03rename sample.teco_ini to fallback.teco_ini and mung it by defaultRobin Haberkorn1-7/+4
* After installation, SciTECO will therefore start into a more userfriendly mode even if the user does not create a custom ~/.teco_ini. It is hoped that this will scare away less of new users, who are not willing to read through all of the documentation. Still, users are warned in the absence of ~/.teco_ini. This warning however, might not be immediately visible, especially not when running gsciteco without an attached console. (This will change once I redo the UI and allow a number of messages to be queued in the message area.) * Theoretically, you could also just extend fallback.teco_ini from ~/.teco_ini, but that would require installing it into $SCITECOPATH. * Since the fallback profile will now be munged automatically on a wide range of systems, we set up xclip only when detecting X11 ($DISPLAY is non-empty). E.g. when running under Wayland or the Linux console, you still won't get the clipboard registers, which is probably better than having the clipboard operations fail once you try to use them. * xclip is now "suggested" on Debian/Ubuntu. Unfortunately we cannot pull it in only in the presence of X11.
2025-03-02GTK: always scroll caret when window size changesRobin Haberkorn1-3/+0
* The old implementation would scroll only once for the file first opened and too early. As a result, opening via `sciteco file:number` did not always scroll to the correct position. Also, `?` would usually not scroll the topic into view. * Instead, we now always scroll in all views, but only if the size allocation changed. This ensures, we can still scroll with the mouse wheel. * Therefore, we have to store the current size allocation per view. Instead of allocating a separate heap object, I decided to subclass the Scintilla GTK class. * Some explicit casts are still necessary since teco_view_t is typedefed to `struct teco_view_t`, but we cannot easily rename the GObject instance structure.
2025-03-02GTK: set the mouse cursor on the Scintilla view to signal business and on ↵Robin Haberkorn1-3/+1
the popup entries * By default, use the "text" cursor - this is the default Scintilla cursor, but inhibited by the GtkEventBox I used to catch all input events. * When processing input events, the cursor is changed to "wait". This is done with a small delay in order to avoid flickering during normal typing. The cursor is only changed after 100ms of activity, i.e. only when executing long loops or external programs. * We use the raw GSource API since it's tricky to work with source ids if the source could be removed in the meantime. * The popup entries' cursor is also changed to "pointer" (hand) to give a hint that it can be clicked.
2025-02-27implemented ncurses clipboard support via external processesRobin Haberkorn1-5/+0
* As an alternative to OSC-52, which is rarely supported by terminal emulators. * Makes the new mouse support much more useful since you rely on good builtin clipboard support. You can no longer e.g. just double-click a word to copy it into the "primary" selection as terminal emulators do by default. * Set $SCITECO_CLIPBOARD_SET/GET e.g. to xclip, way-copy, pbcopy or some wrapper script. * This is currently using POSIX-specific popen() API, so it behaves a bit different to command execution via EC/EG. I am not sure if it's worth rewriting with the GSpawn-API, since it will be used only on POSIX anyway and a GSpawn-based implementation is likely to be a bit larger. * Should there be some small command-line utility for interacting (esp. pasting) via OSC-52, built-in OSC-52 support could well be removed from SciTECO. Currently, I know only of https://github.com/theimpostor/osc/ and it requires very recent Go compilers. (I still haven't tested it. Quite possibly, pasting when run as a piped command is impossible.)
2025-02-24fixed rubbing out `?` (help) after editing a Q-RegisterRobin Haberkorn1-2/+3
* Test case: @EQa// @?/EX/ -- Rubout should return you to the Q-Register view. * The test suite has been extended. Unfortunately we cannot currently directly check whether we're editing a Q-Register. But we add a magic number of characters to the Q-Register, that we can check afterwards.
2025-02-23updated TODORobin Haberkorn1-11/+49
2025-01-19support :EF for saving a file before closing itRobin Haberkorn1-1/+0
Analoguous to :EX, but always saves the file like EW$, not only if it's dirty.
2025-01-13mention the Alpine package and updated TODORobin Haberkorn1-1/+11
2024-12-30support +line[,column] and filename:line:column syntaxes when opening filesRobin Haberkorn1-8/+0
* This is done via the new opener.tes in the standard library. * Some programs that use $EDITOR expect the +line syntax to work. * You can copy filename:line:column directly from GCC error messages and filename:line from grep output. * Since there may be safe file names beginning with "+" or containing colons, there needs to be a way to turn this off, especially for scripts that don't know anything about the filenames to open. This is done with "--". Unfortunately, the first "--", that stops parameter processing, is always removed from the command line and not passed down into TECO land. This is not a problem for stand-alone scripts, since the script filename is already stopping option processing, so "--" would get passed down. But when calling the profile via `sciteco -- ...`, you could prevent leading minus signs to cause problems but since the `--` is removed, opener.tes cannot use it as a hint. Therefore, we introduced `-S` as a new alternative to `--`, that's always passed down as `--` (i.e. it is equivalent to "-- --"). In other words, `sciteco -S *` will always open exactly the specified files without any danger of misinterpreting certain file names. Should we ever switch to a custom option parsing algorithm, we might preserve "--" (unless after --mung) and thus get rid of "-S". * This advanced behavior can be tweaked by the user relatively easily. In the easiest case, we could replace M[opener] with <:L;R 0X.f [* @EB/^EN.f/ ]* L> in ~/.teco_ini to completely disable the special syntax.
2024-12-27nightly builds now include 64-bit Windows builds (MINGW64)Robin Haberkorn1-2/+0
* 32-bit binaries have been dropped, even though we could build both. But there is virtually no demand for 64-bit binaries left. * I continue to build 32-bit versions during CI, so that at least something still builds and tests under 32-bit.
2024-12-25prepared v2.3.0 releasev2.3.0Robin Haberkorn1-4/+1
2024-12-24added AX_WITH_CURSES for more robust ncurses checksRobin Haberkorn1-0/+4
* Turns out that on SunOS/OmniOS the ncurses port does not ship with a ncursesw pkg-config file, but the ncurses file is for a version, that does contain widechar support as well. * Instead of adding yet another recursive PKG_CHECK_MODULES() call, we now use the AX_WITH_CURSES() macro, which is probably more robust. This should at least fix ./configure on OmniOS. * It also adds a number of feature C macros, that could be useful to check in the future. * At the moment, we strive to support all X/Open-compatible Curses libraries, but both enhanced and color functions are required. Therefore plain SVr4 Curses is not supported. * source: https://www.gnu.org/software/autoconf-archive/ax_with_curses.html
2024-12-24introduced true block and EOL commentsRobin Haberkorn1-4/+0
* The previous convention of !* ... *! are now true block comments, i.e. they are parsed faster, don't spam the goto table and allow embedding of exclamation marks - only "*!" terminates the comment. * It is therefore now forbidden to have goto labels beginning with "*". * Also support "!!" to introduce EOL comments (like C++'s //). This disallows empty labels, but they weren't useful anyway. This is the shortest way to begin a comment. * All comment labels have been converted to true comments, to ensure that syntax highlighting works correctly. EOL comments are used for single line commented-out code, since it's easiest to uncomment - you don't have to jump to the line end. This is a pure convention / coding style. Other people might do it differently. * It's of course still possible to abuse goto labels as comments as TECO did for ages. * In lexing / syntax highlighting, labels and comments are highlighted differently. * When syntax highlighting, a single "!" will first be highlighted as a label since it's not yet unambiguous. Once you type the second character (* or !), the first character is retroactively styled as a comment as well.
2024-12-23Curses: don't install PNG iconsRobin Haberkorn1-5/+0
* They are used at runtime only by the GTK port. * Their existence can cause problems if OS-specific build systems have to clean these files from the staging directory afterwards. This was the case on FreeBSD where the committer refused to remove these files after installation. In the official FreeBSD port, we therefore currently ship the PNG icons unnecessarily. * They are now installed and shipped only on GTK builds.
2024-12-22updated TODORobin Haberkorn1-17/+26
2024-12-13document the FK...$^SR idiomRobin Haberkorn1-1/+0
* We don't actually have to negate ^S results after FK. For deleting the matched pattern, you can use ^YD or -^SD.
2024-12-13implemented Scintilla lexer for SciTECO code, i.e. TECO syntax highlightingRobin Haberkorn1-5/+9
* this works by embedding the SciTECO parser and driving it always (exclusively) in parse-only mode. * A new teco_state_t::style determines the Scintilla style for any character accepted in the given state. * Therefore, the SciTECO lexer is always 100% exact and corresponds to the current SciTECO grammer - it does not have to be maintained separately. There are a few exceptions and tweaks, though. * The contents of curly-brace escapes (`@^Uq{...}`) are rendered as ordinary code using a separate parser instance. This can be disabled with the lexer.sciteco.macrodef property. Unfortunately, SciTECO does not currently allow setting lexer properties (FIXME). * Labels and comments are currently styled the same. This could change in the future once we introduce real comments. * Lexers are usually implemented in C++, but I did not want to draw in C++. Especially not since we'd have to include parser.h and other SciTECO headers, that really do not want to keep C++-compatible. Instead, the lexer is implemented "in the container". @ES/SCI_SETILEXER/sciteco/ is internally translated to SCI_SETILEXER(NULL) and we get Scintilla notifications when styling the view becomes necessary. This is then centrally forwarded to the teco_lexer_style() which uses the ordinary teco_view_ssm() API for styling. * Once the command line becomes a Scintilla view even on Curses, we can enabled syntax highlighting of the command line macro.
2024-12-09prepared v2.2.0 releasev2.2.0Robin Haberkorn1-30/+58
This release is mainly for the upcoming FreeBSD package.
2024-11-24added special Q-Register ":" for accessing dotRobin Haberkorn1-6/+2
* 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-23the search mode and current radix are mapped to __local__ Q-Registers ^X and ↵Robin Haberkorn1-11/+10
^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 Haberkorn1-4/+1
* 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-17updated TODO and ChangeLog for v2.1.1 releasev2.1.1Robin Haberkorn1-1/+9
2024-11-11session.tes: store the current tab style (width and hard-tabs); fixed for ↵Robin Haberkorn1-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 Haberkorn1-4/+0
* 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-10updated grosciteco.tes(1): mention new macros, changed command lines and ↵Robin Haberkorn1-0/+4
restrictions
2024-11-10updated TODORobin Haberkorn1-4/+23
2024-11-05fully support relocatable binaries, improving AppImagesRobin Haberkorn1-5/+0
* 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-10-29updated TODORobin Haberkorn1-9/+17
2024-10-28added hidden --fake-cmdline parameter for testing command-line editingRobin Haberkorn1-3/+0
* Supports all immediate editing commands. Naturally it cannot emulate arbitrary key presses since there is no canonic ASCII-encoding of function keys. Key macros are not consequently also not testable. The --fake-cmdline parameter is instead treated very similar to a key macro expansion. * Most importantly this allows adding test cases for rubout behavior and bugs that are quite common. * Added regression test cases for the last two rubout bugs. * It's not easy to pass control codes in command line arguments in a portable manner, so the test cases will often use { and }. Control codes could be used e.g. by defining variables like RUBOUT=`printf '\b'` and referencing them with ${RUBOUT}.
2024-10-21fixed some interruptions of <EC> on Win32Robin Haberkorn1-5/+2
* We now recreate the event loop with every call since it turned out that the idle watcher wouldn't be invoked after the event loop has been quit once. This at least fixes interruption of ECbash -c 'while true; do true; done'$. * Unfortunately, ECping -t 8.8.8.8$ still cannot be interrupted (unless you manually kill the process from the task manager).
2024-10-19<EC>: perhaps fixed race conditions and problems when creating and ↵Robin Haberkorn1-0/+1
terminating process groups on Win32 * Sometimes already the job assignment failed in CI builds. We now check whether the process is still alive before throwing an error. * We now set the JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE flag. This theoretically shouldn't be necessary when using TerminateJobObject(), but who knows.
2024-10-18updated Scinterm: italic and underline styles are now supported on CursesRobin Haberkorn1-3/+2
* For instance, when using the Solarized color scheme, comments will be in italics. * The underline style could also be supported in color.set, but currently it's not required. * Unfortunately, this does *not* fix the INDIC_PLAIN indicator style for underlining, so you still cannot use that eg. for spell checking. * See https://github.com/orbitalquark/scinterm/issues/22
2024-10-15updated TODORobin Haberkorn1-43/+91
2024-09-20^W^W and ^V^V can be typed completely with upcarets now and they case fold ↵Robin Haberkorn1-5/+0
all expansions of ^EQq, ^EUq and so on * Previously, there was no way to enter upper-case mode in interactive commands since the Ctrl+W immediate editing command is interpreted everywhere. * Without the case folding of ^EQq/^EUq results, the upper and lower case modes are actually pretty useless considering that modern keyboards have caps lock. So it was clear we need this, regardless of what the classic TECOs did. The TECO-11 manual is not very clear on this. tecoc apparently does not case-fold ^EQq results. * This opens up new idioms, for instance `EUq^W^W^EQq$` in order to upper case register q. It's also the only way you can currently upper-case Unicode codepoints.
2024-09-19Ctrl+^ is no longer translated to a single caret in string building (refs #20)Robin Haberkorn1-2/+0
* Ctrl+^ (30) and Caret+caret (^^) were both translated to a single caret. While there might be some reason to keep this behavior for double-caret, it is certainly pointless for Ctrl+^. * That gives you an easy way to insert Ctrl+^ (code 30) into documents with <I>. Perviously, you either had to insert a double-caret, typing 4 carets in a row, or you had to use <EI> or 30I$. * The special handling of double-caret could perhaps be abolished altogether, as we also have ^Q^ to escape plain carets. The double-caret syntax is very archaic from the time that there was no proper ^Q as far as I recall correctly.
2024-09-19"special" Q-Registers now support EQq/.../ (load) and E%q/.../ (save) commandsRobin Haberkorn1-2/+0
* @EQ$/.../ sets the current directory from the contents of the given file. @E%$/.../ stores the currend directory in the given file. * @EQ*/.../ will fail, just like ^U*...$. @E%*/.../ stores the current buffer's name in the given file. * It's especially useful with the clipboard registers. There could still be a minor bug in @E%~/.../ with regard to EOL normalization as teco_view_save() will use the EOL style of the current document, which may not be the style of the Q-Reg contents. Conversions can generally be avoided for these particular commands. But without teco_view_save() we'd have to care about save point creation.
2024-09-18check that local register is not edited at the end of macro callsRobin Haberkorn1-3/+0
* This was unsafe and could easily result in crashes, since teco_qreg_current would afterwards point to an already freed Q-Register. * Since automatically editing another register or buffer is not easy to do right, we throw an error instead.
2024-09-16updated TODORobin Haberkorn1-28/+55
2024-09-12update TODORobin Haberkorn1-23/+18
2024-09-11updated TODORobin Haberkorn1-11/+19
2024-09-09updated TODORobin Haberkorn1-10/+48
2024-09-09prefer libncursesw (widechar variant) (refs #5)Robin Haberkorn1-2/+2
* Some platforms like Ubuntu actually ship widechar and non-widechar versions of ncurses with different pkg-config files. Other platforms like FreeBSD will ship an "ncursesw" and "ncurses" pkg-config file but both point to the same wide-char library anyway. * Currently we are not using wide-char APIs to ensure maximum compatibility even with embedded systems where ncurses might be built without widechar support. But in order to handle Unicode correctly, we still need to link against the widechar version of ncurses (if available). * Compilation on platforms without a widechar ncurses is now handled by the common AC_CHECK_LIB() fallback (which might actually find a widechar version anyway if it just didn't install the pkg-config file). If necessary, we could also check for the "ncurses" package if "ncursesw" is not found. * This fixes Unicode display and input on Ubuntu.
2024-08-23fully support out of tree buildsRobin Haberkorn1-3/+0
* You no longer have to copy contrib/scintilla, contrib/scinterm and contrib/lexilla manually to the build directory. * It turns out, that Scintilla/Lexilla was supporting this since 2016. Scintilla allows pointing to a source directory (srdir) and Lexilla to a binary directory (DIR_O). * For Scinterm I opened a pull request in order to add srcdir/basedir variables: https://github.com/orbitalquark/scinterm/pull/21 * `make distcheck` is therefore now also fixed. * The FreeBSD package is now allowed to build out of source. I haven't tested it yet. * See also https://github.com/ScintillaOrg/lexilla/issues/266
2024-08-22some updates on Scintilla/Lexilla out-of-tree buildsRobin Haberkorn1-0/+4
2024-08-21Curses UI: fixed drawing of boxed indicatorsRobin Haberkorn1-4/+1
* The scinterm submodule temporarily points to my own fork. * This is necessary for the aspell macro on Curses. See https://github.com/rhaberkorn/sciteco/wiki/Useful-Macros#spell-checker * See also https://github.com/orbitalquark/scinterm/pull/19
2024-08-18added troff/nroff lexerRobin Haberkorn1-1/+0
* This is optimized for Groff, but works for Heirloom Troff and Neatroff as well. Currently, the Heirloom and Neatroff requests are just added ontop of the Groff ones. Theoretically, we could also try to separate the keyword lists into a base K&R set with Groff, Heirloom and Neatroff ontop. * The lexer necessarily has many restrictions, as Troff is fundamentally unparseable (like classic TECO) and needs a lot of per-request knowledge. * The "*.mm" extension has been removed from the lexers/cpp.tes. I don't know what language this was for, and I prefer `*.mm` files to be considered Troff. * Temporarily changed the lexilla submodule URL. The corresponding Lexila lexer is in the process of being upstreamed. Once it is, I will probably revert the submodule to the official repository, as the "troff" branch is not stable (can be rebased).
2024-05-22build and upload AppImages as part of nightly buildsRobin Haberkorn1-1/+4