| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
* especially to improve building on FreeBSD 11
* We need GNU Make, yet alone because Scintilla/Scinterm
needs it. We now document that dependency and added
an Autoconf check from the autoconf-archive.
We make sure that the build process is invoked with GNU make
by generating only GNUmakefiles.
The Makefile.am files have not been renamed, so this
change can be rolled back easily.
* Some GNU-Make-specific autoreconf warnings have still been
resolved. But not all of them, as this would have been
unelegant and we need GNU Make anyway.
* Declare ACLOCAL_AMFLAGS to appease autoreconf
* Added an explicit check for C++11 from the autoconf-archives.
In general we should support building with every C++11 compiler
that is sufficiently GNU-like.
* Do not use `sed` for inplace editing, as different sed-implementations
have mutually incompatible syntax for this.
Instead of declaring and checking a dependency on GNU sed,
we simply use SciTECO for the editing task.
This improves code portability on BSDs.
* Similarily, BSD/POSIX `cmp` is supported now.
This fixes the test suite on BSD without declaring a
dependency on the GNU coreutils.
* Simplified sciteco-wrapper generation.
|
|
* some classic TECOs have this
* just like ^[, dollar works as a command only, not as a string terminator
* it improves the readability of macros using printable characters only
* it closes a gap in the language by allowing $$ (double-dollar) and
^[$ as printable ways to write the return from macro command.
^[^[ was not and is not possible.
* since command line termination is a regular interactive return-command
in SciTECO, double-dollar will also terminate the command line now.
This will be allowed unless it turns out to be a cause of trouble.
* The handling of unterminated commands has been cleaned up by
introducing State::end_of_macro().
Most commands (and thus states) except the start state cannot be
valid at the end of a macro since this indicates an unterminated/incomplete
command.
All lookahead-commands (currently only ^[) will end implicitly
at the end of a macro and so will need a way to perform their action.
The virtual method allows these actions to be defined with the rest
of the state's implementation.
|
|
* The $$ would leave the current state pointing to the "escape" state
which was manually fixed up in macro return handling but not in command line
return (ie. termination) handling.
Therefore the initial state at the start of the command line after $$
was the "escape" state.
The rubout-last-command immediate editing command would consequently
end up in an infinite loop trying to reach the start state.
* This has been fixed by setting the state before throwing Return().
Some additional paranoia assertions have been added to prevent this
bug in the future.
|
|
* this has been broken since cb5e08b40d
|
|
* a table reference was stored in the UndoToken.
* since there are only two tables at a given moment, this can
be avoided by having two different undo tokens, one for globals
and one for locals.
* Practically, undo tokens for locals are only created for the
top-level local Q-Reg table since macro calls with locals
with set must_undo to false since the local table is destroyed
with the macro return.
|
|
* shouldn't really be an issue but since we already have
CTL_KEY_ESC_STR as a character literal, we may as well use it.
|
|
* on MSVCRT/MinGW, space allocated with alloca()/g_newa() was apparently
freed once the first exception was caught.
This prevented the proper destruction of local Q-Reg tables and
broke the Windows port.
* Since all alternatives to alloca() like VLAs are not practical,
the default Q-Register initialization has been moved out of the
QRegisterTable constructor into QRegisterTable::insert_defaults().
* The remaining QRegisterTable initialization and destruction is
very cheap, so we simply reserve an empty QRegisterTable for
local registers on every Execute::macro() call.
The default registers are only initialized when required, though.
* All of this has to change anyway once we replace the
C++ call-stack approach to macro calls with our own macro
call frame memory management.
|
|
* we can use root() instead of min() which is faster
|
|
performance issues with memory measurements
* Fixed build problems on Windows
* g_slice on Windows has been shown to be of little use either
and it does not work well with the GetProcessMemoryInfo()
measurements.
Also, it brings the same problem as on Glibc: Not even command-line
termination returns the memory to the OS.
Therefore, we don't use g_slice at all and commented on it.
* The custom Linux and Windows memory measurement approaches
have been shown to be inefficient.
As a workaround, scripts disable memory limiting.
* A better approach -- but it will only work on Glibc -- might
be to hook into malloc(), realloc() and free() globally
and use the malloc_usable_size() of a heap object for
memory measurements. This will be relatively precise and cheap.
* We still need the "Object" base class in order to measure
memory usage as a fallback approach.
|
|
* a simple cast was missing due to C++ aliasing rules
|
|
* we were basing the glib allocators on throwing std::bad_alloc just like
the C++ operators. However, this always was unsafe since we were throwing
exceptions across plain-C frames (Glib).
Also, the memory vtable has been deprecated in Glib, resulting in
ugly warnings.
* Instead, we now let the C++ new/delete operators work like Glib
by basing them on g_malloc/g_slice.
This means they will assert and the application will terminate
abnormally in case of OOM. OOMs cannot be handled properly anyway, so it is
more important to have a good memory limiting mechanism.
* Memory limiting has been completely revised.
Instead of approximating undo stack sizes using virtual methods
(which is unprecise and comes with a performance penalty),
we now use a common base class SciTECO::Object to count the memory
required by all objects allocated within SciTECO.
This is less precise than using global replacement new/deletes
which would allow us to control allocations in all C++ code including
Scintilla, but they are only supported as of C++14 (GCC 5) and adding compile-time
checks would be cumbersome.
In any case, we're missing Glib allocations (esp. strings).
* As a platform-specific extension, on Linux/glibc we use mallinfo()
to count the exact memory usage of the process.
On Windows, we use GetProcessMemoryInfo() -- the latter implementation
is currently UNTESTED.
* We use g_malloc() for new/delete operators when there is
malloc_trim() since g_slice does not free heap chunks properly
(probably does its own mmap()ing), rendering malloc_trim() ineffective.
We've also benchmarked g_slice on Linux/glib (malloc_trim() shouldn't
be available elsewhere) and found that it brings no significant
performance benefit.
On all other platforms, we use g_slice since it is assumed
that it at least does not hurt.
The new g_slice based allocators should be tested on MSVCRT
since I assume that they bring a significant performance benefit
on Windows.
* Memory limiting does now work in batch mode as well and is still
enabled by default.
* The old UndoTokenWithSize CRTP hack could be removed.
UndoStack operations should be a bit faster now.
But on the other hand, there will be an overhead due to repeated
memory limit checking on every processed character.
|
|
* test case: rubout 1U[foo]
* this probably also leaked memory if it didn't crash
* a missing cast from RBTree::remove() was missing.
This cast is necessary since QRegister uses multiple inheritance.
The offset of RBEntryString might not be 0 in QRegister.
Also, since the base class is no longer virtual, a cast to the
virtual QRegister class is necessary to ensure that subclass
destructors get called.
This might have not caused problems before since RBEntry was virtual
or the compiler just happened to reorder the instance structures.
|
|
implementation classes
* whenever the implementation class was not exactly RBEntryType,
it had to have a virtual destructor since RBTree cared about
cleanup and had to delete its members.
* Since it does not allocate them, it is consistent to remove RBTree::clear().
The destructor now only checks that subclasses have cleaned up.
Implementing cleanup in the subclasses is trivial.
* Consequently, RBEntryString no longer has to be virtual.
HelpIndex and GotoTables are completely non-virtual now
which saves memory (and a bit of cleanup speed).
For QRegister, not much changes, though.
|
|
* From what the documentation says, a dot may only be used
once to introduce a local Q-Register specification.
The parser was accepting arbitrarily many dots though.
* Now, ".." will refer to the local register ".".
|
|
* Using a common implementation in RBTreeString::auto_complete().
This is very efficient even for very huge tables since only
an O(log(n)) lookup is required and then all entries with a matching
prefix are iterated. Worst-case complexity is still O(n), since all
entries may be legitimate completions.
If necessary, the number of matching entries could be restricted, though.
* Auto completes short and long Q-Reg names.
Short names are "case-insensitive" (since they are upper-cased).
Long specs are terminated with a closing bracket.
* Long spec completions may have problems with names containing
funny characters since they may be misinterpreted as string building
characters or contain braces. All the auto-completions suffered from
this problem already (see TODO).
* This greatly simplifies investigating the Q-Register name spaces
interactively and e.g. calling macros with long names, inserting
environment registers etc.
* Goto labels are terminated with commas since they may be part
of a computed goto.
* Help topics are matched case insensitive (just like the topic
lookup itself) and are terminated with the escape character.
This greatly simplifies navigating womanpages and looking up
topics with long names.
|
|
* the old implementation tried to avoid template programming by
making the entry comparison function virtual.
* The new RBTree implementation takes a template argument with the
implementation of RBEntry. It is now partially conventional
that the template argument must be actually derived from RBTree::RBEntry
and must define a "compare" method.
* As an advantage we now get static polymorphism (avoiding virtual
calls and allowing for more compiler optimizations) and the
the RBEntry implementation no longer has to be virtual.
* The only RB-Trees actually used are string-keyed, though.
Therefore there's a common base class RBTreeString now which
defines two synonymous "key" and "name" attributes.
* The entry base class RBEntryString is virtual again because
we do not want to propagate the RBEntryType template parameter
even further and the RBTree base class needs to destroy
entries.
This might be avoided by not defining a RBTree::clear() method,
leaving this task to the implementations.
At least QRegisters have to be virtual, though.
* RBTreeString only depends on the strcmp() and strncmp() functions
used now and only case-sensitive and case-insensitive versions
are actually required, so we instantiate these templates statically
in rbtree.cpp.
This means there are still only two instantiations of the RBTree
in the binary.
* RBTreeString defines convenient wrappers for find() and nfind()
to look up by string.
This uses the RBEntryString base class, so no allocations whatsover
are required for lookups and less space is wasted on the call stack.
* A RBEntryOwnString base class is also provided which frees the
implementations from memory managing the tree keys.
* RBTreeString can now be used to add other common functionality
like auto-completions for Q-Registers, goto labels and help topics.
* some minor optimizations
* updated TODO
|
|
called tedoc.tes
* some code simplifications
* it now supports command line arguments via getopt.tes.
* the -C flag enabled C/C++ mode.
By default tedoc parses SciTECO code which means it can be used
to document macro packages as well.
* Therefore it is installed as a separate tool now.
It may be used as a Groff preprocessor for third-party macro
authors to generate (wo)man pages.
* there's a man page tedoc.tes(1)
* The troff placeholder macro is now called ".TEDOC".
* Help topics can now be specified after the starting comment /*$ or !*$.
Topics have been defined for all built-in commands.
|
|
* this uses an optstring compatible with getopt(3).
* It does not use repeated getopt calls to iterate options, though
but places the results in registers beginning with "getopt.".
E.g. option "C" will result in "getopt.C" being set after the
call to setopt.
String arguments are supported and are placed in the string part
of the getopt registers.
* The grosciteco.tes and symbols-extract.tes scripts make use of
getopt now, to simplify and clean up their command line handling.
|
|
* it turns out that option-like arguments could not be reliably passed to
SciTECO scripts for two reasons:
a) "--" arguments are not removed from argv by GOption if it detects
and following option-like argument.
"--" would thus be passed as a script argument which will disable
option parsing in scripts that interpret "--".
b) A script run via the Hash-Bang line "#!...sciteco -m" would
require an explicit "--" to turn of GOption parsing.
However it is __impossible__ to insert after the script file name
on UNIX.
* Therefore, SciTECO now removes leading "--" arguments left over by GOption.
* If possible (Glib >= 2.44), option parsing is performed in strict POSIX
mode which inhibits parsing after the first non-option argument.
This reduces the number of cases where an explicit "--" is required.
* --mung no longer takes an argument. Instead, the first non-option argument
is expected to be the script file name.
This looks weird at first but is more consistent with how other interpeters
work. Once we revise argument passing to scripts, the script name can also
be passed to the script which is more consistent with it being the first
non-option argument.
Also, with strict POSIX parsing, this fixed Hash-Bang lines since
the script file name constructed by the kernel will automatically switch
off option parsing, passing all option-like script arguments uninterpreted
to the script.
* Since we're supporting Glib < 2.44, the Hash-Bang lines are still broken
for certain builds.
Therefore, a wrapper script is installed to libexecdir (it never has to be
executed by users and Hash-Bang lines need absolute paths anyway) which
transparently inserts "--" into the SciTECO command line and should be used
as the interpreter in portable SciTECO scripts.
The wrapper script is generated and points to the exact SciTECO binary
installed. This is important when doing parallel installs of Curses and Gtk
binaries since each one will get its own working wrapper script.
The wrapper-script workaround can be removed once we depend on Glib >= 2.44
(some day...).
* The default /usr/bin/env Hash-Bang lines are no longer used in the
scripts since they are broken anyway (UNIX incl. Linux cannot pass
multiple arguments to the interpreter!).
Scripts that get installed will get a fixed-up Hash-Bang line referring
to the installed SciTECO binary anyway.
* Interface::main() has been renamed to Interface::init() and is optional
now. The Interface::main() method was introduced because of the misconception
that interfaces will find their options in the argv array and have to do
their own parsing.
This is wrong, since their option group already cares about parsing.
Therefore, gtk_init() does not have to called explicitly, too.
|
|
* 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.
|
|
* empty scripts are SciTECO scripts with an Hash-Bang line but no
EOL characters.
They are simply ignored now.
* A test case cannot be added since 1) it's hard to create the test
script with AT_DATA - we'd have to add it to the repo instead.
2) If the bug is not occurring, SciTECO starts into interactive mode
which cannot be inhibited unless the script is __not__ empty.
* Skipping the Hash-Bang line is optimized now, saving one iteration
of the macro just to find out it contains no CR (which is
the most common case).
|
|
escape glob patterns
* globbing is fnmatch(3) compatible, now on every supported platform.
* which means that escaping of glob patterns is possible now.
^ENq has been introduced to ease this task.
* This finally allows you to pass unmodified filenames to EB.
Previously it was impossible to open file names containing glob wildcards.
* this was achieved by moving from GPattern to GRegex as the underlying
implementation.
* The glob pattern is converted to a regular expression before being
compiled to a GRegex.
This turned out to be trickier than anticipated (~140 lines of code)
and has a runtime penalty of course (complexity is O(2*n) over the
pattern length).
It is IMHO still better than the alternatives, like importing
external code from libiberty, which is potentially non-cross-platform.
* Using GRegex also opens the potential of supporting brace "expansions"
later in the form of glob pattern constructs
(they won't actually expand but match alternatives).
* is_glob_pattern() has been simplified and moved to Globber::is_pattern().
It makes sense to reuse the Globber class namespace instead of using
plain functions for functions working on glob patterns.
* The documentation has a new subsection on glob patterns now.
* Testsuite extended with glob pattern test cases
|
|
* mapped to different registers beginning with "~"
* on supported platforms accessing the clipboard is as easy as
X~ or G~.
Naturally this also allows clipboards to be pasted in
string arguments/insertions (^EQ~).
* Currently, Gtk+, PDCurses and ncurses/XTerm are supported.
For XTerm clipboard support, users must set 0,256ED to enable
it since we cannot check for XTerm window ops programmatically
(at least without libX11).
* When clipboard regs exist, the clipboard can also be deemed functional.
This allows macros to fall back to xclip(1) if necessary.
* EOL handling has been moved into a new file eol.c and eol.h.
EOL translation no longer depends on GIOChannels but can be
memory-backed as well.
|
|
* allows expansion of Q-Register contents with UNIX shell quoting
* This especially improves the usefulness of the EC/EG commands as
we can reliably determine that a TECO string (ie. Q-Register)
will end up as a single argument to the spawned process.
A previous workaround was to enclose ^EQ in quotes, but it does
not work e.g. if the register contains the wrong kind of quotes or
other magic shell characters.
* NOTE: In order to be absolutely sure about the runtime behaviour of
EC plus ^E@, you will have to enable UNIX98 shell emulation in portable
macros.
|
|
* the loop counter wasn't properly restored when rubbing out
the loop end command, so when it was reinserted again,
it would still be 1 (since that's the abortion criteria) and
no additional loop iteration was performed.
* simple test case: Try typing 5<%a> then rubout and reinsert ">".
* Fixed by saving the loop counter before modifying it.
There are arguably more efficient ways to do this like only
creating one undo token at the end of the loop -- but that
would require storing the initial loop counter in the LoopContext
and would generally be more tricky.
* The case of infinite loops has been optimized in interactive mode:
Since the loop counter never actually changes, we do not have
to create an undo token per loop iteration.
|
|
* The default command interpreter will thus be inherited from
the operating system. In the case of UNIX from the user's
passwd entry.
E.g. if bash is used, bash extensions can be used immediately
if flag 128 is not set in the ED flags.
* On DOS-like systems there are also alternative interpreters
(e.g. 4NT, 4OS2) that are configurable now.
* At least on UNIX with $SHELL it is not guaranteed that
the interpreter supports the standard command line arguments
like "-c". If they don't, this will cause problems with EC.
Since $SHELL is mapped to a Q-Register, it can however
always be easily customized for SciTECO sessions in the
user's .teco_ini.
|
|
* one would expect function key macros masked for the start
state to work after ^[ ($), but since it has its own
state now, this was broken since f08187e454f56954b41d95615ca2e370ba19667e.
* Similarily command reinsertion would reinsert too much
after $, since the parser wouldn't be in the "real" start state.
* The "escape" state should be handled like the start state
(where new commands can begin)
from the perspective of the user -- the difference is not
even documented, it's an implementation detail.
|
|
* acts like exit(3) -- ie. the program is terminated
immediately but the quit hook (aka SciTECO's atexit()
handlers) will still run.
* for "compatibility" with classic TECOs.
Can also be used as a shorter variant of "-EX$$"
but working from every macro level.
* disallowed in interactive mode to avoid typing it
accidentally.
|
|
optimizationa and additional checks
* undo tokens emitted by the expression stack no longer waste
memory by pointing to the stack implementation.
This uses some ugly C++ constant template arguments but
saves 4 or 8 byte per undo token depending on the architecture.
* Round braces are counted now and the return command $$ will
use this information to discard all non-relevant brace levels.
* It is an error to close a brace when none have been opened.
* The bracing rules are still very liberal, allowing you to
close braces in macros belonging to a higher call frame
or leave them open at the end of a macro.
While this is technically possible, it is perhaps a good
idea to stricten these rules in some future release.
* Loops no longer (ab)use the expression stack to store
program counters and loop counters.
This removes flow control from the responsibility of the
expression stack which is much safer now since we can control
where we jump to.
This also eased implemented proper semantics for $$.
* It is an error to leave loops open at the end of a macro
or trying to close a loop opened in the caller of the macro.
Similarily it is only possible to close a loop from the
current invocation frame.
This means it is now impossible to accidentally jump to invalid
PCs.
* Even though loop context stacks could be attached directly to
the macro invocation frame, this would be inefficient.
Instead there's a loop frame pointer now that is part of the
invocation frame. All frames will reuse the same stack structure.
* Loops are automatically discarded when returning using $$.
* Special aggregating forms of the loop start (":<") and loop
end (":>") commands are possible now and have been implemented.
This improves SciTECO's capability as a stack-oriented language.
It is no longer necessary to write recursive macros to generate
stack values of arbitrary length dynamically or to process them.
* All expression and loop stacks are still fixed-size.
It may be a good idea to implement dynamic resizing (TODO).
* Added some G_UNLIKELYs to Execute::macro(). Should improve
the branch prediction of modern CPUs.
* Local Q-Register tables are allocated on the stack now instead
of on the heap (the bulk of a table is stored on the heap anyway).
Should improve performance of macro invocations.
* Document that "F<" will jump to the beginning of the macro
if there is no loop.
This is not in standard TECO, but I consider it a useful feature.
|
|
* <$$> is faster than jumping to the end of the macro
and enables shorter code for returning values from macros.
* this also replaces $$ as an immediate editing command.
In other words, command line termination is an ordinary command
now. The old behaviour was similar to what classic TECO did.
Classic TECO however had no choice than to track key presses
directly for command line termination as it did not keep track
about the parser state as input was typed.
This led to some glitches in the language. For instance
"FS$$" would terminate the command line, unless the second escape
was typed after backspace, etc. This behaviour is not worth copying
and SciTECO did a better job than that by making sure that at least the
second escape is only effective if it is not part of language syntax.
This still lead to some undesirable cases like "ES...$$$" that would
terminate the command line unexpectedly.
To terminate the command line after something like "FS$$", you will
now have to type "FS$$$$".
* As it is a regular command now - just executed immediately - and
its properties stay close to the macro return behaviour, command line
termination may now not always be performed when $$ is typed even
as a standalone command. E.g. "Ofoo$ !bar!$$ !foo!Obar$" will
curiously terminate the command line now.
* This also means that macros can finally terminate command lines
by using the command line editing commands ({ and }) to insert
$$ into the command line macro.
This is also of interest for function key macros.
* This implementation showed some serious shortcoming in SciTECO's
current parser that yet have to be fixed.
E.g. the macro "@^Ua{<$$>}" is currently unsafe since
loops abuse the expression stack for storing their state and $$
does not touch the expression stack. Calling "Ma>" would actually
continue the loop jumping to the beginning of the command line
since program counters referring to the macro A will be reused!
This cannot be easily solved by checking for loop termination
since being able to return that way from loops is a useful
feature. This is a problem even without loops and $$, e.g. as
in "@^Ua{1,2,3(4,5} Ma)".
Instead, a kind of expression stack frame pointer must be
added to macro invocation stack frames, pointing to the beginning
of the expression stack for the current frame.
At the end of macros or on return, the stack contents of
corresponding to the frame can be discarded while preserving the
immediate arguments at the time of the return or end-of-macro.
This would stabilize SciTECO's macro semantics.
* When a top-level macro returns in batch mode, it would
be a good idea to use the last argument to calculate the
process return code, so it can be set by SciTECO scripts (TODO).
|
|
* test case: "@^Ua{eq.a$}Ma" and rubbing out until "}", reinserting it
* this means that probably a lot of rubout/reinsertion cases were
broken
|
|
|
|
* SciTECO commands are implemented with immediate execution in mind.
Those commands that do need to execute immediately while a string
command is entered, can do so using StateExpectString::process().
For simplicity, the parser just assumed that every input character
should result in immediate execution (if the command supports it
of course).
* This lead to unnecessarily slow execution of commands like <I> or
<S> in batch mode. E.g. a search was always repeated for every
character of the pattern - a N character pattern could result in
N searches instead of one.
Also in interactive mode when executing a macro
or repeating commands in a loop, immediate processing of string arguments
is unnecessary and results in superfluous undo tokens.
* These cases are all optimized now by being informed about
the necessity of providing immediate feedback via State::refresh().
This is used by StateExpectString to defer calling process() as
long as possible.
* For states extending StateExpectString, there is no change since
they can already process arbitrarily long strings.
The optimization is hidden in StateExpectString.
* some allocations are now also avoided in StateExpectString::custom().
|
|
* This is one of the most called functions (although a cheap one),
so having our own inline implementation speeds up things.
Benchmarks have shown that parsing is sped up by at least 4%.
|
|
batch mode
* by using variadic templates, UndoStack::push() is now responsible
for allocating undo tokens. This is avoided in batch mode.
* The old UndoStack::push(UndoToken *) method has been made private
to avoid confusion around UndoStack's API.
The old UndoStack::push() no longer needs to handle !undo.enabled,
but at least asserts on it.
* C++11 support is now required, so variadic templates can be used.
This could have also been done using manual undo.enabled checks;
or using multiple versions of the template with different numbers
of template arguments.
The latter could be done if we one day have to support a non-C++11
compiler.
However since we're depending on GCC 4.4, variadic template use should
be OK.
Clang supports it since v2.9.
* Sometimes, undo token pushing passed ownership of some memory
to the undo token. The old behaviour was relied on to reclaim the
memory even in batch mode -- the undo token was always deleted.
To avoid leaks or repeated manual undo.enabled checking,
another method UndoStack::push_own() had to be
introduced that makes sure that an undo token is always created.
In batch mode (!undo.enabled), this will however create the object
on the stack which is much cheaper than using `new`.
* Having to know which kind of undo token is to be pushed (taking ownership
or not) is inconvenient. It may be better to add static methods to
the UndoToken classes that can take care of reclaiming memory.
* Benchmarking certain SciTECO scripts have shown 50% (!!!) speed increases
at the highest possible optimization level (-O3 -mtune=native -march=native).
|
|
* the canonicalized labels are used in title bars and popups
* title labels and popup labels are selectable.
The latter only makes sense as long as there is no mouse support
for selecting popup entries.
* message bar labels are selectable
* title bars can be styled according to the current document type
(.info-qregister and .info-buffer classes)
* .dirty has been introduced for dirty buffers.
This way, dirty buffer file names can be printed in italics
without hardcoding that behaviour. It can be customized in the user CSS.
* The style of highlighted popup entries is now themeable as well
using the .highlight style class.
|
|
* those strings can contain control characters
* the canonicalized label will automatically escape the non-printable
characters according to the same mapping used elsewhere and shows
them in "reverse" video.
* reverse video is hard to achieve in Gtk, esp. for Pango versions
that don't support transparent foregrounds
* the current implementation does not need dedicated styling for
reverse video characters; but this may be an option in order to
get it right even on older Gtk versions
|
|
|
|
|
|
* this was worked around by using an idle watcher which can
be registered thread-safe.
* this workaround can be reverted once we're single-threaded again.
|
|
* This uses the font and size of STYLE_DEFAULT.
* We cannot just pass the font down to the user CSS.
There are no font variables in Gtk CSS.
Therefore we configure the command line widget directly.
This can still be overwritten by an user CSS.
* Instead of using the deprecated gtk_widget_modify_font(),
we generate CSS. Ugly, but still better than writing our
own style provider.
* Font setting is exposed to the user using a new optional
Q-Reg "lexer.font". The numeric part is the point size
multiplied with 100 (fractional point size).
* Font setting in lexer.auto is skipped in Curses
where it is irrelevant anyway to speed up startup.
* Perhaps the "Monospace" font name is also a good default
value instead of Courier?
fixup
|
|
* this is what the Curses UI does for a long time now
* the popup does NOT cover the info (header) line, as this
would be inconsistent if the header is actually the window's
title bar.
This should perhaps be adapted in the Curses UI as well, so both
UIs look more consistently.
* removed unused InterfaceGtk attribute
|
|
* implemented by exporting the most important Scintilla STYLEs
as CSS variables and defining named widgets for the main UI
components.
* ~/.teco_css will then apply the Scintilla styles to the
Gtk UI.
This file is also for additional tweaks, e.g. enabling
translucency.
* A fallback.css is provided which does just that and is able
to apply the terminal.tes and solarized.tes color schemes.
* Other important aspects of theming like font sizes and names
have not yet been dealt with.
(We may want to apply the corresponding Scintilla settings
to some widgets...)
|
|
* many WMs like Unity or even Awesome WM have problems with client-side
decorations.
Awesome WM for instance does not allow us to move or resize
floating windows with CSDs. Also, the added close button does
not make sense for tiling window managers and since they usually
never show window title bars, CSD brings no advantages at all
on tiling window managers.
* Other window managers might not support CSD at all.
* There is AFAIK no way to detect whether CSDs will be possible
or whether there will be glitches (see Awesome).
* Added command line option --no-csd in the --help-gtk group.
This can be added to desktop shortcuts etc. Later there might
be better ways to configure stuff like that, e.g. when we add
support for scripted UI customizations.
|
|
* the header bar takes the role of the "info" line in the Curses UI.
* even though the current file was already shown in the window title,
this has certain disadvantages:
* does not work well with decoration-less WMs like awesome.
The file name is important information and should always be at the
top of the window. The space in the task list of awesome is usually
not even large enough to show the file name.
* the title bar uses a canonicalized buffer/Q-Register name.
For the header bar we can use custom renderings using Pango
that highlight control characters just like the Curses UI does.
This is currently not implemented.
* An icon is now shown for the current file.
This is the same icon fetching code that gtk-info-popup uses.
We might want to move that code into a separate module, along
with Pango rendering - Gob2 could just as well generate C++ code.
* For Q-Registers, currently no icon is shown (FIXME).
* Currently, the subtitle is used to indicate which type of document
(buffer or q-register) is edited. This could be done using the
icons only, in which case we can disable the subtitles and save
screen space.
* Client-side decorations are known to cause problems with some
WMs and if using them fails, we end up with a titlebar and header
bar. It is probably a good idea to make titlebar installation
configurable, at least via a command-line switch (or perhaps
ED flag?)
|
|
allocation issue
* this is a callback for GtkOverlay's "get-child-position" signal
that allocates a size to the popup.
* cleaner than overwriting the size_allocate method and does not
assume apriori that the popup is part of an overlay.
* the popup was always allocated a few pixels too little height,
resulting the GtkViewbox always scrolling.
Actually it requests a few pixels too little.
We now workaround that by adding a constant value to its
natural height when allocating a position in the overlay.
This is of course a non-portable hack.
|
|
* it is currently never hidden since the popup will always be a few pixels
too small to prevent scrolling.
* makes the GTK popup behave more like the Curses one
|
|
* this has been prepared a long time ago
* the popup widget does not in any way depend on the InterfaceCurses
class and could be used elsewhere.
* common and generic Curses drawing functions required by both the
Curses UI and the CursesInfoPopup widget have been factored out
into curses-utils.cpp (namespace Curses)
* this improved the UI-logic separation and helped in making
interface-curses.cpp smaller
|
|
* the GTK UI uses the first three resolutions for setting the
window icon.
* the 256px version will currently not be installed.
It may however be used later when packaging for Ubuntu.
|
