| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
"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 release is mainly for the upcoming FreeBSD package.
|
|
* 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.
|
|
* 13 is now the oldest supported version
|
|
|
|
|
|
* 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.
|
|
|
|
This does not change anything functionally.
|
|
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.
|
|
|
|
* lexer.checkheader is therefore case-sensitive now as well
|
|
* 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.
|
|
* also explicitly mention -%q
|
|
|
|
|
|
|
|
filenames containing ASCII 27
* You can now set a per-file tab style, that differs from the defaults established
in the ED hook.
This is important especially since we do not yet support per-project .teco_ini
scripts where you could establish differing policies depending on the VCS repository.
(The latter would be easy to implement, but we cannot currently easily extend the
existing ED hooks.)
* It's unlikely that files contain an ASCII 27, but not impossible.
Therefore we now use ASCII 0 (^@) as a terminator.
This indeed be safe under UNIX.
Even better would be a string building construct for escaping ASCII 27 ($), though,
as that would work with arbitrary bytes.
|
|
* should also fix Win32 nightly builds
* Even though we weren't using main's argv, but were using glib
API for retrieving the command line in UTF-8, newer MinGW runtimes
would fail when converting the Unicode command line into the system codepage
would be lossy.
* Most people seem to compile in a "manifest" to work around this issue.
But this requires newer Windows versions and using some Microsoft tool which isn't
even in $PATH.
Instead, we now link with -municode and define wmain() instead, even though we still
ignore argv. wmain() proabably get's the command line in UTF-16 and we'd have to
convert it anyway.
* See https://github.com/msys2/MINGW-packages/issues/22462
|
|
non-relocatable binary)
* This was accidentally installing into $bindir/usr (usually /usr/local/bin/usr/...)
You might want to check whether SciTECO accidentally installed something there.
|
|
The next release will include almost exclusively bug fixes.
|
|
restrictions
|
|
|
|
* The line drawing algorithm currently works only with tbl, though.
* Also only straight lines are currently supported.
* This was meant for rendering presentations in SciTECO - it's not currently
used or planned to be used in the manpages.
Although we might well add pic graphics to the manpages in the future.
|
|
This could theoretically be used to apply Scintilla styles not natively and easily supported by grosciteco,
eg. different fonts and font sizes.
|
|
|
|
not found' error
* This is important with gotos in loops as in <@O/x/> where, we would otherwise
get a confusing "Unterminated loop" error.
* This in particular fixes the error thrown in grosciteco.tes when encountering
a new unknown command.
|
|
characters by unicode, ie. typesetting of most non-latin text
* This was broken at least for characters that happened to contain hexadecimal digits > 9
since "D does not detect hexadecimal digits.
|
|
* We just passed the length in glyphs to SCI_SETSTYLING.
|
|
* The program exit code will usually not signal failures since they are caught earlier.
* Therefore, we always have to capture and check stderr.
|
|
characters in Q-Register)
* It was initialized only once, so it could inherit the wrong local Q-Register table.
A test case has been added for this particular bug.
* Also, if starting from the profile (batch mode), the state machine could be initialized
without undo, which then later cause problems on rubout in interactive mode.
For instance, if S^EG[a] fails and you would repeatedly type `]`, the Q-Reg name could
grow indefinitely. There were probably other issues as well.
Even crashes should have been possible, although I couldn't reproduce them.
* Since the state machine is required only for the pattern to regexp translation
and is performed anew for every character in interactive mode,
we now create a fresh state machine for every call and don't attempt
any undo.
There might be more efficient ways, like reusing the string building's
Q-Reg parser state machine.
|
