Notable changes: Scintilla: - Add SC_ELEMENT_FOLD_LINE to set the colour of fold lines. Add SC_ELEMENT_HIDDEN_LINE to show where lines are hidden. - On GTK, fix the line spacing so that underscores and accents are visible for some fonts such as DejaVu Sans Mono 10.
Lexilla - Implement conditional group rules in CSS. Issue #25, Pull request #28. - Check PHP numeric literals, showing invalid values with default style instead of numeric. Issue #20.
The CSS change causes compatiblity trouble. We exposed the changed style in filetypes.css. We still do for compatiblity reasons but we still want to align the style name to lexilla so we default to "group_rule" now. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2930
-- Commit Summary --
* <a href="https://github.com/geany/geany/pull/2930/commits/56416311291ea0e0ffeca4e244bf43b0544d8fac">Update to Scintilla 5.1.3 and Lexilla 5.1.2</a>
-- File Changes --
M data/filedefs/filetypes.css (2) M scintilla/gtk/PlatGTK.cxx (4) M scintilla/gtk/ScintillaGTK.cxx (50) M scintilla/gtk/ScintillaGTK.h (3) M scintilla/gtk/ScintillaGTKAccessible.cxx (1) M scintilla/include/Scintilla.h (6) M scintilla/include/Scintilla.iface (14) M scintilla/include/ScintillaCall.h (4) M scintilla/include/ScintillaMessages.h (4) M scintilla/include/ScintillaTypes.h (2) M scintilla/lexilla/include/SciLexer.h (2) M scintilla/lexilla/lexers/LexCSS.cxx (8) M scintilla/lexilla/lexers/LexHTML.cxx (140) M scintilla/lexilla/lexers/LexMarkdown.cxx (9) M scintilla/lexilla/lexlib/WordList.cxx (85) M scintilla/lexilla/lexlib/WordList.h (9) M scintilla/lexilla/version.txt (2) M scintilla/src/AutoComplete.cxx (4) M scintilla/src/AutoComplete.h (7) M scintilla/src/CallTip.cxx (4) M scintilla/src/CallTip.h (2) M scintilla/src/CaseConvert.cxx (10) M scintilla/src/CaseFolder.cxx (3) M scintilla/src/CaseFolder.h (1) M scintilla/src/CellBuffer.cxx (2) M scintilla/src/ContractionState.cxx (2) M scintilla/src/Decoration.cxx (12) M scintilla/src/Document.cxx (23) M scintilla/src/Document.h (38) M scintilla/src/EditModel.cxx (1) M scintilla/src/EditModel.h (1) M scintilla/src/EditView.cxx (95) M scintilla/src/Editor.cxx (48) M scintilla/src/Editor.h (7) M scintilla/src/Geometry.cxx (24) M scintilla/src/Geometry.h (28) M scintilla/src/Indicator.cxx (4) M scintilla/src/KeyMap.cxx (4) M scintilla/src/KeyMap.h (1) M scintilla/src/LineMarker.cxx (2) M scintilla/src/MarginView.cxx (528) M scintilla/src/MarginView.h (2) M scintilla/src/PositionCache.cxx (98) M scintilla/src/PositionCache.h (21) M scintilla/src/RESearch.cxx (4) M scintilla/src/RESearch.h (1) M scintilla/src/ScintillaBase.cxx (34) M scintilla/src/Selection.cxx (3) M scintilla/src/Selection.h (1) M scintilla/src/Style.cxx (116) M scintilla/src/Style.h (50) M scintilla/src/UniConversion.h (2) M scintilla/src/UniqueString.cxx (6) M scintilla/src/UniqueString.h (4) M scintilla/src/ViewStyle.cxx (316) M scintilla/src/ViewStyle.h (30) M scintilla/version.txt (2) M src/highlightingmappings.h (7)
-- Patch Links --
https://github.com/geany/geany/pull/2930.patch https://github.com/geany/geany/pull/2930.diff
@kugel- commented on this pull request.
@@ -388,7 +388,12 @@ static const HLStyle highlighting_styles_CSS[] =
{ SCE_CSS_EXTENDED_IDENTIFIER, "extended_identifier", FALSE }, { SCE_CSS_EXTENDED_PSEUDOCLASS, "extended_pseudoclass", FALSE }, { SCE_CSS_EXTENDED_PSEUDOELEMENT, "extended_pseudoelement", FALSE }, - { SCE_CSS_MEDIA, "media", FALSE } + { SCE_CSS_GROUP_RULE, "group_rule", FALSE }, + /* In Geany 1.38 and earlier shipped filetypes.css with "media" identifier, + * Scintilla/Lexilla 5.1.2 has renamed this style and extended its meaning. + * We still recognize media for compatibility. + */ + { SCE_CSS_GROUP_RULE, "media", FALSE }
@b4n @eht16 is the compatibility fix I did here even valid?
I get a segfault on closing Geany with this applied, but not on master at dda15b47 bt:
``` Thread 1 "geany" received signal SIGSEGV, Segmentation fault. 0x00007ffff7583500 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 (gdb) bt #0 0x00007ffff7583500 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #1 0x00007ffff745283e in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #2 0x00007ffff7435f60 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #3 0x00007ffff7436a4d in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #4 0x00007ffff7599703 in gtk_style_context_get_property () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #5 0x00007ffff75998c5 in gtk_style_context_get_valist () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #6 0x00007ffff7599b7e in gtk_style_context_get () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #7 0x00007ffff7643a02 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #8 0x00007ffff7643fb3 in gtk_widget_create_pango_context () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #9 0x00007ffff7644080 in gtk_widget_get_pango_context () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #10 0x00007ffff76440ee in gtk_widget_create_pango_layout () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #11 0x00007ffff745fd33 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #12 0x00007ffff7460f87 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #13 0x00007ffff746163a in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #14 0x00007ffff6d9bf03 in g_cclosure_marshal_VOID__OBJECTv () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x00007ffff6d98a56 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x00007ffff6db7b48 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x00007ffff6db80f3 in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x00007ffff76358d4 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #19 0x00007ffff7635908 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #20 0x00007ffff75e6500 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #21 0x00007ffff7635908 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #22 0x00007ffff73d2670 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #23 0x00007ffff7635908 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #24 0x00007ffff7638b24 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #25 0x00007ffff7647463 in gtk_widget_unparent () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 --Type <RET> for more, q to quit, c to continue without paging--c #26 0x00007ffff73ccb48 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #27 0x00007ffff6d9bf03 in g_cclosure_marshal_VOID__OBJECTv () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #28 0x00007ffff6d98a56 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #29 0x00007ffff6db7b48 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #30 0x00007ffff6db80f3 in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #31 0x00007ffff741d0ec in gtk_container_remove () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #32 0x00007ffff763d798 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #33 0x00007ffff6d9f4d1 in g_object_run_dispose () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #34 0x00007ffff7649ce9 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #35 0x00007ffff741ebca in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #36 0x00007ffff6d98802 in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #37 0x00007ffff6dacb05 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #38 0x00007ffff6db7bbe in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #39 0x00007ffff6db80f3 in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #40 0x00007ffff763d870 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #41 0x00007ffff76514ec in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #42 0x00007ffff6d9f4d1 in g_object_run_dispose () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #43 0x00007ffff7cefc3d in do_main_quit () at libmain.c:1339 #44 do_main_quit () at libmain.c:1255 #45 0x00007ffff7cf18ac in main_quit () at libmain.c:1397 #46 0x00007ffff7cc15bd in on_window_delete_event (widget=<optimised out>, event=<optimised out>, gdata=<optimised out>) at callbacks.c:84 #47 0x00007ffff76895ef in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #48 0x00007ffff6d98a56 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #49 0x00007ffff6db6df1 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #50 0x00007ffff6db80f3 in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #51 0x00007ffff7633c23 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #52 0x00007ffff74f138d in gtk_main_do_event () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #53 0x00007ffff71d9f79 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #54 0x00007ffff720d106 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #55 0x00007ffff6ca517d in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #56 0x00007ffff6ca5400 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #57 0x00007ffff6ca56f3 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #58 0x00007ffff74f037d in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #59 0x00007ffff7cf1140 in main_lib (argc=<optimised out>, argv=<optimised out>) at libmain.c:1240 #60 0x00007ffff7a7a0b3 in __libc_start_main (main=0x555555555060 <main>, argc=3, argv=0x7fffffffe028, init=<optimised out>, fini=<optimised out>, rtld_fini=<optimised out>, stack_end=0x7fffffffe018) at ../csu/libc-start.c:308 #61 0x000055555555509e in _start () ```
Any plugins involved? I don't get that.
No plugins.
Ok, this is getting weird, it segfaults if I quit with `Tools->Configuration files->Filetype Configuration->Programming Language->filetypes.c` open but is fine if nothing is open.
Some more testing I find if geany is quit with any file opened or closed during the session it segfaults. If started with one file in the session it quits ok, but if there are two files in the session it segfaults on quit even if I don't do anything while its running. These tests are with files of filetype none and then filetype C, so it seems its independent of filetype, so its probably in Scintilla not a lexer.
Easy reproducer: start `geany -c nonexistant` do `File->New` then quit.
The backtrace looks like the above each time, and there is no Geany or Scintilla code in there (except `do_main_quit` and `main_quit` which is expected). Its happening on `gtk_widget_destroy()` of the main window so maybe Scintilla has changed some object lifetime and GTK is trying to release a dangling pointer.
@elextr commented on this pull request.
@@ -179,6 +180,18 @@ GdkAtom SelectionOfGSD(GtkSelectionData *sd) noexcept {
return gtk_selection_data_get_selection(sd); }
+bool SettingGet(GtkSettings *settings, const gchar *name, gpointer value) noexcept {
This looks like the only change that is likely to cause segfaults on widget destroy of the main window if these settings are added to the Scintilla widget and the memory is double released?
@kugel- commented on this pull request.
@@ -264,6 +279,12 @@ ScintillaGTK::~ScintillaGTK() {
} ClearPrimarySelection(); wPreedit.Destroy(); + if (settingsHandlerId) { + g_signal_handler_disconnect(settings, settingsHandlerId); + } + if (settings) { + g_object_unref(settings);
Fairly sure this is the problem. `settings` is initialized using `gtk_settings_get_default()` and this is documented as "transfer-none", so `g_object_unref()` is inappropriate. Code using this instance is then suffering from use-after-free.
@kugel- commented on this pull request.
@@ -264,6 +279,12 @@ ScintillaGTK::~ScintillaGTK() {
} ClearPrimarySelection(); wPreedit.Destroy(); + if (settingsHandlerId) { + g_signal_handler_disconnect(settings, settingsHandlerId); + } + if (settings) { + g_object_unref(settings);
And removing this call fixes the crash.
@kugel- commented on this pull request.
@@ -264,6 +279,12 @@ ScintillaGTK::~ScintillaGTK() {
} ClearPrimarySelection(); wPreedit.Destroy(); + if (settingsHandlerId) { + g_signal_handler_disconnect(settings, settingsHandlerId); + } + if (settings) { + g_object_unref(settings);
https://sourceforge.net/p/scintilla/code/ci/db178448ae7a1049853c8e6e2cdba6f7...
I guess we can simply remove the unref as the same fix is alredy applied upstream.
@kugel- pushed 1 commit.
e76c0f168695441afb508b6f404b1e17c50f5483 Fix use-after-free crash caused by new Scintilla.
@elextr commented on this pull request.
@@ -282,9 +282,6 @@ ScintillaGTK::~ScintillaGTK() {
if (settingsHandlerId) { g_signal_handler_disconnect(settings, settingsHandlerId); } - if (settings) {
Fixes crash here.
@eht16 commented on this pull request.
@@ -388,7 +388,12 @@ static const HLStyle highlighting_styles_CSS[] =
{ SCE_CSS_EXTENDED_IDENTIFIER, "extended_identifier", FALSE }, { SCE_CSS_EXTENDED_PSEUDOCLASS, "extended_pseudoclass", FALSE }, { SCE_CSS_EXTENDED_PSEUDOELEMENT, "extended_pseudoelement", FALSE }, - { SCE_CSS_MEDIA, "media", FALSE } + { SCE_CSS_GROUP_RULE, "group_rule", FALSE }, + /* In Geany 1.38 and earlier shipped filetypes.css with "media" identifier, + * Scintilla/Lexilla 5.1.2 has renamed this style and extended its meaning. + * We still recognize media for compatibility. + */ + { SCE_CSS_GROUP_RULE, "media", FALSE }
Good idea. Though it doesn't work, easy to find out by just testing it: the "media" item overwrites the previous "group_rule" item, regardless whether "group_rule" appears in the fletype configuration or not.
So, we have a couple of options here: 1. keep the name "media" even though it doesn't matter the Scintilla style name anymore. Maybe add a comment in `data/filedefs/filetypes.css` to the "media" style to document it's also used for the other CSS groups 2. rename the style to "group_rule" and tell the users in the release notes about the renamed style, some users probably won't notice it anyway and might be wondering about broken styling 3. add some code which actually can handle such duplicate comparability style items 4. add some code to support something like ``` group_rule=0xffffff;0x0000ff;true;false media=group_rule ``` in filetype definition files, currently style references seem to work only for global styles but not for those defined in the same file.
I think 4. would be the best and most flexible solution but also with the most effort. And of course, 3. and 4. would be totally out of scope of this PR.
So maybe 1. would be good enough? If such renamings happen more often in the future, we might reconsider the other options, I think.
@elextr commented on this pull request.
@@ -388,7 +388,12 @@ static const HLStyle highlighting_styles_CSS[] =
{ SCE_CSS_EXTENDED_IDENTIFIER, "extended_identifier", FALSE }, { SCE_CSS_EXTENDED_PSEUDOCLASS, "extended_pseudoclass", FALSE }, { SCE_CSS_EXTENDED_PSEUDOELEMENT, "extended_pseudoelement", FALSE }, - { SCE_CSS_MEDIA, "media", FALSE } + { SCE_CSS_GROUP_RULE, "group_rule", FALSE }, + /* In Geany 1.38 and earlier shipped filetypes.css with "media" identifier, + * Scintilla/Lexilla 5.1.2 has renamed this style and extended its meaning. + * We still recognize media for compatibility. + */ + { SCE_CSS_GROUP_RULE, "media", FALSE }
Though it doesn't work, easy to find out by just testing it:
I thought it did work, but maybe I tested it wrong, I just tried some CSS of the web :-)
For 4. if there is both a `media` and a `group_rule` syntactic entity is it possible they could both be assigned the same named style in the config file without any extra code needed?
@eht16 commented on this pull request.
@@ -388,7 +388,12 @@ static const HLStyle highlighting_styles_CSS[] =
{ SCE_CSS_EXTENDED_IDENTIFIER, "extended_identifier", FALSE }, { SCE_CSS_EXTENDED_PSEUDOCLASS, "extended_pseudoclass", FALSE }, { SCE_CSS_EXTENDED_PSEUDOELEMENT, "extended_pseudoelement", FALSE }, - { SCE_CSS_MEDIA, "media", FALSE } + { SCE_CSS_GROUP_RULE, "group_rule", FALSE }, + /* In Geany 1.38 and earlier shipped filetypes.css with "media" identifier, + * Scintilla/Lexilla 5.1.2 has renamed this style and extended its meaning. + * We still recognize media for compatibility. + */ + { SCE_CSS_GROUP_RULE, "media", FALSE }
Though it doesn't work, easy to find out by just testing it:
I thought it did work, but maybe I tested it wrong, I just tried some CSS of the web :-)
Or I tested it wrong? We need a third tester :D.
For 4. if there is both a `media` and a `group_rule` syntactic entity is it possible they could both be assigned the same named style in the config file without any extra code needed?
For me, it didn't work. I tested with the snippet I posted above in `~/.config/geany/filedefs/filetypes.css` and got "Bad color 'group_rule'" in the debug log.
@elextr commented on this pull request.
@@ -388,7 +388,12 @@ static const HLStyle highlighting_styles_CSS[] =
{ SCE_CSS_EXTENDED_IDENTIFIER, "extended_identifier", FALSE }, { SCE_CSS_EXTENDED_PSEUDOCLASS, "extended_pseudoclass", FALSE }, { SCE_CSS_EXTENDED_PSEUDOELEMENT, "extended_pseudoelement", FALSE }, - { SCE_CSS_MEDIA, "media", FALSE } + { SCE_CSS_GROUP_RULE, "group_rule", FALSE }, + /* In Geany 1.38 and earlier shipped filetypes.css with "media" identifier, + * Scintilla/Lexilla 5.1.2 has renamed this style and extended its meaning. + * We still recognize media for compatibility. + */ + { SCE_CSS_GROUP_RULE, "media", FALSE }
yeah I think the second line needs to be removed so they are two separate syntactic entity names.
Basically I don't think its going to be possible to map the two together in the code as @kugel- wanted to, good try and it would have allowed old colour schemes to handle `group_rule` unchanged. But it looks like has to be done in the config file, and colour schemes.
Unless some new magic capability is added to `highlightingmappings.h` and `highlighting.c` to provide a backward compatibility feature, its always going to be a problem for colour schemes and filetype configs when syntactic entities change.
@elextr commented on this pull request.
@@ -388,7 +388,12 @@ static const HLStyle highlighting_styles_CSS[] =
{ SCE_CSS_EXTENDED_IDENTIFIER, "extended_identifier", FALSE }, { SCE_CSS_EXTENDED_PSEUDOCLASS, "extended_pseudoclass", FALSE }, { SCE_CSS_EXTENDED_PSEUDOELEMENT, "extended_pseudoelement", FALSE }, - { SCE_CSS_MEDIA, "media", FALSE } + { SCE_CSS_GROUP_RULE, "group_rule", FALSE }, + /* In Geany 1.38 and earlier shipped filetypes.css with "media" identifier, + * Scintilla/Lexilla 5.1.2 has renamed this style and extended its meaning. + * We still recognize media for compatibility. + */ + { SCE_CSS_GROUP_RULE, "media", FALSE }
I had some time to check again (after reading W3C tutorial on @media etc) and I agree with @eht16, using %Y in the status bar I can see that `media` and `document` in `@media` and `@document` is styled 22 but the applied named style is `default` (after editing `filetypes.common` to make`default` and `parameter` named styles blindly obvious :), so as usual @eht16 is right ;-P. But if I remove the line above, the applied named style is `parameter`.
@kugel- it was a good idea, but it doesn't work. I don't think its necessary to retain backward compatibility with syntactic entity names, previously `media` and now `group-rule` is mapped to the `parameter` named style which is what the colour schemes should be changing, so they will still work.
It would only be when someone who changed the named style that `media` mapped to in their `filetypes.css` that would not "just work" but they would probably be smart enough to change it again when the new Geany comes out especially if its highlighted in the next release NEWS. Maybe add it to NEWS now so its not forgotten.
Has been working for me for two weeks (with some but not heavy testing), just needs the second CSS GROUP_RULE line removed, it does not work.
So we have to accept that there is a breakage of user edited filetypes.css but thats going to happen any time Lexilla changes syntactic entities incompatibility. I do not think Geany should start committing to a backward compatibility guarantee that Lexilla does not provide.
It's reasonable to expect users who edit `filetypes.css` to check the manual if anything breaks because the first three lines state: ``` # For complete documentation of this file, please see Geany's main documentation [styling] # Edit these in the colorscheme .conf file instead ```
@elextr good to hear we're on the same page.
I can update this PR but I'm unsure if we should wait for 5.1.4 ?
@kugel- Neil just posted 5.1.4 will be "in a few days" so it probably better to wait.
@kugel- pushed 2 commits.
6d109b309165ff0bfb17a2b21056bd498d54c032 Update to Scintilla 5.1.3 and Lexilla 5.1.2 fb7ab270d9e20b2d39f1d14b9a45c6967e691a84 Update to Scintilla 5.1.4 and Lexilla 5.1.3
updated scintilla and removed the defunct compatiblity change.
@kugel- thanks, will test
I've rebased and built this off of master... nothing obvious has gone wrong so far... is there anything I should look for?
@xiota Anything mentioned in the comments above as a problem with previous Scintilla 5 versions, then look for any new highlighting problems in any language you know/use. Then just use it, thats usually when things appear.
So far I have found nothing, will keep using it for the rest of the week. It would be nice if @eth16 and @techee (or anybody else who can build and run on those platforms of course) could try on windows and mac.
So far I have found nothing, will keep using it for the rest of the week. It would be nice if @eht16 [...] could try on windows and mac.
Will do but it will take until the end of November. IMO it'd be OK to merge into master even if Windows is not yet tested. Don't let it getting old here more than necessary.
It's not a major update since 5.1.1 is already in master so I don't expect wildness on Windows. I can have a look too, though.
Don't let it getting old here more than necessary.
Update to Scintilla 5.1.5 and Lexilla 5.1.4 ...
Don't let it getting old here more than necessary.
Yeah, its "nice" not necessary that other platforms are checked before merge, we are a ways off any release, it will get tested plenty before then with split session and ctags stuff to do as well as billions [exaggeration for effect] of small paper cuts.
I swiftly checked windows and it looks good (opened a C file and .ini file, nothing in-depth)
Should the filetypes.css thing be noted anywhere?
The CSS thing is a temporary thing for one version, so I don't think its anything that needs to be in the manual. Probably should be in the release notes for the next release, if we remember it.
What do you mean with "for one version"? Don't we have filetype.css for a long time?
What I mean is that the incompatibility is between two versions, this version may be incompatible with the 1.38 but (hopefully) the next version will be compatible with this one. Geany doesn't document syntactic entities anyway, so its just a warning at release.
So far I have found nothing, will keep using it for the rest of the week. It would be nice if @eht16 and @techee (or anybody else who can build and run on those platforms of course) could try on windows and mac.
I haven't tried this specific pull request but update to Scintilla 5 went without any Mac-specific problems so I don't expect any problem here.
Merged #2930 into master.
github-comments@lists.geany.org