| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* Highlights both 1st level and 2nd level quotes and signatures.
* This also sets the edge to 78 columns, as is recommended for email and
enables word wrapping.
The edge mode is not set, since it kind of looks ugly in Scinterm.
* Helps when using SciTECO as the email editor for instance in the
Aerc mail client.
* Unfortunately, we cannot set up Scintilla to automatically break words
after 78 columns (or perhaps that's a good thing).
You can use the M#rf reformat-paragraph macro to reflow paragraphs
before sending the mail.
This will take the edge column into account even if no edge mode is set.
|
|
* This has __always__ been broken.
It's been especially annoying when pressing `Y` at the end of a line with trailing whitespace
since the linebreak would also be deleted.
This was because `Y` always deleted the entire word or non-word character-span.
This was inconsistent with `V`.
* We now use SCI_WORDSTART|ENDPOSITION instead of the keyboard commands.
It therefore also requires less Scintilla messages (4+2*n vs. 4+4*n).
Most importantly, we can now check for errors before changing the buffer,
so there is no need to undo anything in case of errors.
This should always be the preferred strategy.
* Added test case.
|
|
* 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.
|
|
* 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.
|
|
Also makes sense since all other GObject classes are in separate files.
|
|
* The old implementation would scroll only once for the file first opened and too early.
As a result, opening via `sciteco file:number` did not always scroll to the correct position.
Also, `?` would usually not scroll the topic into view.
* Instead, we now always scroll in all views, but only if the size allocation changed.
This ensures, we can still scroll with the mouse wheel.
* Therefore, we have to store the current size allocation per view.
Instead of allocating a separate heap object, I decided to subclass the Scintilla GTK class.
* Some explicit casts are still necessary since teco_view_t is typedefed
to `struct teco_view_t`, but we cannot easily rename the GObject instance structure.
|
|
the popup entries
* By default, use the "text" cursor - this is the default Scintilla cursor, but
inhibited by the GtkEventBox I used to catch all input events.
* When processing input events, the cursor is changed to "wait".
This is done with a small delay in order to avoid flickering during normal typing.
The cursor is only changed after 100ms of activity, i.e. only when executing long loops
or external programs.
* We use the raw GSource API since it's tricky to work with source ids if the
source could be removed in the meantime.
* The popup entries' cursor is also changed to "pointer" (hand) to give a hint that
it can be clicked.
|
|
* Popup entries are added with expanded directory names, so we have to skip the
expanded directory names from the clicked popup entries.
|
|
* 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.)
|
|
Environment variables will of course never contain null-bytes.
However you can always set them later on from TECO code and include nulls.
We therefore everywhere check for null-bytes in all registers used as null-terminated strings
to avoid unexpected behavior.
|
|
* Test case: @EQa// @?/EX/ -- Rubout should return you to the Q-Register view.
* The test suite has been extended.
Unfortunately we cannot currently directly check whether we're editing a Q-Register.
But we add a magic number of characters to the Q-Register, that we can check afterwards.
|
|
* At the SciTECO API level (-nEJ), there are no double clicks.
We must therefore ignore the GDK_2BUTTON_PRESS and GDK_3BUTTON_PRESS events,
that are delivered when GTK detects double or triple clicks.
They are only sent in addition to GDK_BUTTON_PRESS, so it's safe to
simply ignore them.
* This was causing spurious RELEASED events, which were confusing the ^KMOUSE
macro from fnkeys.tes, causing the wrong buffer range to be inserted into the
command line.
|
|
(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.
|
|
popup window
|
|
* 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.
|
|
* Allowing label redefinitions might have been useful when used as comments,
since you will want to be able to define arbitrary comments.
However as flow control constructs, this introduced a certain ambiguity since
gotos might jump to different locations, depending on the progression
of the parser.
* On the other hand, making label redefinition an error might disqualify labels as
comments when writing or porting classic TECO code.
Therefore, it has been made a warning as a compromise.
* Added test case
|
|
Analoguous to :EX, but always saves the file like EW$, not only if it's dirty.
|
|
* This is not simply determined at compile-time but queries the concrete path
at least on Windows and OS X.
* The Windows implementation is kind of hacky and relies on undocumented behavior.
It's also not even tested yet!
* On Linux and FreeBSD completions will always be case-sensitive as they used to be.
There does not appear to be any API to query case sensitivity of a given path or even
the entire file system.
At most, we could white-list a number of case-insensitive file systems.
|
|
|
|
* 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.
|
|
* g_utf8_get_char_validated() returns -2 for null-bytes (sometimes!?)
|
|
* Apparently g_utf8_get_char_validated() sometimes(!) returns -2 for null-characters,
so it was considered an invalid byte sequence.
* What's strange and unexplainable is that other uses of the function, as are behind nA and nQq,
did not cause problems and returned 0 for null-bytes.
* This also fixes syntax higlighting of .teco_session files which use the null-byte as the
string terminator.
(.teco_session files are not highlighted automatically, though.)
|
|
This is a purely cosmetic change.
|
|
characters)
* The teco_qreg_vtable_t::get_string() method should support returning the
length optionally (may be NULL).
This already worked with teco_doc_get_string(), even though it wasn't documented,
and therefore didn't cause problems with regular Q-Registers.
|
|
* @ES/SCI_SETILEXER/lib^@name/ now opens the lexer <name> in library <lib>.
* You need to define the environment variable $SCITECO_SCINTILLUA_LEXERS to point
to the lexers/ subdirectory (containing the *.lua files).
Perhaps this should default to the dirname of <lib>?
* The semantics of SCI_NAMEOFSTYLE have been changed:
It now returns style ids when given style names, so you can actually write
Scintillua lexer *.tes files.
This will be superfluous if we had a way to return strings from Scintilla messages into
Q-Registers, e.g. 23@EPq/SCI_NAMEOFSTYLE/.
* We now depend on gmodule as well, but it should always be part of glib.
It does not change the library dependencies of any package.
It might result in gmodule shared libraries to be bundled in the Win32 and Mac OS
packages if they weren't already.
|
|
line-character index
* checks for character consistency (of UTF-8 byte sequences) were slowing down things significantly in Scintilla
* It got even worse if the file indeed contained non-ANSI codepoints as reading in chunks of 1024
would sometimes mean that incomplete byte sequences would be read.
Some large 160mb test files wouldn't load even after minutes.
They now load in seconds.
* This does NOT yet solve the slowdowns when operating on very long lines.
|
|
* I.e. you can now write FK...$^YD to delete up to AND the matched pattern.
|
|
as a separate command)
|
|
"identifier" to enable lexing in the container
* SCI_SETILEXER(NULL) is not a reliable way to do that since
that's the default for all views.
* This was breaking the git.tes lexer for instance and was unnecessarily
driving teco_lexer_style() on plain-text documents.
* Since we currently do not implement the ILexer5 C++ interface
and teco_view_t is just a pointer alias, we are abusing the view's "identifier" instead.
This is probably sufficient, as long as there is only one lexer "in the container".
Otherwise, there should perhaps be a single C++ class that does nothing but
wrapping a callback into an ILexer5 object with a C ABI.
|
|
* We don't actually have to negate ^S results after FK.
For deleting the matched pattern, you can use ^YD or -^SD.
|
|
* 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()
|
|
* This would crash if <EB> opened more than one file, e.g. EB*.c$.
The reason is that teco_current_doc_undo_edit() must be called before every teco_ring_edit().
* Unfortunately, this is not reproduceable with
sciteco --no-profile --fake-cmdline '@EB"foo*.txt"{HK}'
since the crashes actually happen when printing messages in interactive mode.
That's why no test case has been added.
|
|
* As known from DEC TECO, but extended to convert absolute positions to line numbers as well.
:^Q returns the current line.
* Especially useful in macros that accept line arguments,
as it is much shorter than something like
^E@ES/LINEFROMPOSITION//+Q.l@ES/POSITIONFROMLINE//:^E-.
* On the other hand, the fact that ^Q checks the line range means we cannot
easily replace lexer.checkheader with something like
[:J 0,^Q::S...$ ]:
Using SCI_POSITIONFROMLINE still has the advantage that it returns `Z` for out-of-bounds ranges
which would be cumbersome to write with the current ^Q.
* Perhaps there should be a separate command for converting between absolute lines and positions
and :^Q should be repurposed to return a failure boolean for out-of-range values?
* fnkeys.tes could be simplified.
|
|
::FS as well)
* The colon modifier can now occur 2 times.
Specifying `@` more than once or `:` more than twice is an error now.
* Commands do not check for excess colon modifiers - almost every command would have
to check it. Instead, a double colon will simply behave like a single colon on most
commands.
* All search commands inherit the anchored semantics, but it's not very useful in some combinations
like -::S, ::N or ::FK.
That's why the `::` variants are not documented everywhere.
* The lexer.checkheader macro could be simplified and should also be faster now,
speeding up startup.
Eventually this macro can be made superfluous, e.g. by using 1:FB or 0,1^Q::S.
|
|
* Can be freely combined with the colon-modifier as well.
:@Xq cut-appends to register q.
* This simply deletes the given buffer range after the copy or append operation
as if followed by another <K> command.
* This has indeed been a very annoying missing feature, as you often have to retype the
range for a K or D command.
At the same time, this cannot be reasonably solved with a macro since macros
do not accept Q-Register arguments -- so we would have to restrict ourselves to one or a few
selected registers.
I was also considering to solve this with a special stack operation that duplicates the
top values, so that Xq leaves arguments for K, but this couldn't work for cutting lines
and would also be longer to type.
* It's the first non-string command that accepts @.
Others may follow in the future.
We're approaching ITS TECO madness levels.
|
|
lengths (refs #27)
* Allows storing pattern matches into Q-Registers (^YXq).
* You can also refer to subpatterns marked by ^E[...] by passing a number > 0.
This is equivalent to \0-9 references in many programming languages.
* It's especially useful for supporting TECO's equivalent of structural regular expressions.
This will be done with additional macros.
* You can also simply back up to the beginning of an insertion or search.
So I...$^SC leaves dot at the beginning of the insertion.
S...$^SC leaves dot before the found pattern.
This has been previously requested by users.
* Perhaps there should be ^Y string building characters as well to backreference
in search-replacement commands (TODO).
This means that the search commands would have to store the matched text itself
in teco_range_t structures since FR deletes the matched text before
processing the replacement string.
It could also be made into a FR/FS-specific construct,
so we don't fetch the substrings unnecessarily.
* This differs from DEC TECO in always returning the same range even after dot movements,
since we are storing start/end byte positions instead of only the length.
Also DEC TECO does not support fetching subpattern ranges.
|
|
5597bc72671d0128e6f0dba446c4dc8d47bf37d0)
* Using teco_expressions_eval() is wrong since it does not pay attention to precedences.
If you have multiple higher precedence operators in a row, as in 2+3*4*5,
the lower precedence operators would be resolved prematurely.
* Instead we now call teco_expressions_calc() repeatedly but only for lower precedence
operators on the stack top.
This makes sure that as much of the expression as possible is evaluated at any given moment.
|
|
* This is not safe since the size of the stack object comes from the "outside" world,
so stack overflows can theoretically be provoked by macros.
|
|
* It was possible to provoke operator right-associativity when placing a high-precedence
operator between two low-precedence operators.
1-6*5-1 evaluated to -28 instead of the expected -30.
* The reason is that SciTECO relies on operators to be resolved from left-to-right as soon as possible.
The higher precedence operator prevents that and pushing the 2nd "-" only evaluated 6*5.
At the end 1-30-1 would be left on the stack.
teco_expressions_eval() however evaluates from right-to-left which is wrong in this case.
* Instead, we now do a full eval on every operator with a lower precedence, making sure that 1-30 is
evaluated first.
|
|
* We cannot call it "." since that introduces a local register
and we don't want to add an unnecessary syntactic exception.
* Allows the idiom [: ... ]: to temporarily move around.
Also, you can now write ^E\: without having to store dot in a register first.
* In the future we might add an ^E register as well for byte offsets.
However, there are much fewer useful applications.
* Of course, you can now also write nU: instead of nJ, Q: instead of "." and
n%: instead of "nC.". However it's all not really useful.
|
|
|
|
non-control characters, but to the literal caret, followed by c
* For instance `^$` would insert two characters.
* The alternative would have been to throw an error.
|
|
* This would actually causes crashes when trying to format numbers.
* The ^R local register has a custom set_integer() method now,
so that the check is performed also when using nU.^X.
|
|
^R now (refs #17)
* This way the search mode and radix are local to the current macro frame,
unless the macro was invoked with :Mq.
If colon-modified, you can reproduce the same effect by calling
[.^X 0^X ... ].^X
* The radix register is cached in the Q-Reg table as an optimization.
This could be done with the other "special" registers as well, but at the
cost of larger stack frames.
* In order to allow constructs like [.^X typed with upcarets,
the Q-Register specification syntax has been extended:
^c is the corresponding control code instead of the register "^".
|
|
* Usually you will only want -^X for enabling case sensitive searches
and 0^X for case-insensitive searches (which is also the default).
* An open question is what happens if the user sets -^X and then calls
a macro. The search mode flag should probably be stacked away along
with the search-string. This means we'd need a ^X special Q-Reg as well,
so you can write [^X[_ 0^X S...$ ]_]^X.
Alternatively, the search mode flag should be a property of the
macro frame, along with the radix.
|
