| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
in Windows-only code as well
|
|
|
|
in doc/
* When fixing up hash-bang lines, `::FS` returns a status integer, which was returned by the process
* also avoid expanding Make variables into TECO code - better pass it as a command-line argument
* should also fix OBS builds
|
|
|
|
|
|
The latter is apparently frowned upon.
This will hopefully get the v2.5.0 release into ports quicker.
|
|
* hash-bang lines in grosciteco.tes and tedoc.tes are fixed up
at build time instead of install-time (via install-exec-hook).
* This will hopefully resolve problems with the FreeBSD port,
since Poudriere installs the package as non-root but with BINMODE=555.
The alternative would have been to set BINMODE=755 in the port which may not
be acceptible by the official port committer.
Anyway, I decided to go out of the way of any conflicts.
See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?format=multiple&id=283601
* On the downside, this will break install-path overrides at install-time
(e.g. `make install bindir=...`).
|
|
It causes build failures on OBS for several Linux distributions.
It generally works on Linux, so it's probably related to Xvfb.
|
|
Hopefully fixes the OBS build errors.
|
|
This is useful to launch from a terminal without "blocking" this terminal.
There are tools like nohup and daemonize (BSD) to do the same, but having it
builtin is shorter to write.
|
|
|
|
* After the last commit 0b593eb7d0e6907b19cdbb605caf1becae351004
we tried to clean up (unlink) recovery files for all dirty buffers.
This resulted in superfluous file deletions before any recovery
file was dumped; after disabling file recovery and even in
batch mode.
It's not tolerable that SciTECO scripts try to unlink files
as a side effect e.g. of EW.
Also, sometimes you may have to clean up recovery dumps even
in batch mode, e.g. in Quit hooks.
* Also, it was broken for dirty unnamed buffers, which would
cause glib errors.
* That's why we had to add another buffer state for
dirty files with outdated recovery dumps (TECO_BUFFER_DIRTY_OUTDATED_DUMP).
Once a dump was written, a buffer never directly transitions
into the TECO_BUFFER_DIRTY_NO_DUMP state again.
We can now reliably unlink() only where we'd expect a
recovery file to exist in the first place.
|
|
* It was possible to provoke left-over recovery files even if the editor does *not* crash:
1. If you dirtified the buffer (state = TECO_BUFFER_DIRTY), it would be dumped to a
recovery file (TECO_BUFFER_DIRTY_DUMPED).
2. If you dirtify the buffer again, the state will become TECO_BUFFER_DIRTY again,
so it's up for dumping in the next cycle.
3. If you now save and exit (e.g. `:EX`) the recovery file is not deleted since
the state is not TECO_BUFFER_DIRTY_DUMPED.
* A buffer can have a recovery file both for TECO_BUFFER_DIRTY and TECO_BUFFER_DIRTY_DUMPED,
so we must clean up afterwards in both states.
* Of course, it may __not__ yet have a recovery file in the TECO_BUFFER_DIRTY state.
The g_unlink() might therefore be superfluous on those files.
Moreover, if you disable recovery files, SciTECO will now still try to unlink the
recovery file.
These operations could only be avoided by adding yet another state, e.g.
TECO_BUFFER_DIRTY_OUTDATED_DUMP, so that after the first dump you will never switch
back into TECO_BUFFER_DIRTY.
|
|
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.
|
|
* This is still rendered as underlined text.
* It uses a new Scinterm upstream feature, so we can
switch back to the upstream repo.
|
|
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.
|
|
This made problems in teco_state_replace_default_insert, where we had to
override the done_cb.
Perhaps we should avoid all generated callback names (ie. mandatory
callback implementations)?
|
|
It was returning the range of the search, but not of the inserted text.
Since the searched text is deleted, the range of the insertion is more useful.
It's also what was documented and what DEC TECO does.
|
|
* When constructing the list of popup items, the unnamed buffer is stored as the empty string
instead of a prerendered "(Unnamed)".
Using the empty string simplifies autocompletions, which will actually have to insert nothing
at all (in addition to terminating the string).
* Since unnamed buffers are now special in the popup list, we can render them with special
icons as well.
Currently, only on Curses we use a file symbol with a question mark.
There doesn't appear to be a fitting standard Freedesktop icon to use on GTK and there
isn't even any fitting standard emblem to lay over the default file icon.
|
|
* Other editors call "backup files" previous copies of saved files.
This role would be served by savepoint files in SciTECO.
* Likewise filename~ would point to such a backup file.
It therefore makes sense that savepoint files also end in tildes (.teco-n-filename~).
* Security copies of modified buffers would be called "auto-saves" (Emacs) or
"swap files" (Vim).
Both of these terms is IMHO misleading, so SciTECO now uses the
term "recovery file".
* "Recovery files" are now named #filename# just like in Emacs.
|
|
* It emits undo tokens which would bring internal datastructures - especially the undo stack -
out of sync.
* We now document that teco_view_save_to_channel() will always be without undo token emission.
|
|
* The backup mechanism is supposed to guard against crashes of SciTECO and
unexpected program terminations (e.g. power cycling, etc.)
* In a given interval (no matter whether busy or idlying on the prompt)
SciTECO saves all modified buffers with the filename~ (like most other editors).
As an optimization files are not backed up if they have been backed up
previously to avoid pointless and possibly slow file system writes.
* While the backup mechanism exists outside of the usual undo-paradigm -
backup file creating is not bound to character input and it makes no sense
to restore the exact state of backup files - there are some interesting
interactions:
* When a buffer is dirtyfied or saved that was previously backed up, it must always
be reset to the DIRTY state on rubout, so backups are eventually recreated.
* When a buffer is dirtyfied first (was clean), the backup file must be
removed on rubout as well - we don't expect backup files for clean buffers.
* There is currently no automatic way to restore backup files.
This could potentially be done by opener.tes and session.tes in the future,
although you couldn't currently always get meaningful user feedback
(whether he wants to restore the file).
Perhaps we should at least log a message when detecting backup files that
are newer than the file that is being opened.
|
|
* FILENAME_MAX is a standard C macro, but it may be arbitrarily long on some platforms
(like the popular GNU/Hurd). See:
https://www.gnu.org/software/libc/manual/html_node/Limits-for-Files.html#index-FILENAME_005fMAX
* This means there is no portable macro for the maximum path length.
You could perhaps define PATH_MAX to MAX_PATH on Windows.
* Instead, we use g_strdup_printf() to calculate the save point name.
We avoid another g_build_filename() by prepending the directory in the printf().
|
|
operators
* For consistency with other lexers, like the C/C++ lexer.
* `^*`, `^/` and `^#` are also true operators and shouldn't be styled
as regular commands.
This required introducing a new operator style (3).
|
|
* teco_file_get_absolute_path() does not currently guarantee to resolve
non-existent parts of the path.
When opening a symbolic link to a non-existing file, it would only
be created when writing out the file.
The undo token to remove it, however would remove the original
unresolved path.
When rubbing out the EW, the symlink would get removed instead
of the newly written file.
* We now resolve/canonicalize the path again immediately after
opening the new file, which should ensure that it resolves.
* As an alternative, we might have also tried to reliably canonicalize
non-existent symlinks. This however is tricky and there would have
to be a break condition to guard against cyclic symlinke.
In the end there is no guarantee to be able to resolve a path
exactly like the OS does.
Therefore, teco_file_get_absolute_path() was not touched,
not even on UNIX.
* A test case was not added since it would rely on creating real symlinks.
It wouldn't work on MSYS when `ln -s` falls back to hardlinks.
Perhaps other non-UNIX platforms would have similar restrictions.
|
|
We cannot rely on the central teco_cmdline_update() call per keypress
in this case.
The analogous call was removed in 4e6ddd6c329d56055a732c6344df019f0d997aaf,
so this was a recent regression.
|
|
* color.target is yellow in terminal.tes which looks awful and it should be
used sparingly.
The largest part of text in any lexer should be in the default colors.
* bash.tes now discerns between double and single quote strings like most lexers.
* autodetect GNUmakefiles
* yaml.tes now uses color.string for keys - this is for consistency with JSON
where keys will also always be strings.
|
|
|
|
* grosciteco.tes generates two output files.
First this was modeled with `%.woman %.woman.tec : ...`, but it creates independant rules
which could result in superfluous builds and broke parallel builds.
Then I tried grouped targets (`%.woman %.woman.tec &: ...`) which were supposed to solve the
problem cleanly. However they turned out to be buggy with pattern rules,
so I used templates instead.
Unfortunately grouped targets turned out to be unreliable in general and that broke
some older platforms, resulting in broken .woman.tec files.
* The same can be achieved by declaring .woman files the main artifact and
having an empty rule like `%.woman.tec : %.woman;`.
If anything draws in .woman.tec, it will still execute the rule only once.
|
|
|
|
|
|
rendered as "TAB" without any indentation
|
|
It does not change anything functionally, though.
|
|
0x404040 (COLOR_LBLACK) is a poor choice since on terminal emulators
with less than 16 colors, it would be rendered in black (and thus be invisible).
|
|
replacement ({...})
* The line end type and tab mode is apparently a property of the document.
Therefore it was lost when exchanging the command line's document during command line replacement.
* Instead, the old command line is now stored in a string.
* During replacement we delete and append only the part of the command line that changed.
This ensures that we don't have to restyle the entire command line with every single
replacement (even if it is at the end of the command line).
|
|
The new wcwidth.c wasn't actually linked in.
|
|
This requires enhanced INDIC_STRAIGHTBOX semantics, which are not yet upstream in Scinterm.
|
|
* This currently needs a yet unmerged patch, fixing the light colors.
* Scinterm no longer systematically initializes the color pairs, so
we cannot predict their numbers - instead we initialize color pairs
on demand and store them in a hash map, very similar to what Scinterm
does internally.
* Scinterm v5.5 can use arbitrary RGB colors now by automatically
allocating curses colors and pairs.
We do not expose this in SciTECO yet, although that would also
be possible.
It has to be decided first whether the special predefined colors
will continue to live in the same namespace along with "true"
RGB colors.
|
|
This was broken if you configured a command line with a height > 1.
|
|
SC_LINE_END_TYPE_NONE
|
|
fmsbw.de CI runner"
This reverts commit 092f7d9919d9572219b7bf516933c37180e6f400.
Turns out that the "Memory limiting" test cases won't even successfully run on my PC under Valgrind.
|
|
|
|
* This allows for several customizations.
* You can simply increase the visible command line history.
For that you must also set SCI_SETWRAPMODE(SC_WRAP_CHAR).
An example was added to fallback.teco_ini.
* You could also set SCI_SETLINEENDTYPESALLOWED(SC_LINE_END_TYPE_DEFAULT)
to see the structure of inserted text.
* Alternatively we could have introduced a new command like EP or FW
and also overload it to replace the current ED&2048 (e.g. -EP and EP).
In DEC TECO `W` comes closest to what 5EJ now does.
|
|
the current line as well
* This optimization is unnecessary for regular TECO scripts unless you write stupendously long lines.
On the command line macro however, we were always restyling the entire command line with every insertion
or rubout since the command line view uses single line mode by default.
Even if you enable a multi-line command line with regular line breaks, it's unlikely that you would insert
many line breaks except when inserting text into the buffer.
* We will now during insertion into the command line view style from the beginning of the last regular
command.
* During rub out from the command line, we still won't have enough information about where the previous
valid start state was, so we will frequently have to restyle the entire command line.
This might be worked around by adding a cmdline-view-specific hack if it turns out to be relevant
on very long command lines and slow computers.
|
|
These are equivalent, but LINES and COLS are shorter.
|
|
enables syntax highlighting on the command line
* M[lexer.set.cmdline] can be used to set up syntax highlighting on the command line
(if desired).
* Color schemes with light-dark themes (solarized.tes) are now responsible
to update the command line view as well.
|
|
* 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).
|
|
* This requires the new SCI_SETTABDRAWMODE(SCTD_CONTROLCHAR).
* It makes no sense to let TAB indent in TECO code as it can be
the insert-with-tab command (^I).
On the other hand large `I`-blocks could include TABs which are
actually meant as indentations.
|
|
This simplifies teco_interface_cmdline_update() and prepares for backing the
command line macro itself with a Scintilla view (teco_view_t).
The latter will avoid unnecessary recalculations when inserting characters
into the command line and to factor out redundancies with the Curses UI.
|
|
* It was failing on OpenSUSE Tumbleweed i586 on OBS,
resulting in duplicate symbols and build errors.
This was not reproducible with 32-bit builds on OpenSUSE Tumbleweed x86_64.
* Instead of hoping for a compiler warning to be treated as an error,
we now use a static assertion with a _Generic expression.
* The scintilla submodule has also been updated since Neil was asking to
update the documentation as well.
|
