<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/Makefile.am, branch v2.5.2</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>&lt;EW&gt; now accepts a numeric argument to specify the buffer to save</title>
<updated>2025-07-19T15:09:33+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-19T14:38:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=29e11f68bae0364034fb692062403735bec8d07a'/>
<id>29e11f68bae0364034fb692062403735bec8d07a</id>
<content type='text'>
* In this case we always save the given buffer and never the current Q-Register.
* The current Q-Register is only saved without any numeric argument.
  The same semantics make sense for &lt;EF&gt; so that Q*EF closes the current buffer
  even when editing a Q-Register.
* This variant is present in Video TECO.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* In this case we always save the given buffer and never the current Q-Register.
* The current Q-Register is only saved without any numeric argument.
  The same semantics make sense for &lt;EF&gt; so that Q*EF closes the current buffer
  even when editing a Q-Register.
* This variant is present in Video TECO.
</pre>
</div>
</content>
</entry>
<entry>
<title>Gtk/win32: fixed fonts and therefore pango warnings on startup (closes #7)</title>
<updated>2025-04-18T18:27:00+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-18T18:27:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=91fa1656600a52eddf650ea550e7cbd69d72903e'/>
<id>91fa1656600a52eddf650ea550e7cbd69d72903e</id>
<content type='text'>
* The default womanpage font is the abstract "Serif" now, so that should be
  more portable. "Times" wasn't found on Windows.
* Win32 distributions include a custom .teco_css now, which
  removes the small-caps font attribute from the type label.
  The default Gtk theme on Windows references the "Segoe UI" font
  and it doesn't have a small-caps variant.
  In fact no default Windows font appears to have one.
* We could add a custom .teco_ini to win32 distributions as well,
  but there is currently no need for it.
* Do not distribute the /win32 files. They are used only for building
  Win32/64 packages. There is no point in distributing them in the tarball if
  the /debian and /freebsd directories aren't distributed as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The default womanpage font is the abstract "Serif" now, so that should be
  more portable. "Times" wasn't found on Windows.
* Win32 distributions include a custom .teco_css now, which
  removes the small-caps font attribute from the type label.
  The default Gtk theme on Windows references the "Segoe UI" font
  and it doesn't have a small-caps variant.
  In fact no default Windows font appears to have one.
* We could add a custom .teco_ini to win32 distributions as well,
  but there is currently no need for it.
* Do not distribute the /win32 files. They are used only for building
  Win32/64 packages. There is no point in distributing them in the tarball if
  the /debian and /freebsd directories aren't distributed as well.
</pre>
</div>
</content>
</entry>
<entry>
<title>rename sample.teco_ini to fallback.teco_ini and mung it by default</title>
<updated>2025-03-03T20:35:04+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-02T22:44:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=1b907dae072f2aa93d75d8c056a9bd02555a17f8'/>
<id>1b907dae072f2aa93d75d8c056a9bd02555a17f8</id>
<content type='text'>
* 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: don't install PNG icons</title>
<updated>2024-12-23T01:07:44+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-12-23T01:07:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e5d1253d363a209ecd1288278808e38ac87b34d9'/>
<id>e5d1253d363a209ecd1288278808e38ac87b34d9</id>
<content type='text'>
* 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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.
</pre>
</div>
</content>
</entry>
<entry>
<title>the SciTECO data installation path is now configurable via --with-scitecodatadir</title>
<updated>2023-06-19T17:45:16+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-19T17:45:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=60a09132b62c3cae86f5e832830a4490ba5bf712'/>
<id>60a09132b62c3cae86f5e832830a4490ba5bf712</id>
<content type='text'>
* This is also the base of $SCITECOPATH.
* Changing it is useful for packaging where it is not possible to factor out the common
  files between Curses and Gtk builds into a "sciteco-common" package.
  As an alternative, you can now create disjunct sciteco-curses and sciteco-gtk packages.
* You will most likely want to use this for Gtk builds as in:
  --with-interface=gtk --program-prefix=g --with-scitecodatadir=/usr/local/share/gsciteco.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This is also the base of $SCITECOPATH.
* Changing it is useful for packaging where it is not possible to factor out the common
  files between Curses and Gtk builds into a "sciteco-common" package.
  As an alternative, you can now create disjunct sciteco-curses and sciteco-gtk packages.
* You will most likely want to use this for Gtk builds as in:
  --with-interface=gtk --program-prefix=g --with-scitecodatadir=/usr/local/share/gsciteco.
</pre>
</div>
</content>
</entry>
<entry>
<title>simplified win32 packaging using mingw-bundedlls</title>
<updated>2022-12-03T05:07:56+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2022-12-03T02:04:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=4b501f288309e8d201a758ba23ddccfa9dffed81'/>
<id>4b501f288309e8d201a758ba23ddccfa9dffed81</id>
<content type='text'>
* mingw-bundledlls finds and copies transitive DLL dependencies.
* Like all external one-file sources, mingw-bundledlls has been copied into contrib/
  instead of adding a submodule.
  It's taken from here: https://github.com/mpreisler/mingw-bundledlls
* Packaging is more robust now if dependant DLLs are upgraded or if we
  decide to link in more statically.
  With the old scheme, we might also miss some DLL and break builds
  without even noticing it.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* mingw-bundledlls finds and copies transitive DLL dependencies.
* Like all external one-file sources, mingw-bundledlls has been copied into contrib/
  instead of adding a submodule.
  It's taken from here: https://github.com/mpreisler/mingw-bundledlls
* Packaging is more robust now if dependant DLLs are upgraded or if we
  decide to link in more statically.
  With the old scheme, we might also miss some DLL and break builds
  without even noticing it.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed Debian packages: don't use curly brace expansions as they are not portable</title>
<updated>2021-10-12T07:43:35+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-10-12T07:06:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=da1a6507a826acbdfc2f492027efe0c48cc790b6'/>
<id>da1a6507a826acbdfc2f492027efe0c48cc790b6</id>
<content type='text'>
* fixed some Debian lintian warnings
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* fixed some Debian lintian warnings
</pre>
</div>
</content>
</entry>
<entry>
<title>upgraded to Scintilla 5.1.3 and Scinterm 3.1</title>
<updated>2021-10-11T05:02:05+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-10-11T05:02:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=6e67f5a682ff46d69888fec61b94bf45cec46721'/>
<id>6e67f5a682ff46d69888fec61b94bf45cec46721</id>
<content type='text'>
* 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,
  &lt;ES&gt; 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 &lt;ES&gt;.
* &lt;ES&gt; 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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,
  &lt;ES&gt; 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 &lt;ES&gt;.
* &lt;ES&gt; 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.
</pre>
</div>
</content>
</entry>
<entry>
<title>revised icon loading on Windows and packaging again</title>
<updated>2021-10-08T20:09:14+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-06-09T17:14:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=535c9e63afa226e334bf7e3e2835dc130e853dee'/>
<id>535c9e63afa226e334bf7e3e2835dc130e853dee</id>
<content type='text'>
* We don't need the PNG icons on Windows as the compiled-in ICO should suffice
* Ship the dependencies of the SVG pixbuf loader.
* The PNG pixbuf loader is still distributed, as we at least need it
  for loading the icon theme.
* Install a loaders.cache - without it, the pixbuf loaders won't be found.
  This file can be generated by gdk-pixbuf-query-loaders but apparently has
  to be modified by hand.
* Regenerate the icon cache using gtk-update-icon-cache.
* Icon themes are found now.
  Unfortunately, we have to distribute the entire Adwaita icon theme
  as distributing only the scalable (SVG) icons does not work for some
  strange reason (FIXME).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* We don't need the PNG icons on Windows as the compiled-in ICO should suffice
* Ship the dependencies of the SVG pixbuf loader.
* The PNG pixbuf loader is still distributed, as we at least need it
  for loading the icon theme.
* Install a loaders.cache - without it, the pixbuf loaders won't be found.
  This file can be generated by gdk-pixbuf-query-loaders but apparently has
  to be modified by hand.
* Regenerate the icon cache using gtk-update-icon-cache.
* Icon themes are found now.
  Unfortunately, we have to distribute the entire Adwaita icon theme
  as distributing only the scalable (SVG) icons does not work for some
  strange reason (FIXME).
</pre>
</div>
</content>
</entry>
<entry>
<title>when not replacing malloc with dlmalloc (--disable-malloc-replacement), don't build an empty libdlmalloc</title>
<updated>2021-06-05T00:31:39+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-06-04T16:26:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=686bb6c596c1574310b340160dfeb08df8dff81c'/>
<id>686bb6c596c1574310b340160dfeb08df8dff81c</id>
<content type='text'>
* on some platforms (eg. Darwin/mac OS) we cannot apparently build empty
  convenience libraries
* instead, we use conditional subdirectories and a conditional library dependency
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* on some platforms (eg. Darwin/mac OS) we cannot apparently build empty
  convenience libraries
* instead, we use conditional subdirectories and a conditional library dependency
</pre>
</div>
</content>
</entry>
</feed>
