aboutsummaryrefslogtreecommitdiffhomepage
path: root/lib
AgeCommit message (Collapse)AuthorFilesLines
2025-04-06session.tes extensions: allow per-session .teco_ini; detect sessions in ↵session-extensionsRobin Haberkorn1-0/+0
arbitrary parent directories (WIP) * Unfortunately not that easy to get right, especially the per-session .teco_ini. * We must make sure that we do mung the $SCITECOCONFIG/.teco_ini. * .teco_ini must always be munged even if .teco_session is not munged.
2025-04-04scroll caret __almost__ always automatically after key pressesRobin Haberkorn1-2/+2
* 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.
2025-04-03improved the "asm" (x86 assembly) lexerRobin Haberkorn1-1/+9
There are still some glitches with non-mainstream assemblers like A86, though.
2025-03-31the git, sciteco and email lexer configurations are now installed even ↵Robin Haberkorn1-5/+5
--without-lexilla They don't require Lexilla, so it makes no sense not to exclude them.
2025-03-31added tutorial document, which is automatically loaded on the first invocationRobin Haberkorn1-0/+0
* 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.
2025-03-31opener.tes: fixed opening filename:line if filename has trailing digitsRobin Haberkorn1-3/+4
The trailing digits where cut off the filename. E.g. when trying `sciteco test.f77:100`, we would open test.f on line 100 instead.
2025-03-23the ES command (send Scintilla message) now supports passing both wParam and ↵Robin Haberkorn4-0/+0
lParam as null-terminated strings * Being able to embed null bytes into the lParam string is practically useless - there aren't any messages where this is useful and where there are no native SciTECO counterparts - so this case is now catched and the null-byte separates wParam from lParam. * wParam can be the empty string, but it is not supported to pass wParam as a string and lParam as the empty string. If the second string argument ends in ^@, lParam is popped from the stack instead. * This is a temporary workaround until we can properly parse the Scintilla.iface and generate more elegant per-message wrappers. * It in particular unlocks the SCI_SETREPRESENTATION and SCI_SETPROPERTY messages. The former allows us to write a special hex-editor macro which sets hexadecimal character representations, while the latter allows you to set lexer properties. * The C-based lexers ("cpp" in Lexilla) can now take preprocessor definitions into account. This is disabled by default, unless you set lexer.c.defines before opening a file. You can also set it interactively and re-set the lexer. For instance: ^U[lexer.c.defines]NDEBUG$ M[lexer.set.c]
2025-03-22harmonized all word-movement and deletion commands: they move/delete until ↵Robin Haberkorn2-3/+3
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).
2025-03-12sciteco lexer: enable 2-char soft tabs by defaultRobin Haberkorn1-0/+4
* You practically never want to indent in SciTECO code with hard tabs, as the hard tab is an insertion command. * 2-char soft tabs are the convention in SciTECO's included macros. * Fixes the M#it macro among other things. * If you do want to insert an insertion-with-tab command (ASCII 9), you almost always will want to type it ^I instead. Real ASCII 9s should consequently be highlighted, ie. there should be a character representation. Unfortunately, character representations are currently set in C code and cannot be changed via <ES>.
2025-03-08Asciidoc, Markdown and Git lexers: enable word wrapping by defaultRobin Haberkorn3-0/+6
These are all more or less plain text formats.
2025-03-08added "email" lexer for writing mailsRobin Haberkorn2-1/+36
* 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.
2025-03-01GTK: improved the RGB values of the 16 default colorsRobin Haberkorn1-18/+48
* Using the same values as on Curses/scinterm resulted in too dark colors with terminal.tes. (solarized.tes actually defines all colors with its own RGB values, so the look has always been consistent between Curses and GTK.) This is because the values like 0xFF0000 for red are actually just placeholders in Scinterm, in turn translated internally to Curses colors, which are interpreted by terminal emulators with possibly various different color palettes. * We therefore now use the exact RGB values as will be used by common terminal emulators like xterm and st. It does not guarantee that the colors will always match between Curses and GTK, but at least the GTK colors are now a bit brighter.
2025-02-16implemented mouse support via special ^KMOUSE and <EJ> with negative keysRobin Haberkorn1-0/+68
* 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.
2024-12-30support +line[,column] and filename:line:column syntaxes when opening filesRobin Haberkorn2-2/+39
* 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.
2024-12-24added session.fossil for setting up buffer sessions per Fossil repositoryRobin Haberkorn1-0/+0
* This goes into session.vcs as well. * `fossil info` does not allow printing only the local-root property, so we have to do some parsing afterwards.
2024-12-24simplified session.svn: no need to mess around with XMLRobin Haberkorn1-0/+0
* In fact, since SVN has --no-newline, this is even simpler than on Git and Mercurial. * This requires at least Subversion v1.9 (2015, so should be safe).
2024-12-24introduced true block and EOL commentsRobin Haberkorn78-134/+146
* 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.
2024-12-14update sciteco.tes: this again highlights commands, but not Q-Register namesRobin Haberkorn1-2/+2
It's a bit easier on the eyes.
2024-12-13fixed lexer.checkheader: restore dot in case of successRobin Haberkorn1-1/+1
2024-12-13fixup 244a54a18b7db6af177c9d10f3224772f08d7484: abuse the Scintilla view's ↵Robin Haberkorn1-1/+1
"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.
2024-12-13implemented Scintilla lexer for SciTECO code, i.e. TECO syntax highlightingRobin Haberkorn2-1/+22
* 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.
2024-12-08implemented the ^Q command for converting between line and glyph positionsRobin Haberkorn2-7/+7
* 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.
2024-12-06support the ::S anchored search (string comparison) command (and ::FD, ::FR, ↵Robin Haberkorn5-4/+4
::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.
2024-12-04use the new ^Y, ^S and @Xq commands in tedoc.tes and string.tesRobin Haberkorn1-1/+1
2024-11-24lexer.auto: use case-sensitive searchesRobin Haberkorn1-0/+0
* lexer.checkheader is therefore case-sensitive now as well
2024-11-24added special Q-Register ":" for accessing dotRobin Haberkorn2-9/+5
* 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.
2024-11-11session.tes: store the current tab style (width and hard-tabs); fixed for ↵Robin Haberkorn1-0/+0
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.
2024-10-16Solarized color scheme: fixed F5 function key macroRobin Haberkorn1-2/+2
The macro prefix was changed from ^F to ^K.
2024-09-26Git lexer: added support for TAG_EDITMSG and MERGE_MSGRobin Haberkorn1-0/+2
* Curses: "icons" have also been added
2024-09-17improved HTML lexer (html.tes)Robin Haberkorn1-3/+48
This previously highlighted little more than embedded Javascripts.
2024-09-12function key macros have been reworked into a more generic key macro featureRobin Haberkorn1-31/+28
* 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.
2024-09-09added an improvised lexer for styling Git commit messagesRobin Haberkorn2-1/+18
It's not a real Lexilla lexer, but simply styles the document once in lexer.set.git in order to highlight comment lines.
2024-09-09Xq and ]q inherit the document encoding from the source document (refs #5)Robin Haberkorn1-0/+0
* ^Uq however always sets an UTF8 register as the source is supposed to be a SciTECO macro which is always UTF-8. * :^Uq preserves the register's encoding * teco_doc_set_string() now also sets the encoding * instead of trying to restore the encoding in teco_doc_undo_set_string(), we now swap out the document in a teco_doc_t and pass it to an undo token. * The get_codepage() Q-Reg method has been removed as the same can now be done with teco_doc_get_string() and the get_string() method.
2024-09-09lexer.checkheader is Unicode-aware now (refs #5)Robin Haberkorn1-1/+1
2024-09-09implemented <EE> and <^E> commands for configuring encodings and translating ↵Robin Haberkorn1-16/+16
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.
2024-08-18added troff/nroff lexerRobin Haberkorn3-2/+88
* This is optimized for Groff, but works for Heirloom Troff and Neatroff as well. Currently, the Heirloom and Neatroff requests are just added ontop of the Groff ones. Theoretically, we could also try to separate the keyword lists into a base K&R set with Groff, Heirloom and Neatroff ontop. * The lexer necessarily has many restrictions, as Troff is fundamentally unparseable (like classic TECO) and needs a lot of per-request knowledge. * The "*.mm" extension has been removed from the lexers/cpp.tes. I don't know what language this was for, and I prefer `*.mm` files to be considered Troff. * Temporarily changed the lexilla submodule URL. The corresponding Lexila lexer is in the process of being upstreamed. Once it is, I will probably revert the submodule to the official repository, as the "troff" branch is not stable (can be rebased).
2024-01-28cursor movement via fnkeys.tes now preserves the column as in most text editorsRobin Haberkorn1-27/+48
* 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)`.
2024-01-20fnkeys.tes: support zooming via F9/F10Robin Haberkorn1-0/+9
* Works only in Gtk of course and only in the parser start state. * Since its side effects can neither be reversed, nor does it have any side effects on the editor state, we can completely rub it out. * Currently, it will only affect the current buffer and only the text area. It would be trivial to apply the zoom to the commandline widget as well (FIXME?). There is currently no way that the zoom value or any font size could be passed to the CSS, though. So the auto-completion overlay could only be zoomed if Gtk supports a zoom factor as well.
2023-04-16added Asciidoc lexer configRobin Haberkorn2-1/+30
2023-04-14allow disabling Lexilla (Lexer) support by specifying --without-lexillaRobin Haberkorn1-79/+83
* This does not make sense for most SciTECO builds, but only when you want to optimize for size as the lexers take up 50% of the compressed binary size. Without Lexilla, it should be possible get it compiled in about 500kb. * It can be useful for instance when building for embedded distributions. * When Lexilla is disabled, symbols-scilexer.c is also not generated (we assume that the Lexilla sources are not available and it also doesn't serve any purpose). * Consequently, most of the lexer configuration scripts are also not installed under --without-lexilla.
2022-11-27added Markdown and YAML lexer configsRobin Haberkorn3-1/+53
* For markdown.tes we should better introduce new predefined colors in the color scheme files since it doesn't map well to existing colors. For italic and bold, I am not using the predefined colors at all but only set the bold and italic style attributes -- this should still be portable across color schemes.
2022-11-22scite2co.lua: avoid unnecessary string concatenations with io.write()Robin Haberkorn1-9/+9
Not that speed would make any difference here whatsoever...
2022-11-22scite2co.lua: support generating substylesRobin Haberkorn1-19/+48
2022-11-21improved the C/C++ and Gob lexersRobin Haberkorn4-4/+13
* single quoted constants are highlighted like single quoted strings in all other auto-generated lexers using "CPP". * recognize /// and //! and comments after preprocessor statements
2022-11-21added lexers for Python and Linux Device TreesRobin Haberkorn3-1/+96
* The device tree lexer reuses CPP and has certain limitations. For once it does not recognize /keywords/ and secondly it confuses properties beginning with # as preprocessor statements.
2021-10-13improved default selection colors and made them configurable via color.tesRobin Haberkorn3-2/+10
* NOTE: Selections are currently only used to highlight search results. * The default selection colors were not always visible well with default settings (--no-profile) and they were not uniform across platforms. On Curses, the selection would be reversed, while on Gtk it had a lighter foreground color. They are now always reversed (black on white background). The default styles do not assume any color support - they use only black and white. * Since these defaults cannot possibly work on every color scheme, color.selfore and color.selback has been added to color.tes. All existing color schemes have been updated to configure selections as reversed to the default colors. This especially fixes selection colors on Gtk. * On solarized.tes, the caret style was already distinct from inversed default colors. On terminal.tes, the color of the caret is now bright white, so it stands out from the selection colors. * In Curses, the caret color is currently __not__ applied to the command line where it is continued to be drawn reversed. The command line drawing code is considered deprecated and will eventually be replaced with a Scintilla minibuffer. * In Gtk, we now apply the caret style to the commandline view as well. * Fixed the comment color in solarized.light.
2021-10-11upgraded to Scintilla 5.1.3 and Scinterm 3.1Robin Haberkorn72-73/+73
* Previous Scintilla version was 3.6.4 and Scinterm was 1.7 (with lots of custom patches). All of the patches are now either irrelevant or have been merged upstream. * Since Scintilla 5 requires C++17, this increases the minimum GCC version at least to 5.0. We may actually require even newer versions. * I could not upgrade the scintilla-mirror (which was imported from Mercurial), so the old sciteco-dev branch was renamed to sciteco-dev-pre-v2.0.0, master was deleted and I reimported the entire Scintilla repo using git-remote-hg. This means that scintilla-mirror now contains two entirely separate trees. But it is still possible to clone old SciTECO repos. * The strategy/workflow of maintaining hotfix branches on scintilla-mirror has been changed. Instead of having one sciteco-dev branch that is rebased onto new Scintilla upstream releases and tagging SciTECO releases in scintilla-mirror (to keep the commits referenced), we now create a branch for every Scintilla version we are based on (eg. sciteco-rel-5-1-3). This branch is never rebased or deleted. Therefore, we are guaranteed to be able to clone arbitrary SciTECO repo commits - not only releases. Releases no longer have to be tagged in scintilla-mirror. On the downside, fixup commits may accumulate in these new branches. They can only be squashed once a new branch for a new Scintilla release is created (e.g. by cherry-picking followed by rebase). * Scinterm does no longer have to reside in the Scintilla subdirectory, so we added it as a regular submodule. There are no more recursive submodules. The Scinterm build system has not been improved at all, but we use a trick based on VPATH to build Scinterm in scintilla/bin/. * Scinterm is now in Git and we reference the upstream repo for the time being. We might mirror it and apply the same branching workflow as with Scintilla if necessary. The scinterm-mirror repository still exists but has not been touched. We will also have to rewrite its master branch as it was a non-reproducible Mercurial import. * Scinterm now also comes with patches for Scintilla which we simply applied on our sciteco-rel-5-1-3 branch. * Scintilla 5 outsourced its lexers into the Lexilla project. We added it as yet another submodule. * All submodules have been moved into contrib/. * The Scintilla API for setting lexers has consequently changed. We now have to call SCI_SETILEXER(0, CreateLexer(name)). As I did not want to introduce a separate command for setting lexers, <ES> has been extended to allow setting lexers by name with the SCI_SETILEXER message which effectively replaces SCI_SETLEXERLANGUAGE. * The lexer macros (SCLEX_...) no longer serve any purpose - they weren't used in the SciTECO standard library anyway - and have consequently been removed from symbols-scilexer.c. The style macros from SciLexer.h (SCE_...) are theoretically still useful - even though they are not used by our current color schemes - and have therefore been retained. They can be specified as wParam in <ES>. * <ES> no longer allows symbolic constants for lParam. This never made any sense since all supported symbols were always wParam. * Scinterm supports new native cursor modes. They are not used for the time being and the previous CARETSTYLE_BLOCK_AFTER caret style is configured by default. It makes no sense to enable native cursor modes now since the command line should have a native cursor but is not yet a Scintilla view. * The Scintilla upgrade performed much worse than before, so some optimizations will be necessary.
2017-11-16CPP lexer: support *.ino files (Arduino IDE sketches)Robin Haberkorn1-1/+2
* a proper Arduino lexer supporting the special Arduino keywords/classes could in principle be written, but for the time being they're treated just like regular C++ sources
2016-11-22womanpage lexer: fixed popup stylingRobin Haberkorn1-1/+1
* the ESSTYLECLEARALL$$ was resetting the STYLE_CALLTIP (and others) resulting in wrongly-styled popups. * We now only change STYLE_DEFAULT for Gtk UIs and use `color.init` to reinitialize the other styles (not very elegant).
2016-11-18standard lib: added getopt.tes for parsing command line options in scriptsRobin Haberkorn2-1/+53
* this uses an optstring compatible with getopt(3). * It does not use repeated getopt calls to iterate options, though but places the results in registers beginning with "getopt.". E.g. option "C" will result in "getopt.C" being set after the call to setopt. String arguments are supported and are placed in the string part of the getopt registers. * The grosciteco.tes and symbols-extract.tes scripts make use of getopt now, to simplify and clean up their command line handling.