| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This fixes building of the new tutorial.woman on Ubuntu.
|
|
|
|
* This is rendered with ms, so we now need the entire groff on Debian.
This is not a big deal as it just adds a few kilobytes of build-time dependencies.
Most platforms do not allow installation of some "groff-base" package anyway
and always draw in the entire package.
* sciteco.tmac has been extended to disable page breaks on ms.
* The tutorial is installed like any other woman page and can be invoked
interactively with ?tutorial$.
* It is optimized to be still usable on a plain 80x24 terminal.
|
|
* It makes little sense to e.g. rub out until `I` in `@I/foo/`, but
leave the `@` modifier.
Modifiers have to be considered part of the command,
even though the state machine is not currently modelled like that.
|
|
* They swap the default order of skipping characters.
For positive arguments: first non-word chars, then word chars.
* This is especially useful after executing the non-at-modified versions.
For instance, at the beginning of a word, `@W` jumps to its end.
`@V` would delete the remainder of the word.
* Since they have to evaluate the at-modifier, which has syntactic
significance, the command implementations can no longer use
transition tables, so they are in the switch-statements instead.
|
|
* regression from 867d22e419afe769f05ad26b61c6ea5ea1432c3c
|
|
This was changed ages ago for some old version of Groff.
These workarounds should no longer be necessary.
|
|
out no-op commands (whitespace)
* In string arguments, ^W first rubs out non-word chars (usually whitespace),
so it makes sense if ^W would work analogously at the command level.
A non-command would be one of the no-ops.
|
|
* All the movement commands have shortcuts for their negative forms:
`R` instead of `-C`, `B` instead of `-L`.
Therefore there was always the need for a `-W` shortcut as well.
* `P` is a good choice because it is a file IO command in TECO-11,
that does not make sense supporting.
In Video TECO it toggles between display windows (ie. split screens)
and I do not plan to support multiple windows in SciTECO.
* Added to the cheat sheet.
|
|
the beginning of words now
* All commands and their documentations were inconsistent.
* ^W rubbed out to the beginning of words.
* Shift+Right (fnkeys.tes) moved to the beginning of the next word if
invoked at the beginning of a word and to the end of the next word otherwise.
* <W> (and <V> and <Y> by extension) moved to the end of the next word.
* The cheat sheet would claim that <W> moves to the beginning of the next word.
* Video TECO's <W> command would differ again from everything else.
With positive arguments, it moved to the beginning of words, while
with negative it moved to end of words.
I decided not to copy this behavior.
* It has been decided to adopt a consistent beginning-of-words policy.
-W therefore differs from Video TECO in moving to the beginning of the
current or previous word.
* teco_find_words() is now based on parsing the document pointer, instead
of relying on SCI_WORDENDPOSITION, since the latter cannot actually be
used to skip strictly non-word characters.
This requires a constant amount of Scintilla messages but will require fewer
messages only when moving for more than 3 words.
* The semantics of <W> are therefore now consistent with Vim and Emacs as well.
* Shift+Right/Left is still based on SCI_WORDENDPOSITION, so it's behavior
differs slightly from <W> for instance at the end of lines, as it will
stop at linebreaks.
* Unfortunately, these changes will break lots of macros, among others
the M#rf, M#sp and git.blame macros ("Useful macros" from the wiki).
|
|
We don't need to specify the "woman.tec" output file as the default is sufficient.
If it has to be specified, it's now done with `-t`.
|
|
* 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.)
|
|
* 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.
|
|
* 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
|
|
* 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.
|
|
* @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.
|
|
installation
* use the new ::FS and ^Q commands
|
|
::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.
|
|
|
|
|
|
* 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.
|
|
^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 "^".
|
|
* also explicitly mention -%q
|
|
|
|
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.
|
|
|
|
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.
|
|
* This might fix builds on Ubuntu Bionic.
I would have to make another minor release in order to try that out and
push another Ubuntu PPA release.
* Since the PPA is practically not used by anybody,
it's not worth it.
|
|
|
|
|
|
|
|
* Due to recent changes, you now have to type S^Q^Q^^$ since
the ASCII caret (94) is interpreted as a pattern match character.
|
|
* makes it possible, albeit cumbersome, to escape pattern match characters
* For instance, to search for ^Q, you now have to type
S^Q^Q^Q^Q$.
To search for ^E you have to type
S^Q^Q^Q^E$.
But the last character cannot be typed with carets currently (FIXME?).
For pattern-only characters, two ^Q should be sufficient as in
S^Q^Q^X$.
* Perhaps it would be more elegant to abolish the difference between string building
and pattern matching characters to avoid double quoting.
But then all string building constructs like ^EQq should operate at the pattern level
as well (ie. match the contents of register q verbatim instead of being interpreted as a pattern).
TECOC and TECO-64 don't do that either.
If we leave everything as it is, at least a new string building construct should be added for
auto-quoting patterns (analoguous to ^EN and ^E@).
|
|
* This allows you to type ^Q^U (which would otherwise rub out the entire argument)
and ^Q^W (which would otherwise rub out the ^Q).
* ^Q^U coincidentally worked previously since the teco_state_stringbuilding_escaped
state would default to teco_state_process_edit_cmd().
But it's better to make this feauture explicit.
* This finally makes it possible to insert the ^W (23) char into a buffer.
In interactive mode, you can still only type Caret+W as a string building construct.
* ^G could also be inhibited after ^Q, but the control char is not used anywhere yet,
so there is no point in doing that.
|
|
* 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.
|
|
all expansions of ^EQq, ^EUq and so on
* Previously, there was no way to enter upper-case mode in interactive commands since
the Ctrl+W immediate editing command is interpreted everywhere.
* Without the case folding of ^EQq/^EUq results, the upper and lower case modes are actually pretty useless
considering that modern keyboards have caps lock.
So it was clear we need this, regardless of what the classic TECOs did.
The TECO-11 manual is not very clear on this.
tecoc apparently does not case-fold ^EQq results.
* This opens up new idioms, for instance
`EUq^W^W^EQq$` in order to upper case register q.
It's also the only way you can currently upper-case Unicode codepoints.
|
|
* Ctrl+^ (30) and Caret+caret (^^) were both translated to a single caret.
While there might be some reason to keep this behavior for double-caret,
it is certainly pointless for Ctrl+^.
* That gives you an easy way to insert Ctrl+^ (code 30) into documents with <I>.
Perviously, you either had to insert a double-caret, typing 4 carets in a row,
or you had to use <EI> or 30I$.
* The special handling of double-caret could perhaps be abolished altogether,
as we also have ^Q^ to escape plain carets.
The double-caret syntax is very archaic from the time that there was no proper
^Q as far as I recall correctly.
|
|
|
|
* character-based model, avoid mentioning "ASCII code"
* added "0EE" example
* should be built with pdfmom, so it's built with gropdf
|
