aboutsummaryrefslogtreecommitdiffhomepage
path: root/debian
AgeCommit message (Collapse)AuthorFilesLines
2025-03-03rename sample.teco_ini to fallback.teco_ini and mung it by defaultRobin Haberkorn1-0/+1
* 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-01-13updated copyright to 2025Robin Haberkorn1-1/+1
2024-12-28Debian: disabled parallel builds when running the test suiteRobin Haberkorn2-3/+3
* Hopefully makes the log easier to read in case of failures. There may still be 2 runs concurrently since we build Curses and Gtk in parallel. * Updated homepage. * Ubuntu plucky builds are failing. See https://launchpadlibrarian.net/765999455/buildlog_ubuntu-plucky-amd64.sciteco_2.3.0-0ppa1~plucky1_BUILDING.txt.gz This may have been a spurious failure due to xvfb-run. It may be less likely with --no-parallel. Theoretically we could bump the Debian package version in order to test that, but the PPA is practically not used by anybody anyway.
2024-12-25prepared v2.3.0 releasev2.3.0Robin Haberkorn1-0/+6
2024-12-09updated Debian package for v2.2.0 releaseRobin Haberkorn1-0/+6
2024-11-18Debian/Ubuntu, FreeBSD and website updates for v2.1.1 releaseRobin Haberkorn1-0/+6
2024-11-05fully support relocatable binaries, improving AppImagesRobin Haberkorn1-2/+7
* 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-16updated ChangeLog, FreeBSD and Debian packages for v2.1.0 releaseRobin Haberkorn1-0/+6
2024-09-09prefer libncursesw (widechar variant) (refs #5)Robin Haberkorn1-1/+1
* 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-23debian package: updated copyright to 2024Robin Haberkorn1-1/+1
2024-08-23fully support out of tree buildsRobin Haberkorn1-6/+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
2023-06-20Debian: fixed rules (build and binary targets)Robin Haberkorn1-2/+33
* dh_testdir would sometimes cause problems on the PPA servers, so we replaced it with an empty rule. * We need to define the binary-arch and binary-indep targets in order to recurse into the correct subdirectories. I do not understand why this always worked on the Github runner and sometimes even on the PPA servers. Unfortunately, we cannot just call `dh binary-arch -B... -p...` since that would call `dh_install -a` which overrides any `-p` (package), thus trying to install the curses binaries from the Gtk build directory and vice versa.
2023-06-20Debian: updated/modernized config filesRobin Haberkorn3-13/+39
* This resolves must lintian warnings and errors.
2023-06-20fixup 75533443ecae81d6861bdc1402a0e4b271838979: fixes sciteco-gtk Debian ↵Robin Haberkorn1-1/+1
packages
2023-06-19distribute sciteco.desktopRobin Haberkorn2-10/+1
* Useful for packaging on platforms where we can only build from tarballs (FreeBSD) * I don't know whether it's always safe and correct to install this file into $DATADIR/applications, so the file is only distributed but not installed yet. * It contains a hardcoded binary name "gsciteco". This could actually differ depending on the concrete --program-prefix and it would be good to include the exact installation path. This however is not possible as long as we do not install this file.
2023-04-05updated copyright to 2023Robin Haberkorn1-1/+1
2022-06-21updated copyright to 2022 and updated TODORobin Haberkorn1-1/+1
2021-10-12fixed Debian packages: don't use curly brace expansions as they are not portableRobin Haberkorn3-3/+7
* fixed some Debian lintian warnings
2021-10-11upgraded to Scintilla 5.1.3 and Scinterm 3.1Robin Haberkorn3-14/+13
* Previous Scintilla version was 3.6.4 and Scinterm was 1.7 (with lots of custom patches). All of the patches are now either irrelevant or have been merged upstream. * Since Scintilla 5 requires C++17, this increases the minimum GCC version at least to 5.0. We may actually require even newer versions. * I could not upgrade the scintilla-mirror (which was imported from Mercurial), so the old sciteco-dev branch was renamed to sciteco-dev-pre-v2.0.0, master was deleted and I reimported the entire Scintilla repo using git-remote-hg. This means that scintilla-mirror now contains two entirely separate trees. But it is still possible to clone old SciTECO repos. * The strategy/workflow of maintaining hotfix branches on scintilla-mirror has been changed. Instead of having one sciteco-dev branch that is rebased onto new Scintilla upstream releases and tagging SciTECO releases in scintilla-mirror (to keep the commits referenced), we now create a branch for every Scintilla version we are based on (eg. sciteco-rel-5-1-3). This branch is never rebased or deleted. Therefore, we are guaranteed to be able to clone arbitrary SciTECO repo commits - not only releases. Releases no longer have to be tagged in scintilla-mirror. On the downside, fixup commits may accumulate in these new branches. They can only be squashed once a new branch for a new Scintilla release is created (e.g. by cherry-picking followed by rebase). * Scinterm does no longer have to reside in the Scintilla subdirectory, so we added it as a regular submodule. There are no more recursive submodules. The Scinterm build system has not been improved at all, but we use a trick based on VPATH to build Scinterm in scintilla/bin/. * Scinterm is now in Git and we reference the upstream repo for the time being. We might mirror it and apply the same branching workflow as with Scintilla if necessary. The scinterm-mirror repository still exists but has not been touched. We will also have to rewrite its master branch as it was a non-reproducible Mercurial import. * Scinterm now also comes with patches for Scintilla which we simply applied on our sciteco-rel-5-1-3 branch. * Scintilla 5 outsourced its lexers into the Lexilla project. We added it as yet another submodule. * All submodules have been moved into contrib/. * The Scintilla API for setting lexers has consequently changed. We now have to call SCI_SETILEXER(0, CreateLexer(name)). As I did not want to introduce a separate command for setting lexers, <ES> has been extended to allow setting lexers by name with the SCI_SETILEXER message which effectively replaces SCI_SETLEXERLANGUAGE. * The lexer macros (SCLEX_...) no longer serve any purpose - they weren't used in the SciTECO standard library anyway - and have consequently been removed from symbols-scilexer.c. The style macros from SciLexer.h (SCE_...) are theoretically still useful - even though they are not used by our current color schemes - and have therefore been retained. They can be specified as wParam in <ES>. * <ES> no longer allows symbolic constants for lParam. This never made any sense since all supported symbols were always wParam. * Scinterm supports new native cursor modes. They are not used for the time being and the previous CARETSTYLE_BLOCK_AFTER caret style is configured by default. It makes no sense to enable native cursor modes now since the command line should have a native cursor but is not yet a Scintilla view. * The Scintilla upgrade performed much worse than before, so some optimizations will be necessary.
2021-06-08get rid of the GObject Builder (GOB2): converted teco-gtk-info-popup.gob and ↵Robin Haberkorn1-1/+1
teco-gtk-label.gob to plain C * Using modern GObject idioms and macros greatly reduces the necessary boilerplate code. * The plain C versions of our GObject classes are now "final" (cannot be derived) This means we can hide the instance structures from the headers and avoid using explicit private fields. * Avoids some deprecation warnings when building the Gtk UI. * GOB2 is apparently no longer maintained, so this seems like a good idea in the long run. * The most important reason however is that there is no precompiled GOB2 for Windows which prevents compilation on native Windows hosts, eg. during nightly builds. This is even more important as Gtk+3 is distributed on Windows practically exclusively via MSYS. (ArchLinux contains MinGW gtk3 packages as well, so cross-compiling from ArchLinux would have been an alternative.)
2021-06-01debianized the Gtk UI (sciteco-gtk)Robin Haberkorn9-16/+125
* Added a Freedesktop file - only as part of the debian package yet. `make install` won't install a Desktop file since it would have to be generated. * Just like when installing manually, you can have a Curses and Gtk installation side by side using the same .teco_ini. * Common data between the Curses UI (sciteco-curses) and Gtk UI are in a new architecture-independant package sciteco-common. * The Gtk+ binaries are prefixed with `g` (gsciteco, gtedoc.tes, ggrosciteco.tes). * Debian source and binary packages can be built using `./distribute.mk debian` as usual. It should also be possible to push everything to the PPA for the next release, although that is not yet tested.
2021-05-30updated Debian packageRobin Haberkorn2-1/+7
* required a new changelog entry since the target release is now v2.0.0 * Glib dependency bumped
2021-05-30THE GREAT CEEIFICATION EVENTRobin Haberkorn1-19/+25
This is a total conversion of SciTECO to plain C (GNU C11). The chance was taken to improve a lot of internal datastructures, fix fundamental bugs and lay the foundations of future features. The GTK user interface is now in an useable state! All changes have been squashed together. The language itself has almost not changed at all, except for: * Detection of string terminators (usually Escape) now takes the string building characters into account. A string is only terminated outside of string building characters. In other words, you can now for instance write I^EQ[Hello$world]$ This removes one of the last bits of shellisms which is out of place in SciTECO where no tokenization/lexing is performed. Consequently, the current termination character can also be escaped using ^Q/^R. This is used by auto completions to make sure that strings are inserted verbatim and without unwanted sideeffects. * All strings can now safely contain null-characters (see also: 8-bit cleanliness). The null-character itself (^@) is not (yet) a valid SciTECO command, though. An incomplete list of changes: * We got rid of the BSD headers for RB trees and lists/queues. The problem with them was that they used a form of metaprogramming only to gain a bit of type safety. It also resulted in less readble code. This was a C++ desease. The new code avoids metaprogramming only to gain type safety. The BSD tree.h has been replaced by rb3ptr by Jens Stimpfle (https://github.com/jstimpfle/rb3ptr). This implementation is also more memory efficient than BSD's. The BSD list.h and queue.h has been replaced with a custom src/list.h. * Fixed crashes, performance issues and compatibility issues with the Gtk 3 User Interface. It is now more or less ready for general use. The GDK lock is no longer used to avoid using deprecated functions. On the downside, the new implementation (driving the Gtk event loop stepwise) is even slower than the old one. A few glitches remain (see TODO), but it is hoped that they will be resolved by the Scintilla update which will be performed soon. * A lot of program units have been split up, so they are shorter and easier to maintain: core-commands.c, qreg-commands.c, goto-commands.c, file-utils.h. * Parser states are simply structs of callbacks now. They still use a kind of polymorphy using a preprocessor trick. TECO_DEFINE_STATE() takes an initializer list that will be merged with the default list of field initializers. To "subclass" states, you can simply define new macros that add initializers to existing macros. * Parsers no longer have a "transitions" table but the input_cb() may use switch-case statements. There are also teco_machine_main_transition_t now which can be used to implement simple transitions. Additionally, you can specify functions to execute during transitions. This largely avoids long switch-case-statements. * Parsers are embeddable/reusable now, at least in parse-only mode. This does not currently bring any advantages but may later be used to write a Scintilla lexer for TECO syntax highlighting. Once parsers are fully embeddable, it will also be possible to run TECO macros in a kind of coroutine which would allow them to process string arguments in real time. * undo.[ch] still uses metaprogramming extensively but via the C preprocessor of course. On the downside, most undo token generators must be initiated explicitly (theoretically we could have used embedded functions / trampolines to instantiate automatically but this has turned out to be dangereous). There is a TECO_DEFINE_UNDO_CALL() to generate closures for arbitrary functions now (ie. to call an arbitrary function at undo-time). This simplified a lot of code and is much shorter than manually pushing undo tokens in many cases. * Instead of the ridiculous C++ Curiously Recurring Template Pattern to achieve static polymorphy for user interface implementations, we now simply declare all functions to implement in interface.h and link in the implementations. This is possible since we no longer hace to define interface subclasses (all state is static variables in the interface's *.c files). * Headers are now significantly shorter than in C++ since we can often hide more of our "class" implementations. * Memory counting is based on dlmalloc for most platforms now. Unfortunately, there is no malloc implementation that provides an efficient constant-time memory counter that is guaranteed to decrease when freeing memory. But since we use a defined malloc implementation now, malloc_usable_size() can be used safely for tracking memory use. malloc() replacement is very tricky on Windows, so we use a poll thread on Windows. This can also be enabled on other supported platforms using --disable-malloc-replacement. All in all, I'm still not pleased with the state of memory limiting. It is a mess. * Error handling uses GError now. This has the advantage that the GError codes can be reused once we support error catching in the SciTECO language. * Added a few more test suite cases. * Haiku is no longer supported as builds are instable and I did not manage to debug them - quite possibly Haiku bugs were responsible. * Glib v2.44 or later are now required. The GTK UI requires Gtk+ v3.12 or later now. The GtkFlowBox fallback and sciteco-wrapper workaround are no longer required. * We now extensively use the GCC/Clang-specific g_auto feature (automatic deallocations when leaving the current code block). * Updated copyright to 2021. SciTECO has been in continuous development, even though there have been no commits since 2018. * Since these changes are so significant, the target release has been set to v2.0. It is planned that beginning with v3.0, the language will be kept stable.
2017-03-03updated copyright to 2017Robin Haberkorn1-2/+2
2016-11-18implemented self-documenting (online) help systemRobin Haberkorn1-1/+2
* the new "?" (help) command can be used to look up help topics. * help topics are index from $SCITECOPATH/women/*.woman.tec files. * looking up a help topic opens the corresponding "womanpage" and jumps to the position of the topic (it acts like an anchor into the document). * styling is performed by *.woman.tec files. * Setting up the Scintilla view and munging the *.tec file is performed by the new "woman.tes" lexer. On supporting UIs (Gtk), womanpages are shown in a variable-width font. * Woman pages are usually not hand-written, but generated from manpages. A special Groff post-processor grosciteco has been introduced for this purpose. It is much like grotty, but can output SciTECO macros for styling the document (ie. the *.woman.tec files). It is documented in its own man-page. * grosciteco also introduces sciteco.tmac - special Troff macros for controlling the formatting of the document in SciTECO. It also defines .SCITECO_TOPIC which can be used to mark up help topics/terms in Troff markup. * Woman pages are generated/formatted by grosciteco at compile-time, so they will work on platforms without Groff (ie. as on windows). * Groff has been added as a hard compile-time requirement. * The sciteco(1) and sciteco(7) man pages have been augmented with help topic anchors.
2016-02-11pass user/maintainer provided CXXFLAGS to the Scintilla build processRobin Haberkorn1-1/+7
* Usually, Scintilla will now be built with -O2 * this can improve performance significantly over the standard Scintilla -Os (up to 10%). * this also allows link-time-optimizing both Scintilla and SciTECO (which are linked statically) by adding -flto to CFLAGS, CXXFLAGS and LDFLAGS. Link-time-optimization will both reduce the total binary size and improve performance slightly since scintilla_send_message() can be inlined. An -O3 optimized Scintilla when linked with LTO results in an only 300kb larger SciTECO binary. * the highest possible optimization thus requires the following maintainer flags on the ./configure command line: CFLAGS="-O3 -mtune=native -march=native -flto" CXXFLAGS="-O3 -mtune=native -march=native -flto" LDFLAGS="-flto" * Windows and Debian builds use link-time-optimization now. On Windows - where we link in everything statically - building the dependant libraries with -flto could improve performance even more. * Debian builds respect the default hardening flags of the build server now. This should ensure that SciTECO is built for the correct architecture at the recommended optimization level etc.
2016-01-31updated debian/copyrightRobin Haberkorn1-5/+12
I'm not sure whether the syntax is correct, so this may need further fixups
2015-03-18bumped release version to v0.6.4, updated ChangeLog and clarify libglib ↵Robin Haberkorn1-3/+5
minimum version * it was necessary to increase the upstream version so I could upload new versions to launchpad while debugging PPA build issues. * ChangeLog finalized for v0.6.4 * SciTECO requires at least libglib v2.28 (but that's only a guess)
2015-03-18fixed Debian package: launchpad build servers have broken $TERM configurationsRobin Haberkorn3-2/+12
* it also sets the compatibility level to 7 which was required when building for Ubuntu Lucid. This version cannot be supported however since its libglib version is too old.
2015-03-17updated Debian package and fixed ./distribute (for Debian packages)Robin Haberkorn2-5/+5
2015-02-11updated copyright to 2015Robin Haberkorn1-2/+2
2014-08-22automatically build Scintilla as part of SciTECO's build system:Robin Haberkorn1-6/+4
this should simplify building SciTECO for new users * compiler and archiver are passed down from Autoconf, so cross-compiling should work transparently * `make clean` will also clean the Scintilla source tree * there is no longer any need for "source bundles" as tar balls also contain Scintilla/Scinterm now * building from Git is not much more difficult than building from a tar ball * The versions of Scintilla/Scinterm embedded as submodules already contain all the patches necessary (currently none are necessary), so there's no need to have patch files in the repository * INSTALL instructions have been rewritten * the --with-scintilla and --with-scinterm site-config options have been kept. But they should be rarely necessary now.
2014-02-17mention sciteco.sf.net as the project's homepageRobin Haberkorn2-2/+2
2014-02-16prepare new target release v0.6Robin Haberkorn1-0/+8
2014-02-16updated minimum required Scintilla version to v3.3.7 / Scinterm v1.2Robin Haberkorn1-2/+2
* allows us to remove most patches. One however is still necessary (Scinterm Makefile bug!) * TECO-style control code echoing is now set up using the SCI_SETREPRESENTATION message * updated copyrights * updated TODO
2014-02-15updated Copyright to year 2014Robin Haberkorn1-2/+2
2014-02-15fixed formatting of "Text Editor and Corrector"Robin Haberkorn1-1/+1
2013-03-28added missing debian copyright notice for BSD headersRobin Haberkorn1-0/+5
2013-03-20updated version to 0.5Robin Haberkorn1-1/+1
2013-03-20use a Debian version and branch by defaultRobin Haberkorn1-1/+1
* distributed binary packages are standard debian packages * ./distribute might fix up the package version and branch for Ubuntu/PPA
2013-03-20default Scintilla-path is ../scintillaRobin Haberkorn1-1/+0
so no additional --with-scintilla is necessary when building from a source bundle
2013-03-19debianized SciTECORobin Haberkorn6-0/+116
* prepared for upload to Ubuntu PPA * debian package will not be in autoconf source distro * will only build as a non-native package based on a source bundle that contains scintilla, scinterm and has patches applied