| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* 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.
|
|
* 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.
|
|
|
|
|
|
* In contrast to the old Github workflow, we can no longer create pkgs,
but instead create tar balls. You don't necessarily have to unpack
it into the root, though, since the binaries are relocatable.
* We cannot execute the resulting binaries, so the testsuite is no
longer run under OS X. It could be executed with Darling, but only
under Linux.
* Resulting binaries are currently apparently fully statically linked.
|
|
* The Knowledge Base replaces the Github wiki.
* The mailing lists replace the Github bug tracker, discussions and pull requests.
|
|
* The new official homepage is https://sciteco.fmsbw.de/
* My new contact address is rhaberkorn AT fmsbw.de.
* The scintilla-mirror is now also on https://git.fmsbw.de/scintilla-mirror/
* Added CI script for my server on fmsbw.de that builds
the website.
It's run in a FreeBSD container, but does not currently
distribute FreeBSD binaries.
|
|
|
|
* It requires a forced refresh on startup (even though that should be the
default). Otherwise, it wouldn't print the info line correctly.
* Redirect stdin and pass it to newterm() to fix key queuing.
Probably necessary for supporting ncurses on NetBSD as well.
* Avoid doupdate() if screen is too small: fixes crashes for very
small windows.
* Updated Scintilla: There were some implicit typing assumptions,
that are broken by this platform.
|
|
Esp. mention the new OBS repositories.
|
|
* Since OBS has its own VCS, there is no need to add the sciteco.spec
to this repository.
It's located here:
https://build.opensuse.org/projects/home:rhaberkorn:sciteco:STABLE/packages/sciteco/files/sciteco.spec
* We will probably provide nightly builds via the UNSTABLE subproject as well.
* Perhaps OBS will even be used to build Debian packages,
as PPA only works on Ubuntu.
Also it has a webinterface for downloading the binary packages, so these
could be removed from our nightly CI workflows.
|
|
* In principle --stdin and --stdout could have been done in pure TECO code using the
<^T> command.
Having built-in command-line arguments however has several advantages:
* Significantly faster than reading byte-wise with ^T.
* Performs EOL normalization unless specifying --8bit of course.
* Significantly shortens command-lines.
`sciteco -qio` and `sciteco -qi` can be real replacements for sed and awk.
* You can even place SciTECO into the middle of a pipeline while editing
interactively:
foo | sciteco -qio --no-profile | bar
Unfortunately, this will not currently work when munging the profile
as command-line parameters are also transmitted via the unnamed buffer.
This should be changed to use special Q-registers (FIXME).
* --quiet can help to improve the test suite (TODO).
Should probably be the default in TE_CHECK().
* --stdin and --stdout allow to simplify many SciTECO scripts, avoiding
temporary files, especially for womenpage generation (TODO).
* For processing potentially infinite streams, you will still have to
read using ^T.
|
|
|
|
Also updated NEWS: mention v2.4.0 release.
|
|
--enable-html-docs
* `--enable-html-manual` renamed to `--enable-html-docs`.
* It's also uploaded to the website and linked to in README.
|
|
* 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.
|
|
This will at least show the currently packaged versions on the website.
|
|
|
|
* Curses allows scrolling with the scroll wheel at least
if mouse support is enabled via ED flags.
Gtk always supported that.
* Allow clicking on popup entries to fully autocomplete them.
Since this behavior - just like auto completions - is parser state-dependant,
I introduced a new state method (insert_completion_cb).
All the implementations are currently in cmdline.c since there is some overlap
with the process_edit_cmd_cb implementations.
* Fixed pressing undefined function keys while showing the popup.
The popup area is no longer redrawn/replaced with the Scintilla view.
Instead, continue to show the popup.
|
|
* You need to set 0,64ED to enable mouse processing in Curses.
It is always enabled in Gtk as it should never make the experience worse.
sample.teco_ini enables mouse support, since this should be the new default.
`sciteco --no-profile` won't have it enabled, though.
* On curses, it requires the ncurses mouse protocol version 2, which will
also be supported by PDCurses.
* Similar to the Curses API, a special key macro ^KMOUSE is inserted if any of the supported
mouse events has been detected.
* You can then use -EJ to get the type of mouse event, which can be used
with a computed goto in the command-line editing macro.
Alternatively, this could have been solved with separate ^KMOUSE:PRESSED,
^KMOUSE:RELEASED etc. pseudo-key macros.
* The default ^KMOUSE implementation in fnkeys.tes supports the following:
* Left click: Edit command line to jump to position.
* Ctrl+left click: Jump to beginning of line.
* Right click: Insert position or position range (when dragging).
* Double right click: insert range for word under cursor
* Ctrl+right click: Insert beginning of line
* Scroll wheel: scrolls (faster with shift)
* Ctrl+scroll wheel: zoom (GTK-only)
* Currently, there is no visual feedback when "selecting" ranges
via right-click+drag.
This would be tricky to do and most terminal emulators do not appear
to support continuous mouse updates.
|
|
|
|
* 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
|
|
* 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.
|
|
frontend to alt.lang.teco
* This appears to be the only remaining working web frontend to alt.lang.teco.
* There is https://www.usenetarchives.com/threads.php?id=alt.lang.teco
which has an archive of very old posts, which is cool, but they appear to have
stopped synchronizing somewhere around 2022.
* https://alt.lang.teco.narkive.com/ is broken and also not fully synchronized.
* Google Groups stopped working in February 2024.
* The FreeBSD port isn't yet in any quartely branch, so it's unlikely somebody can
just pkg install it (yet).
|
|
ircs-URLs (refs #29)
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
* This pushes to the gh-pages branch since we don't yet want to introduce a new
workflow (that would have to rebuild SciTECO).
* Built as part of the nightly MacOS builds.
The Ubuntu builds directly build Debian packages which do not contain the
HTML manuals.
* I don't want to check in images into the master branch.
The gh-pages branch is cleaned with every build.
Therefore I still cross-link to Sourceforge for any additional images
and documents.
* We could automatically build the cheat-sheet.pdf (TODO?).
For the time being, we are still linking to Sourceforge.
|
|
|
|
|
|
* When enabled with bit 2 in the ED flags (0,4ED),
all registers and buffers will get the raw ANSI encoding (as if 0EE had been
called on them).
You can still manually change the encoding, eg. by calling 65001EE afterwards.
* Also the ANSI mode sets up character representations for all bytes >= 0x80.
This is currently done only depending on the ED flag, not when setting 0EE.
* Since setting 16,4ED for 8-bit clean editing in a macro can be tricky -
the default unnamed buffer will still be at UTF-8 and at least a bunch
of environment registers as well - we added the command line option
`--8bit` (short `-8`) which configures the ED flags very early on.
As another advantage you can mung the profile in 8-bit mode as well
when using SciTECO as a sort of interactive hex editor.
* Disable UTF-8 checks in 8-bit clean mode (sample.teco_ini).
|
|
|
|
|
|
|
|
|
|
|
|
* This port is quite basic and does not yet allow building Gtk versions.
|
|
* This is supposed to allow new users without any prior exposure to SciTECO
to pick up the basics of practical usage of SciTECO as an editor.
It almost does not elaborate on scripting-side of things.
* This requires a full Groff installation, so the document is not built by default.
|
|
* replace actions/upload-artifact with pyTooling/Actions/releaser
* The release URL will never change:
https://github.com/rhaberkorn/sciteco/releases/tag/nightly
* On the downside there is now a "nightly" tag in the repo that will
be updated to HEAD whenever a nightly build runs - but other than that it does no harm.
* Compared with artifacts, the new method has several advantages:
* No more nightly.link Github App required
* We can add arbitrary files into releases and no longer have to ZIP everything.
So you can now download the Debian packages separately, the Mac OS "package" is a tar.gz
(instead of zipped tar).
For the Windows packages not much changes, though.
* Files get updated in the "Nightly Builds" release even when individual jobs in the
nightly.yml workflow fail.
With artefacts, the entire workflow must be successful.
* Releases are not deleted after 90 days as opposed to artefacts.
So when my workflow breaks next time, there will still be files to download
for a long time.
* As a downside, the file names in the release have to be uniform and must not contain
versions, commit hashes and dates so that uploads replace old files instead of adding
new ones.
Some manual cleanup could still be necessary after large packaging changes.
This could be worked around, by uploading everything first as artefacts and updating the
release in a separate job, but is not worth the trouble IMHO.
* Another disadvantage is that there will be no old nightly builds to download
(although these were not easily downloadable for end users before).
|
|
* Only x86_64 builds are supported for the time being.
They have been tested on Mac OS 10.15 (Darling) and 11 (thanks to @dertuxmalwieder).
* Curses glitches remain on Mac OS as reported by @dertuxmalwieder.
Under Darling with a Linux terminal emulator, everything looks as it should.
* We don't build AppBundles or pkg installers but instead came up with a rather
ideosyncratic way of packaging:
The packages are tarballs of the installation tree with all dependant libraries
added under /usr/local/lib/sciteco - thanks to dylibbundler.
The archives are supposed to be unpacked into the UNIX tree root (`tar -C / -xf sciteco.tar`)
and it will be necessary to "de-quarantine" all the binaries.
Details will be documented in the wiki:
https://github.com/rhaberkorn/sciteco/wiki/Mac-OS-Support
* Perhaps we will also ship an installation script (TODO).
* AppBundles would have the disadvantage that they cannot be directly installed
into $PATH. On the other hand, this would be relatively easy to do afterwards.
An AppBundle would need certain code adaptions for Mac OS, though.
* Gtk+ builds are not yet supported as I cannot test them with "Darling".
* All Nightly Build artifact names now mention the target architecture.
* build Win32 nightly builds with windows-2019
* May improve compatibility slightly in the future as we should
always build our binaries on the oldest possible system.
* Does not change anything currently since windows-2019 == windows-latest.
* CI still uses windows-latest and may therefore one day switch to windows-2022.
* updated README
|
|
* follow the current terminology:
* PDCurses/Win32a is now called PDCursesMod and includes all other PDCurses ports as well.
The Win32 GUI port is now called PDCurses/WinGUI.
* PDCurses/Win32 is now called PDCurses/WinCon.
* Since PDCursesMod supports WinCon as well, we use the PDCURSES_MOD macro only
to detect PDCursesMod API extensions.
GUIs (detached from system console) might be available both in classic PDCurses as well
as in PDCursesMod.
Only PDCursesMod allows detection of the port used *at runtime* using PDC_get_version().
We therefore introduced a --with-interface=pdcurses-gui that must be given whenever
compiling for any kind of GUI port (including SDL on "classic" PDCurses).
* The PDCURSES macro is used to detect all PDCurses (whether classic or PDCursesMod) API extensions.
* __PDCURSES__ is used to detect PDCurses whenever API extensions are not required.
* Assume that A_UNDERLINE now works even on WinCon.
|
|
* turns out that we need icon themes and pixbuf loaders as well
* GTK assumes an UNIX like hierarchy, so we package sciteco.exe and
all DLLs into a bin/ subdir.
* The SciTECO icons probably shouldn't be in bin/.
If we installed them into the hicolor icon theme, GTK might
pick them up automatically. This would work under Windows and UNIX.
* The GTK builds are still broken.
I do really need a real system (MSYS installation) to play around.
|
|
|
|
* I could not get malloc replacement via dlmalloc to work.
This does not work like on Linux by overwriting weak malloc() functions.
It should theoretically be possible to overwrite the default malloc zone
but I could not properly debug this since I can only build for Mac OS
via CI.
* memory polling seems to work though - test suite runs through
and it includes memory limiting test cases.
|
|
builds) and include Gtk+ versions
* The CI tests are unchanged. The workflow file has been renamed to ci.yml, though.
* Nightly builds are described by nightly.yml and are built at 4:13.
* Nightly Ubuntu package builds now include the Gtk+ 3 packages.
|
|
nightly builds in README
|
|
|
