| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* After installation, SciTECO will therefore start into a more userfriendly mode
even if the user does not create a custom ~/.teco_ini.
It is hoped that this will scare away less of new users, who
are not willing to read through all of the documentation.
Still, users are warned in the absence of ~/.teco_ini.
This warning however, might not be immediately visible, especially
not when running gsciteco without an attached console.
(This will change once I redo the UI and allow a number of messages
to be queued in the message area.)
* Theoretically, you could also just extend fallback.teco_ini from ~/.teco_ini,
but that would require installing it into $SCITECOPATH.
* Since the fallback profile will now be munged automatically
on a wide range of systems, we set up xclip only when detecting X11
($DISPLAY is non-empty).
E.g. when running under Wayland or the Linux console, you still won't
get the clipboard registers, which is probably better than having the
clipboard operations fail once you try to use them.
* xclip is now "suggested" on Debian/Ubuntu.
Unfortunately we cannot pull it in only in the presence of X11.
|
|
* 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.)
|
|
* 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.
|
|
* This is done via the new opener.tes in the standard library.
* Some programs that use $EDITOR expect the +line syntax to work.
* You can copy filename:line:column directly from GCC error messages
and filename:line from grep output.
* Since there may be safe file names beginning with "+" or containing colons,
there needs to be a way to turn this off, especially for scripts that don't
know anything about the filenames to open.
This is done with "--".
Unfortunately, the first "--", that stops parameter processing,
is always removed from the command line and not passed down into TECO land.
This is not a problem for stand-alone scripts,
since the script filename is already stopping option processing, so "--"
would get passed down.
But when calling the profile via `sciteco -- ...`, you could prevent leading
minus signs to cause problems but since the `--` is removed, opener.tes cannot
use it as a hint.
Therefore, we introduced `-S` as a new alternative to `--`, that's always passed
down as `--` (i.e. it is equivalent to "-- --").
In other words, `sciteco -S *` will always open exactly the specified files
without any danger of misinterpreting certain file names.
Should we ever switch to a custom option parsing algorithm, we might preserve
"--" (unless after --mung) and thus get rid of "-S".
* This advanced behavior can be tweaked by the user relatively easily.
In the easiest case, we could replace M[opener] with
<:L;R 0X.f [* @EB/^EN.f/ ]* L>
in ~/.teco_ini to completely disable the special syntax.
|
|
|
|
* The previous convention of !* ... *! are now true block comments,
i.e. they are parsed faster, don't spam the goto table and allow
embedding of exclamation marks - only "*!" terminates the comment.
* It is therefore now forbidden to have goto labels beginning with "*".
* Also support "!!" to introduce EOL comments (like C++'s //).
This disallows empty labels, but they weren't useful anyway.
This is the shortest way to begin a comment.
* All comment labels have been converted to true comments, to ensure
that syntax highlighting works correctly.
EOL comments are used for single line commented-out code, since it's
easiest to uncomment - you don't have to jump to the line end.
This is a pure convention / coding style.
Other people might do it differently.
* It's of course still possible to abuse goto labels as comments
as TECO did for ages.
* In lexing / syntax highlighting, labels and comments are highlighted differently.
* When syntax highlighting, a single "!" will first be highlighted as a label
since it's not yet unambiguous. Once you type the second character (* or !),
the first character is retroactively styled as a comment as well.
|
|
* 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.
|
|
* 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.
|
|
|
|
* When enabled with bit 2 in the ED flags (0,4ED),
all registers and buffers will get the raw ANSI encoding (as if 0EE had been
called on them).
You can still manually change the encoding, eg. by calling 65001EE afterwards.
* Also the ANSI mode sets up character representations for all bytes >= 0x80.
This is currently done only depending on the ED flag, not when setting 0EE.
* Since setting 16,4ED for 8-bit clean editing in a macro can be tricky -
the default unnamed buffer will still be at UTF-8 and at least a bunch
of environment registers as well - we added the command line option
`--8bit` (short `-8`) which configures the ED flags very early on.
As another advantage you can mung the profile in 8-bit mode as well
when using SciTECO as a sort of interactive hex editor.
* Disable UTF-8 checks in 8-bit clean mode (sample.teco_ini).
|
|
* There isn't much we can do anyway.
We can detect if it's Unicode and otherwise default to _some_ codepage.
However, we do not even known which codepage should be preferred.
* This is actually trivial to implement in pure SciTECO.
Having it in the profile gives you the ability to customize the default non-UTF code page.
E.g. if you are working a lot with KOI-8 documents, you could change <1EE> to <204EE>.
* Since the Unicode validity check is a noticable slowdown,
we limit it to the first 1024 bytes.
This speeds up startup significantly compared to checking all codepoints in every document.
|
|
between glyph and byte offsets (refs #5)
* ^E is heavily overloaded and can also be used to check whether a given index is valid
(as it is the same that most movement commands to internally).
Besides that, it is mainly useful for interfacing with Scintilla messages.
* EE takes a code page or 0 for ANSI/ASCII.
Currently all documents and new registers are UTF-8.
There will have to be some kind of codepage inheritance and a single-byte-only mode.
|
|
* Horizontal movements (left/right cursor keys) establish the current column
and vertical movements (up/down) will try to keep on that column.
* This has long been problematic in SciTECO as it requires state that gets
reversed when the command line replacement takes place.
* I experimented with encoding the current horizontal position into the braced
movement operations as in (123C5U$), but I decided that this was clumsy and
I generally did not want these expressions to become even larger.
* Instead I decided to add some minimal support to the C core in the form of 4EJ
which is like a number register only that it does NOT get reversed on rubout.
This is exploited by the fnkeys.tes macros by storing the current position
beyond replacements.
* In theory, this should be a property of the document, but we cannot easily
store custom parameters per document.
So instead, there is just one global variable.
When editing another buffer, it gets reset to .ESGETCOLUMN$$.
sample.teco_ini has been updated.
* The current X position only makes sense in the context of fnkeys.tes, as
TECO commands like <C> are not necessarily "horizonal" movements.
For the same reason, the core does not try to initialize 4EJ automatically
when editing new buffers.
It's entirely left to the TECO macros.
* The commandline replacement is more robust now as it checks braced
expressions at the end of the command line more thorougly.
It will no longer swallow all preceding braced expressions.
Only if they are at least 4 characters in length and end in `C)` or `R)`.
|
|
* The lexer.test.* macros don't work on the unnamed buffer,
so any per-language indention settings etc. could be accidentally
applied to the unnamed buffer.
|
|
* when enabled, it will automatically upper-case all
one or two letter commands (which are case insensitive).
* also affects the up-carret control commands, so they when inserted
they look more like real control commands.
* specifically does not affect case-insensitive Q-Register specifications
* the result are command lines that are better readable and conform
to the coding style used in SciTECO's standard library.
This eases reusing command lines as well.
* Consequently, string-building and pattern match characters should
be case-folded as well, but they aren't currently since
State::process_edit_cmd() does not have sufficient insight
into the MicroStateMachines. Also, it could not be delegated
to the MicroStateMachines.
Perhaps they should be abandoned in favour of embeddedable
regular state machines; or regular state machines with a stack
of return states?
|
|
|
|
* 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.
|
|
* 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.
|
|
* <$$> 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).
|
|
* 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 simplifies profile setup
* should anybody wish to load the default function key macros but
not enable function key support, he/she can still explicitly call
"64,0ED" to disable them again.
|
|
* it makes little sense to keep Scintilla's default for new views
which gives margin 1 (non-folding symbols) a fixed width of 16 pixels.
The interpretation of this width is UI-dependant.
* it is more consistent to disable all margins initially.
this is also the minimalist setup shown when you run e.g. with --no-profile.
* the default look of SciTECO will be more like classic TECOs.
This is also what has been requested in #4.
* sample.teco_ini does no longer have to disable margin 1 explicitly
|
|
* disable ED hook while exuting the "add" hook.
This avoids the "edit" hook being invoked recursively.
* the speed improvement was not measurable, but it also won't
hurt
|
|
* acts as a safe-guard against uninterrupted infinite loops
or other operations that are costly to undo in interactive mode.
If we're out of memory, it is usually too late to react properly.
This implementation tries to avoid OOMs due to SciTECO behaviour.
We cannot fully exclude the chance of an OOM error.
* The undo stack size is only approximated using the
UndoToken::get_size() method.
Other ways to measure the exact amount of allocated heap
(including size fields in every heap object or using sbrk(0) and
similar) are either costly in terms of memory or platform-specific.
This implementation does not need any additional memory per heap
object or undo token but exploits the fact that undo tokens
are virtual already. The size of an undo token is determined
at compile time.
* Default memory limit of 500mb should be OK for most people.
* The current limit can be queried with "2EJ" and set with <x>,2EJ.
This also works interactively (a bit tricky!)
* Limiting can be disabled. In this case, undo token processing
is a bit faster.
* closes #3
|
|
* session.hg sets up the buffer session in the current
Mercurial repository
* session.vcs is a convenience macro that may be used in
profiles to enable buffer sessions per repo for all supported
VCS (Git, Hg and SVN)
|
|
Subversion working copy
* it uses "svn info --xml" since otherwise the output of "svn info" might
be localized.
|
|
automatically when files are given.
this allows you to use sciteco in a Git repository to edit a specific file,
without changing the buffer session. Also useful if SciTECO is used as the GIT_EDITOR
without thrashing the repository's session every time a commit message is edited.
|
|
$SCITECOPATH on Windows
* $SCITECOCONFIG has been introduced, so have a macro-accessible location
for the profile, buffer session etc.
This is set to the program dir on Windows. That way, the config files
will be found, regardless of the current working dir, but it may also
be set up for Unix-like environments on Windows.
* $SCITECOPATH defaults to the program dir + "/lib" now on Windows.
* The default profile is now always called ".teco_ini". Also on Windows.
Platform differences like this would need to be documented.
* The sample teco.ini has been renamed to "sample.teco_ini" for clarity
|
