| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* 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.
|
|
|
|
* use libtool convenience libraries as much as possible
(for all static libraries except Scintilla)
* improves separation of language and user interface implementations
(e.g. the Gtk widgets are not interesting for the rest of SciTECO)
* the Curses popup widget can now be factored out of interface-curses.cpp
* some common CPPFLAGS are now defined by ./configure via AM_CPPFLAGS,
so they don't have to be repeated in each submodule.
* fixed building the Curses UI: GTK_FLOW_BOX_FALLBACK conditional
must always be defined.
|
|
* depend on Gtk+ 3.10. If necessary older versions should also
be supportable. GtkOverlay was already introduced in v3.2
* A fallback for GtkFlowBox is compiled in if the Gtk installation
is too old. This applies even to Ubuntu 14.04 which still runs
Gtk v3.10.
* the threading the Gtk UI is left as it is for the time being
even though the synchronization mechanism has been deprecated.
Alternative approaches have to be tried out and benchmarked.
* Completely revamped the GtkInfoPopup widget.
It is now as powerful as the Curses UI's popup widget.
* A GtkOverlay is used instead of the top-level window hack
in the Gtk2 version.
* GtkFlowBox is used to lay out the columns of the popup.
* I had to work around restrictions of GtkScrolledWindow
by writing my own poor-mans scrolled window which handles
size requests correctly.
* The popup window no longer overflows the screen size,
instead we scroll.
* Scrolling pagewise is finally supported. Wraps at the
end of a list just like the Curses UI.
* Instead of using only two stock icons, we now use
GIO to get file and directory icons for the current theme.
This looks even better.
* The GtkFlowBox allows selections which can be used for mouse
interaction later. But this is not yet implemented.
* Theming of the popup widget and command line is still
not performed correctly.
|
|
of Gtk
* it was necessary to remove the accessibility integration since
I don't want to import a lot of bloat into the SciTECO codebase
* Includes follow the guidelines of external Gtk code now
* internationalization support has been removed
* The "move-cursor" signal uses the generic marshaller now since
we don't want to introduce genmarshal just for that signal
(and it will never be called from a scripting language)
|
|
* this is used as a fallback for installations with Gtk prior
to v3.12
|
|
* when the unnamed file was modified, :EW would just succeed discarding
all changes to the unnamed file.
* Instead now, :EX behaves like the EW$ command on each modified buffer
including the unnamed file.
* In other words, :EX will fail if there is a modified unnamed file
* still refers to #4
|
|
* this allows you to exit and save only those buffers that are modified.
This was not yet possible using macros, since there is currently no way
to query the dirty state of buffers programmatically.
* even if there was, the necessary key presses might be too much for
some users.
* the ability to save all modified buffers has been explicitly requested
by an user in ticket #4.
* the new behaviour is not compatible with classic TECO where EX would
save the current file by default but provides a relatively short way
to do just that.
* updated the documentation: there was also one mistake regarding the
boolean that EX accepts non-colon-modified.
|
|
* it has been proven to be very efficient (at least on Linux/glibc)
|
|
|
|
* class2regexp() and pattern2regexp() now have clear semantics
regarding how they scan over a pattern string
* this bug has probably always been around
* memory leaks could happen in case of exceptions because the
pattern match conversion can itself yield errors.
* now search commands also fail for definitely invalid pattern
match constructs like unsupported ^Ex sequences.
* added some documentation
|
|
|
|
* this practically fixes the delay issues when using
the escape key since 25ms is too short for humans to notice.
Still it should be large enough for all practical terminal
emulators and transmission speeds to get escape sequences
transmitted.
* If the escape delay turns out to be too short, it can still
be overwritten using the (standard ncurses) $ESCDELAY environment
variable.
* fnkeys.tes will still provide the escape surrogate since the
insert key will often be in a better possition on computer
keyboards.
|
|
* we cannot use G_N_ELEMENTS in attribute declarations with Clang
unless declaring C++11. In this case, since the size of the orig_color_table
is fixed anyway, the declaration was simply fixed.
* some reordering was necessary in cmdline.cpp. This should not
have any influence on GCC when optimizations are enabled.
* Scintilla/Scinterm had to be updated as well.
|
|
|
|
|
|
* format_str() will now automatically right-truncate strings (with
formatted control characters) exceeding the window width (or provided
maximum width of formatted characters).
This means that Q-Register names in the info line are now properly
truncated.
* introduced format_filename() which takes care of canonicalizing
control characters in a given filename and truncate the filename
if necessary. Filenames are currently left-truncated since the file
name proper and the directory containing it is more significant
than the directory names closer to the root.
On Windows, we make sure that the drive letter is not truncated.
The truncation rules may have to be further tweaked later.
This feature properly truncated file names in the info line and
in the auto-completion popup.
|
|
* use small values for low precedence
|
|
* SciTECO now has the same operator precedence table as C.
* It is numerically important whether different operators
have the same precedence. E.g. "5*2/4" used to be evaluated
by SciTECO as "5*(2/4)" since division had a higher precedence
than multiplication. Within in real (!) numbers this would
be the expected evaluation order.
Users of other programming languages however would expect
the expression to be evaluated as "(5*2)/4" which makes
a numerical difference when working with integers.
* Operator precedence has been implemented by encoding it
into the enumeration values used to represent different
operators.
Calculating the precedence of a given operator can then
be done very efficiently and elegantly (in our case using
a plain right shift operation).
* documentation updated. We use a precedence table now.
|
|
* Haiku can be handled like UNIX in most respects
since it is POSIX compliant, has a UNIX-like terminal
emulator and uses ncurses.
* still the Glib platform macro is G_OS_HAIKU instead of
G_OS_UNIX, so the preprocessor conditionals had to be adapted.
* the only functional difference between a Haiku and UNIX build
is the default SCITECOCONFIG path.
We use the config path returned by Glib instead of $HOME,
so .teco_ini will be in ~/config/settings on Haiku.
Other UNIX ports appear to use the same conventions.
* Some Haiku-specific restrictions still apply:
* Haiku's terminal is xterm-compatible, but only supports
8 colors. Therefore only the terminal.tes color scheme
can be used and the terminal must be set up to
"Use bright instead of bold text".
* The terminal has artifacts. This appears to be a Haiku
bug and affects other curses applications as well.
* GTK is yet unsupported on Haiku, so there may never be
a GUI port (unless someone writes a QT GUI for SciTECO).
* SciTECO cannot be built with the legacy gcc2 used for
BeOS compatibility on Haiku. This would require too many
changes for an obsolete platform.
BeOS and the x86_gcc2 platform of Haiku will therefore
never be supported.
The PPC and ARM platforms of Haiku should work but are untested.
* a HaikuPorts recipe will be provided for the next regular
SciTECO release. This should hopefully allow installation via
HaikuDepot.
|
|
* the old implementation was totally broken, which was to be expected
* we can at least provide a version that always returns an absolute
path, even though it does not canonicalizes
* fixes e.g. Haiku builds for the time being.
Haiku however is mostly POSIX compliant and could be handled
like UNIX.
* simplified the UNIX implementation of get_absolute_path()
|
|
* there appears to be a bug in Haiku's glib v2.38
g_main_context_unref(). However I could not find a fix
in glib's log.
* as a workaround, simply do not unref the main context.
Memory is reclaimed after program termination anyway.
|
|
* necessary since in SciTECO every operator has a different
precedence. E.g. successive additions/subtractions cannot
be evaluated from left to right (by their associativity).
Perhaps this should be changed.
* subtraction must have a higher precedence than addition,
since (a+b)-c == a+(b-c)
* division must have a higher precedence than multiplication
since (a*b)/c == a*(b/c).
This is not quite true for integer arithmetics.
* this fixes expressions like 5-1+1 which were counterintuitively
evaluated like 5-(1+1)
|
|
* use black on light white as the default popup colors
(e.g. in --no-profile mode). this looks less annoying than
black on light blue and is more often more readable
(since light blue will be rendered quite dark often).
It's no longer necessary to highlight the popup with (distinct)
colors.
Keeping the foreground black ensures that there's a brighter
foreground color for bold entries in case the terminal does
not support bold fonts.
* the `terminal.tes` scheme keeps the default popup style.
However since it uses white on black as the default colors,
this will often still stand out from the message line
(on 16 color terminals).
* `solarized.tes` now uses a similar high-contrast popup style
with either a bright or dark background.
The foreground colors have been chosen so that bright variants
exist for non-bold terminals - although these bright variants
do not stand out very much.
|
|
* InterfaceCurses::Popup has been turned into a proper class.
This made sense since it is more complicated now and allows
us to isolate popup-related code.
This will also ease moving the popup code as a widget into
its own file later (it seems we will need subdirs per interface
anyway).
* the popup is now implemented using curses pads of which pages
are copied into the popup window (to implement cycling through
the list of entries). This simplifies things conceptually.
* instead of a trailing ellipsis, scrollbars are shown if the popup
area is too small to show all entries.
This looks much better and consistent with regard to Scinterm's
scrollbars. Also, the planned GTK+ popup widget rewrite will have
scroll bars, too for cycling through the list of entries.
Therefore, the popup window will now always be the same size
when cycling. This also looks better.
* Borders are drawn around the popup area.
This makes sense since the popup area had to be colored distinctly
just to be able to discern it from the rest of the UI (esp. the
Scintilla view). Now, less annoying colors may be used by default
or set up in color profiles while still maintaining good visibility.
Also, with the borders added, the popup area looks more consistent
when it covers the entire screen.
* Entries that are too long to fit on the screen (e.g. long file names)
are now truncated with a bold/underline ellipsis.
* Use scintilla_noutrefresh() to refresh the Scintilla view.
Since popups have to be refreshed __after__ the Scintilla view,
this improves performance significantly and reduces flickering
when displaying large popups.
|
|
* throws an error now instead of returning 0
* for <A> positions referring to the buffer end are invalid
(unlike many other commands).
* has been broken for a very long time (possibly always?)
|
