| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The ^KMOUSE macro can also change dot and it was possible
to place dot into invisible areas at the end of the document.
|
|
* Set up the folding margin in the currently empty margin column
after the line number.
On Gtk, this meant resetting all the marker symbols and their
foreground/background colors as well as the margin's colors themselves.
This looks like a bug. It's not necessary on Scinterm, which apparently
uses the default/linenumber styles by default.
Perhaps we should try upgrading Scintilla?
* The folding state is considered not to be directly controlled by the
language (just like the scroll position and zoom level). That's why
we can directly control it by clicking on the margin column.
* F1 can be used to toggle all folds globally.
* The only support within the C core necessary for folding is to make
sure that the current line is unfolded after every keypress.
* We might add custom folding commands to the language later on
(e.g. F+, F-). In this case, the key macros will have to be changed
of course.
|
|
|
|
* There are cases, especially where the entire buffer is piped through some
external process or when removing and reinserting large parts of the buffer,
that dot changes very little, but the vertical scrolling position gets resets.
This is especially noticable with the macro @^U{[: HECcat$ ]:},
but also with M#cf (clang-format wrapper from "Useful macros").
* We now try to preserve the vertical position ("first visible line")
before scrolling caret.
|
|
This is hardcoded, but in line with the current defaults from
fnkeys.tes.
|
|
* Both the WinGUI and Wincon variants have their own idiosyncrasies:
* WinGUI ignores `mouseinterval(0)` and may report BUTTONX_CLICKED
for very quick clicks.
Therefore we now emulate separate PRESSED/RELEASED events.
* Wincon does not report BUTTONX_RELEASED at all.
Therefore we still enable click detection, so that fnkeys.tes will
work at least partially.
Therefore we also enable REPORT_MOUSE_POSITION, so that
right-click-dragging will work.
This should still be fixed in PDCurses upstream, though.
* See also https://github.com/Bill-Gray/PDCursesMod/issues/330
|
|
* The old heuristics - scroll if dot changes after key press -
turned out to be too simplistic.
They broke the clang-format macro (M#cf), which left the view at the
top of the document since the entire document is temporarily erased.
Other simplified examples of this bug would be:
@^Um{[: HECcat$ ]:} Mm
Or even: @^Um{[: H@X.aG.a ]:} Mm
* Actually, the heuristics could be tricked even without deleting any
significant amount of text from the buffer.
The following test case replaces the previous character with a linefeed
in a single key press:
@^Um{-DI^J$} Mm
If executed on the last visible line, dot wouldn't be scrolled into the view
since it did not change.
* At the same time, we'd like to keep the existing mouse scroll behavior from
fnkeys.tes, which is allowed to scroll dot outside of the visible area.
Therefore, dot is scrolled into view always, except after mouse events.
You may have to call SCI_SCROLLCARET manually in the ^KMOUSE macro,
which is arguably not always straight forward.
* Some macros like M#cf may still leave the vertical scrolling position
in unexpected positions. This could either be fixed by eradicating all
remaining automatic scrolling from Scintilla or by explicitly restoring
the vertical position from the macro (FIXME).
* This was broken since the introduction of mouse support,
so it wasn't in v2.3.0.
|
|
backgrounds
* Unfortunately we cannot use `wbkgdset(win, A_REVERSE)` if we plan to
use reverse text on this background, i.e. if we want to cancel out the background A_REVERSE.
* SciTECO therefore no longer uses background attributes, but only foreground attributes.
When setting a reverse text, we XOR A_REVERSE into the previous attributes.
* This fixes control characters especially in the info line and popups, as well as rendering
of the popup scroll bars.
* The command-line should now be rendered properly even on a dark-on-bright color theme
(which does not yet exist).
|
|
* SCI_COLOR_PAIR() is now a function teco_color_pair() since it also became
an inline function in Scinterm.
|
|
* If the background color would be non-black, render text in reverse
video. ncurses doesn't do that automatically.
* Fixes rendering under historical terminals like VT100 and VT240,
but also all of the monochrome versions of modern emulators in terminfo.
* This also improves the situation when $TERM is set to something conservative,
e.g. when connecting via RS232.
* Scinterm is temporarily changed to my own fork, which already contains
a monochrome patch.
|
|
* As an alternative to OSC-52, which is rarely supported by terminal emulators.
* Makes the new mouse support much more useful since you rely on good builtin
clipboard support. You can no longer e.g. just double-click a word to copy it into
the "primary" selection as terminal emulators do by default.
* Set $SCITECO_CLIPBOARD_SET/GET e.g. to xclip, way-copy, pbcopy or some wrapper script.
* This is currently using POSIX-specific popen() API, so it behaves a bit different
to command execution via EC/EG.
I am not sure if it's worth rewriting with the GSpawn-API, since it will be used
only on POSIX anyway and a GSpawn-based implementation is likely to be a bit larger.
* Should there be some small command-line utility for interacting (esp. pasting) via OSC-52,
built-in OSC-52 support could well be removed from SciTECO.
Currently, I know only of https://github.com/theimpostor/osc/ and it requires
very recent Go compilers. (I still haven't tested it. Quite possibly, pasting when run as
a piped command is impossible.)
|
|
(or generally when keeping it on screen even unchanged)
* Turns out that updating the hardware cursor - which is not displayed anyway - would cause premature
screen updates in teco_interface_refresh(), thus causing flickering, for instance
when quickly cycling through the auto completion popup.
Or even just when clicking its borders which does not change it.
* Touching the popup window is actually important and expected since
Scinterm is also touching its window by completely redrawing it.
Touching the popup window makes sure, it's still copied into newscr and overlaps
the Scintilla view even if the popup did not change - e.g. when pressing an unassigned
function key or clicking on the popup borders.
|
|
* Curses allows scrolling with the scroll wheel at least
if mouse support is enabled via ED flags.
Gtk always supported that.
* Allow clicking on popup entries to fully autocomplete them.
Since this behavior - just like auto completions - is parser state-dependant,
I introduced a new state method (insert_completion_cb).
All the implementations are currently in cmdline.c since there is some overlap
with the process_edit_cmd_cb implementations.
* Fixed pressing undefined function keys while showing the popup.
The popup area is no longer redrawn/replaced with the Scintilla view.
Instead, continue to show the popup.
|
|
* Fixes scrolling with default ^KMOUSE macro from fnkeys.tes which adjusts
the scroll position without changing dot.
The unconditional SCI_SCROLLCARET would effectively prevent scrolling to any position
that does not contain dot.
|
|
* You need to set 0,64ED to enable mouse processing in Curses.
It is always enabled in Gtk as it should never make the experience worse.
sample.teco_ini enables mouse support, since this should be the new default.
`sciteco --no-profile` won't have it enabled, though.
* On curses, it requires the ncurses mouse protocol version 2, which will
also be supported by PDCurses.
* Similar to the Curses API, a special key macro ^KMOUSE is inserted if any of the supported
mouse events has been detected.
* You can then use -EJ to get the type of mouse event, which can be used
with a computed goto in the command-line editing macro.
Alternatively, this could have been solved with separate ^KMOUSE:PRESSED,
^KMOUSE:RELEASED etc. pseudo-key macros.
* The default ^KMOUSE implementation in fnkeys.tes supports the following:
* Left click: Edit command line to jump to position.
* Ctrl+left click: Jump to beginning of line.
* Right click: Insert position or position range (when dragging).
* Double right click: insert range for word under cursor
* Ctrl+right click: Insert beginning of line
* Scroll wheel: scrolls (faster with shift)
* Ctrl+scroll wheel: zoom (GTK-only)
* Currently, there is no visual feedback when "selecting" ranges
via right-click+drag.
This would be tricky to do and most terminal emulators do not appear
to support continuous mouse updates.
|
|
|
|
|
|
* g_utf8_get_char_validated() returns -2 for null-bytes (sometimes!?)
|
|
This is a purely cosmetic change.
|
|
* this works by embedding the SciTECO parser and driving it always (exclusively)
in parse-only mode.
* A new teco_state_t::style determines the Scintilla style for any character
accepted in the given state.
* Therefore, the SciTECO lexer is always 100% exact and corresponds to the current
SciTECO grammer - it does not have to be maintained separately.
There are a few exceptions and tweaks, though.
* The contents of curly-brace escapes (`@^Uq{...}`) are rendered as ordinary
code using a separate parser instance.
This can be disabled with the lexer.sciteco.macrodef property.
Unfortunately, SciTECO does not currently allow setting lexer properties (FIXME).
* Labels and comments are currently styled the same.
This could change in the future once we introduce real comments.
* Lexers are usually implemented in C++, but I did not want to draw in C++.
Especially not since we'd have to include parser.h and other SciTECO headers,
that really do not want to keep C++-compatible.
Instead, the lexer is implemented "in the container".
@ES/SCI_SETILEXER/sciteco/ is internally translated to SCI_SETILEXER(NULL)
and we get Scintilla notifications when styling the view becomes necessary.
This is then centrally forwarded to the teco_lexer_style() which
uses the ordinary teco_view_ssm() API for styling.
* Once the command line becomes a Scintilla view even on Curses,
we can enabled syntax highlighting of the command line macro.
|
|
* g_assert() apparently does not reference the expression when assertions are disabled
in contrast to glibc's assert()
|
|
|
|
* Has been observed on PDCursesMod/WinGUI when pressing CTRL+Shift+6 on an US layout.
I would expect code 30 (^^) to be inserted, instead PDCurses reports two keypresses (6^^).
The first one is now filtered out since this will not be fixed upstream.
See also https://github.com/Bill-Gray/PDCursesMod/issues/323
* Since AltGr on German layouts is reported as CTRL+ALT, we must be careful not to filter those
out as well.
* This is active on all PDCurses variants - who knows which other platforms will behave similarily.
* You still cannot insert code 0 via CTRL+@ since PDCurses doesn't report it, but ncurses does not allow that either.
This _could_ be synthesized by evaluating the modifier flags, though.
|
|
* Fixes the test suite on PDcurses/Win32 and therefore CI builds.
* Should be necessary on UNIX as well since later on, we would access
cmdline_window, which is not yet initialized.
I didn't see any errors in Valgrind, though.
|
|
* Apparently, netbsd-curses overwrites the escdelay on initscr() (if $ESCDELAY is not set),
so we have to apply the default 25ms after screen initialization.
* The info line is not drawn correctly on netbsd-curses, but only on st/simpleterm.
I assume this is just a shortcoming of the included terminfo entry.
|
|
* added TECO_ERROR_CLIPBOARD for all clipboard-related errors
|
|
* The XTerm version is still checked if we detect running under XTerm.
* Actually, the XTerm implementation is broken for Unicode clipboard contents.
* Kitty supports OSC-52, but you __must__ enable read-clipboard.
With read-clipboard-ask, there will be a timeout.
But we cannot read without a timeout since otherwise we would hang indefinitely
if the escape sequence turns out to not work.
* For urxvt, I have hacked an existing extension:
https://gist.github.com/rhaberkorn/d7406420b69841ebbcab97548e38b37d
* st currently supports only setting the clipboard, but not querying it.
|
|
* This is especially important on platforms, requiring the wgetch()
poll workaround to detect CTRL+C (PDCurses/WinGUI).
wgetch(cmdline_window) would implicitly wrefresh(cmdline_window),
which resulted in additional flickering when pressing function keys.
This is no longer so important since key macros are processed
as an unity and the cmdline will be updated only after processing
all of the characters contained in them, ie. only once after the key press.
Still, there could have still been unwanted side effects.
At the very least, wgetch(input_pad) should be faster.
* The XTerm clipboard implementation was getch()ing on stdscr,
so potentially suffered from the same problem.
It should be tested again.
* Since keypad() is now always enabled even on netbsd-curses.
I assume that the function key processing bug in netbsd-curses
has been fixed by now. We are not building any releases with
netbsd-curses. But it should be retested.
* It does not resolve all flickering issues on PDCurses/WinGUI.
Both the command line and the Scintilla view still flicker near
the cursor. See
https://github.com/Bill-Gray/PDCursesMod/issues/322
|
|
* Turns out that "%C" in wprintw() does not work with non-ANSI chars.
* We still don't want to introduce the Curses widechar API,
so I added teco_curses_add_wc() as a replacement for wadd_wch().
|
|
* Practically requires one of the "Nerd Font" fonts,
so it's disabled by default.
Add 0,512ED to the profile to enable them.
* The new ED flag could be used to control Gtk icons as well,
but they are left always-enabled for the time being.
Is there any reason anybody would like to disable icons in Gtk?
* The list of icons has been adapted and extended from exa:
https://github.com/ogham/exa/blob/master/src/output/icons.rs
* The icons are hardcoded as presorted lists,
so we can binary search them.
This could change in the future. If there is any demand,
they could be made configurable via Q-Registers as well.
|
|
* ALL keypresses (the UTF-8 sequences resulting from key presses) can now be remapped.
* This is especially useful with Unicode support, as you might want to alias
international characters to their corresponding latin form in the start state,
so you don't have to change keyboard layouts so often.
This is done automatically in Gtk, where we have hardware key press information,
but has to be done with key macros in Curses.
There is a new key mask 4 (bit 3) for that purpose now.
* Also, you might want to define non-ANSI letters to perform special functions in
the start state where it won't be accepted by the parser anyway.
Suppose you have a macro M→, you could define
@^U[^K→]{m→} 1^_U[^K→]
This effectively "extends" the parser and allow you to call macro "→" by a single
key press. See also #5.
* The register prefix has been changed from ^F (for function) to ^K (for key).
This is the only thing you have to change in order to migrate existing
function key macros.
* Key macros are enabled by default. There is no longer any way to disable
function key handling in curses, as I never found any reason or need to disable it.
Theoretically, the default ESCDELAY could turn out to be too small and function
keys don't get through. I doubt that's possible unless on extremely slow serial lines.
Even then, you'd have to increase ESCDELAY and instead of disabling function keys
simply define an escape surrogate.
* The ED flag has been removed and its place is reserved for a future mouse support flag
(which does make sense to disable in curses sometimes).
fnkeys.tes is consequently also enabled by default in sample.teco_ini.
* Key macros are handled as an unit. If one character results in an error,
the entire string is rubbed out.
This fixes the "CLOSE" key on Gtk.
It also makes sure that the original error message is preserved and not overwritten
by some subsequent syntax error.
It was never useful that we kept inserting characters after the first error.
|
|
The following rules apply:
* All SciTECO macros __must__ be in valid UTF-8, regardless of the
the register's configured encoding.
This is checked against before execution, so we can use glib's non-validating
UTF-8 API afterwards.
* Things will inevitably get slower as we have to validate all macros first
and convert to gunichar for each and every character passed into the parser.
As an optimization, it may make sense to have our own inlineable version of
g_utf8_get_char() (TODO).
Also, Unicode glyphs in syntactically significant positions may be case-folded -
just like ASCII chars were. This is is of course slower than case folding
ASCII. The impact of this should be measured and perhaps we should restrict
case folding to a-z via teco_ascii_toupper().
* The language itself does not use any non-ANSI characters, so you don't have to
use UTF-8 characters.
* Wherever the parser expects a single character, it will now accept an arbitrary
Unicode/UTF-8 glyph as well.
In other words, you can call macros like M§ instead of having to write M[§].
You can also get the codepoint of any Unicode character with ^^x.
Pressing an Unicode character in the start state or in Ex and Fx will now
give a sane error message.
* When pressing a key which produces a multi-byte UTF-8 sequence, the character
gets translated back and forth multiple times:
1. It's converted to an UTF-8 string, either buffered or by IME methods (Gtk).
On Curses we could directly get a wide char using wget_wch(), but it's
not currently used, so we don't depend on widechar curses.
2. Parsed into gunichar for passing into the edit command callbacks.
This also validates the codepoint - everything later on can assume valid
codepoints and valid UTF-8 strings.
3. Once the edit command handling decides to insert the key into the command line,
it is serialized back into an UTF-8 string as the command line macro has
to be in UTF-8 (like all other macros).
4. The parser reads back gunichars without validation for passing into
the parser callbacks.
* Flickering in the Curses UI and Pango warnings in Gtk, due to incompletely
inserted and displayed UTF-8 sequences, are now fixed.
|
|
* the locale must be initialized very early before g_option_context_parse()
* will allow UTF-8 characters in the test suite
|
|
* All non-ASCII characters are inserted as Unicode.
On Curses, this also requires a properly set up locale.
* We still do not need any widechar Curses, as waddch() handles
multibyte characters on ncurses.
We will see whether there is any Curses variant that strictly requires
wadd_wch().
If this will be an exception, we might keep both widechar and non-widechar
support.
* By convention gsize is used exclusively for byte sizes.
Character offsets or lengths use int or long.
|
|
|
|
* Since Scintilla no longer automatically scrolls the caret (see 941f48da6dde691a7800290cc729aaaacd051392),
the caret wouldn't always end up in the view on startup.
* Added teco_interface_refresh() which includes SCI_SCROLLCARET and
is invoked on startup. This helps with the Curses backend.
It also reduces code redundancies.
* On Gtk, the caret cannot be easily scrolled on startup as long as no size is allocated
to the window, so we also added a size-allocate callback to the
window's event box. Sizes are less often allocated to the event box than to the
window itself for some strange reason.
|
|
* teco_interrupt() turned out to be unsuitable to kill child processes (eg. when <EB> hangs).
Instead, we have Win32-specific code now.
* Since SIGINT can be ignored on UNIX, pressing CTRL+C was not guaranteed to kill the
child process (eg. when <EB> hangs).
At the same time, it makes sense to send SIGINT first, so programs can terminate gracefully.
The behaviour has therefore been adapted: Interrupting with CTRL+C the first time will kill
gracefully. The second time, a more agressive signal is sent to kill the child process.
Unfortunately, this would be relatively tricky and complicated to do on Windows, so CTRL+C will always
"hard-kill" the child process.
* Moreover, teco_interrupt() killed the entire process on Windows when called the second time.
This resulted in any interruption to terminate SciTECO unexpectedly when tried the second time on Gtk/Win32.
* teco_sigint_occurred renamed to teco_interrupted:
There may be several different sources for setting this flag.
* Checking for CTRL+C on Gtk involves driving the main event loop repeatedly.
This is a very expensive operation. We now do that only every 100ms. This is still sufficient since
keyboard input comes from humans.
This optimization saves 75% runtime on Windows and 90% on Linux.
* The same optimization turned out to be contraproductive on PDCurses/WinGUI.
|
|
PDCurses/WinGUI
* we can neither display, nor parse Unicode characters properly, so this does not worsen anything
* makes it harder to confuse the parser as long as we do not support Unicode.
* behaves like on Gtk: pressing a non-ASCII char will simply be ignored
* Most importantly, this fixes crashes on PDCurses/WinGUI.
It apparently couldn't handle the negative integers that resulted from passing a value >= 0x80 <= 0xFF
into gchar (which is a signed integer).
Changing everything into guchar is not worth the effort - we need full Unicode support anyway.
|
|
Scintilla now
* The patch avoids all automatic scrolling consistently, including in SCI_UNDO.
This speads up Undo (especially after interruptions).
* Also, the patch disables a very costly and pointless (in SciTECO) algorithm that
effectively made <Ix$> uninterruptible.
* Effectively reverts large parts of 8ef010da59743fcc4927c790f585ba414ec7b129.
I have never liked using unintuitive Scintilla messages to avoid scrolling.
|
|
* actually everything is updated to their current HEADs but the aforementioned versions are close.
* Scintilla uses threads now, so we added checks for pthread.
To be on the safe side, we imported AX_PTHREAD from the Autoconf archives.
The flags are kept out of the ordinary build system, though and used only for compiling Scintilla
and for linking.
SciTECO may also use threads, but via Glib.
* Scinterm removed SCI_COLOR_PAIR(), so we re-added it to src/interface-curses/interface.c.
* There is an Asciidoc lexer now.
* The <Ix$> interruption bug (see TODO) is not fixed by this upgrade.
Perhaps the Mac OS version runs better now. Feedback is needed (refs #12).
|
|
|
|
* allows us to get rid of some workarounds
* the workarounds themselves required relatively recent PDCursesMod
versions, so we can just as well bump the version yet another time.
We are probably the only ones building it (via Github actions) anyway.
* With v4.3.4 you should be able to link dynamically, but we are still
linking statically for nightly builds to keep binary sizes small.
Unfortunately, the glib builds shipping with MinGW still have
dynamically linked helper executables.
|
|
workaround
* The keyboard hook required polling as well and was actually much less performant
than the generic getch() polling fallback.
Furthemore it did at least not work on Wine.
* We instead now release the WinGUI-internal mutex and yield the thread giving
it some time to process new key presses.
* This workaround is temporary and will probably be part of the the next PDCursesMod-release
(v4.3.4). We still want to support the latest MSYS/MinGW version though which is
currently at v4.3.2.
The fix will also currently only work when statically linking in libpdcurses_wingui.a.
This is what we do for nightly builds.
See also https://github.com/Bill-Gray/PDCursesMod/issues/197
* Once the fix is released upstream and into MSYS, we should probably bump our
minimal required PDCursesMod version.
The color-table workaround (cf9ffc0cec0d2e55930238d1752209bca659c96d) can then also be removed.
* We should also consider dropping official support for the classic PDCurses and support
only PDCursesMod - this will allow us to simplify interfaces-curses/interface.c a bit.
Support for classic PDCurses is probably broken by now anyway and trying to support it
is just too much.
|
|
|
|
* PDCursesMod is now the recommended PDCurses variant
* you should use at least v4.3.2 since earlier versions have problems
inserting CTRL+C and CTRL+V.
* We now check for PDC_get_version() since initscr() was name-mangled at least
for some time. The maintainers have now reverted to name-mangling endwin(),
we still check for PDC_get_version() as it is probably safer in the future.
* Properly define PDC_FORCE_UTF8 now.
* We no longer have to check for PDC_set_resize_limits() since PDCursesMod
now defines its own macro __PDCURSESMOD__ in curses.h.
|
|
* This is already fixed upstream, but we still include the workaround, so we can
build with the current MSYS package and during CI.
|
|
* Due to regressions, the Control handler needs to be installed later
(PDCursesMod installs its own control handler).
* We no longer have to manually set the control mode - at least on PDCursesMod/WinCON.
It's not worth keeping the workaround for the original PDCurses.
* For WinGUI neither the control handler, nor the polling-fallback will work,
therefore we introduced yet another version based on keyboard hooks.
See https://github.com/Bill-Gray/PDCursesMod/issues/197
This version may even become the default on all Win32-ports but I
need to think this through more thorougly.
|
|
* Using ungetch() was of course broken and could easily result in hangs as wgetch()
would never return ERR.
* This wastes some bytes on platforms that do not need the
teco_interface_is_interrupted() fallback.
* introduced teco_interface_blocking_getch()
* FIXME: This is still way too slow on PDCurses/GUI on Windows but
this can potentially be fixed upstream.
|
|
to detect interactive/batch mode
* Adds support for CTRL+C interruptions on Curses variants like PDCurses/GUI and XCurses.
This also affects the current Win32 nightly builds which should now support CTRL+C interruptions.
* The fallback is of course less efficient than the existing platform optimizations (existing for
UNIX and Win32 console builds) and slows down parsing in interactive mode.
* Use teco_interface.cmdline_window consistently to detect interactive mode.
This may theoretically speed up SciTECO code execution slightly on shutdown.
|
|
* The C standard actually forbids this (undefined behaviour) even though
it seems intuitive that something like `memcpy(foo, NULL, 0)` does no harm.
* It turned out, there were actual real bugs related to this.
If memchr() was called with a variable that can be NULL,
the compiler could assume that the variable is actually always non-NULL
(since glibc declares memchr() with nonnull), consequently eliminating
checks for NULL afterwards.
The same could theoretically happen with memcpy().
This manifested itself in the empty search crashing when building with -O3.
Test case:
sciteco -e '@S//'
* Consequently, the nightly builds (at least for Ubuntu) also had this bug.
* In some cases, the passed in pointers are passed down from the caller but
should not be NULL, so I added runtime assertions to guard against it.
|
