gtksourceview issueshttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues2023-09-03T16:01:40Zhttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/329Markdown incorrectly highlight a image tag after a checkbox.2023-09-03T16:01:40ZHugo Parente LimaMarkdown incorrectly highlight a image tag after a checkbox.Probably the checkbox regex need to match to exactly one character to fix this.
![image](/uploads/d0323c4814f72a896b278fa4b7311c65/image.png)Probably the checkbox regex need to match to exactly one character to fix this.
![image](/uploads/d0323c4814f72a896b278fa4b7311c65/image.png)Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/325asterisk keycap emoji breaks markdown2023-07-28T23:48:43Ztwoasterisk keycap emoji breaks markdownGNOME Nightly Text Editor:
![the same file example.md appears as many asterisk keycaps emojis in terminal, but as alternating italic emojis, empty keycaps, and big asterisks in text editor nightly](/uploads/d34275113d645b6c92bac77904372...GNOME Nightly Text Editor:
![the same file example.md appears as many asterisk keycaps emojis in terminal, but as alternating italic emojis, empty keycaps, and big asterisks in text editor nightly](/uploads/d34275113d645b6c92bac77904372f7a/the_same_file_appears_as_many_asterisk_keycaps_emojis_in_terminal__but_as_alternating_italic_emojis__empty_keycaps__and_big_asterisks_in_text_editor_nightly.png)Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/274JavaScript: Static and async keyword stops working after {} in class property2022-11-18T15:37:07ZTheKodeToadJavaScript: Static and async keyword stops working after {} in class propertySample.
```js
class StaticTest {
static worksFine() {
var isFine = {};
}
static stillWorks() {
{
// is this even allowed?
}
}
static myField = {;
static myOtherField = {};
static nowItStopsWorking;
async fetchStu...Sample.
```js
class StaticTest {
static worksFine() {
var isFine = {};
}
static stillWorks() {
{
// is this even allowed?
}
}
static myField = {;
static myOtherField = {};
static nowItStopsWorking;
async fetchStuff() {
return new Promise((resolve) => {
// stuff
resolve();
});
}
}
```
As you can see, GitLab has no trouble. Here is how gnome-text-editor renders it:
![image](/uploads/91ea934e7cce38581452f7d3f8e3926c/image.png)
The issue occurs even without the deliberate syntax errors.Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/235GtkSourceMap: slider position wrong after widget resize2022-07-14T06:35:42ZSophie HeroldGtkSourceMap: slider position wrong after widget resizeI cannot really describe what's going on. Therefore a video. Maybe it's not the indicator itself that is off but the area of the map that is shown?
![Screencast_from_12.11.2021_21_05_16](/uploads/4d84132094c1b88980733fa52a734279/Screenc...I cannot really describe what's going on. Therefore a video. Maybe it's not the indicator itself that is off but the area of the map that is shown?
![Screencast_from_12.11.2021_21_05_16](/uploads/4d84132094c1b88980733fa52a734279/Screencast_from_12.11.2021_21_05_16.webm)Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/208GtkSourceFileLoader: add policy for complex files2023-08-09T04:11:59ZChristian HergertGtkSourceFileLoader: add policy for complex filesWe may want to prevent fully loading a file from `GtkSourceFileLoader` if it has too many lines, or too long of lines, or generally anything else that GtkTextView does not handle reasonably well.
We can do something similar to how mount...We may want to prevent fully loading a file from `GtkSourceFileLoader` if it has too many lines, or too long of lines, or generally anything else that GtkTextView does not handle reasonably well.
We can do something similar to how mountoperation factories work, in either GtkSourceFile or GtkSourceFileLoader.
In particular, some applications may want to display a dialog that asks the user if they really want to perform the action as it may reduce system performance.Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/173GtkSourceBuffer: bracket matching can get confused by escaped parentheses2021-07-29T01:08:05ZAndrew HicksGtkSourceBuffer: bracket matching can get confused by escaped parenthesesWhile it is highlighted in a different color, escaped parentheses in regex do not seem to be completely ignored.![Screenshot_from_2021-01-23_16-21-29](/uploads/542734587398ce3cfabcfd6a425ab4e4/Screenshot_from_2021-01-23_16-21-29.png)While it is highlighted in a different color, escaped parentheses in regex do not seem to be completely ignored.![Screenshot_from_2021-01-23_16-21-29](/uploads/542734587398ce3cfabcfd6a425ab4e4/Screenshot_from_2021-01-23_16-21-29.png)Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/172GtkSourceSearchContext: Make "Replace" and "Replace All" consistent regarding...2021-07-29T00:40:24ZGaël BonithonGtkSourceSearchContext: Make "Replace" and "Replace All" consistent regarding characters escape and fill in the documentationRelated issues: #69, #169
Currently, `gtk_source_search_context_replace()` [always uses `g_regex_replace()`](https://gitlab.gnome.org/GNOME/gtksourceview/-/blob/7325e14208ea720716818b5fc3d63e829f53d31a/gtksourceview/gtksourcesearchconte...Related issues: #69, #169
Currently, `gtk_source_search_context_replace()` [always uses `g_regex_replace()`](https://gitlab.gnome.org/GNOME/gtksourceview/-/blob/7325e14208ea720716818b5fc3d63e829f53d31a/gtksourceview/gtksourcesearchcontext.c#L3713) to replace text when regex search is enabled, whereas `gtk_source_search_context_replace_all()` [uses `g_regex_replace()` only if there are back references](https://gitlab.gnome.org/GNOME/gtksourceview/-/blob/7325e14208ea720716818b5fc3d63e829f53d31a/gtksourceview/gtksourcesearchcontext.c#L3817) in the replacement text.
These two behaviors should be made consistent, and the documentation should indicate whether or not to use `gtk_source_utils_unescape_search_text()` to unescape characters in the replacement text.
Personally, I would say that the correct behavior is the one of `gtk_source_search_context_replace()` and that it should be extended to `gtk_source_search_context_replace_all()`, so that it is not necessary to unescape characters when regex search is enabled, regardless of the replacement method used.Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/167GtkSourceSearchContext: add API to search within selection range2023-11-15T00:02:44ZChristian HergertGtkSourceSearchContext: add API to search within selection rangeIt would be nice if we can use the search API but restrict things to a given range of text (such as the current selection).
This would need to insert marks up front, and then skip anything that is not between those marks as we progress ...It would be nice if we can use the search API but restrict things to a given range of text (such as the current selection).
This would need to insert marks up front, and then skip anything that is not between those marks as we progress through the buffer.
See the original of this at https://bugzilla.gnome.org/show_bug.cgi?id=767783Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/164GtkSourceSearchContext: simple asynchronous search does not succeed when comb...2021-07-29T00:40:12ZGaël BonithonGtkSourceSearchContext: simple asynchronous search does not succeed when combining the "highlight" property with regex searchGtkSourceView versions:<br>
3.24.11<br>
4.8.0<br>
Steps to reproduce:
* Open the [attached file](/uploads/4e6ae52d3833126a04c8738f42e9d77c/bash.1.html) in Gedit (I used Gedit 3.38.0, GtkSourceView 4.8.0);
* Be sure to have "search-highl...GtkSourceView versions:<br>
3.24.11<br>
4.8.0<br>
Steps to reproduce:
* Open the [attached file](/uploads/4e6ae52d3833126a04c8738f42e9d77c/bash.1.html) in Gedit (I used Gedit 3.38.0, GtkSourceView 4.8.0);
* Be sure to have "search-highlighting" set to true (run `gsettings set org.gnome.gedit.preferences.editor search-highlighting true` if needed);
* Go to line 7500;
* Open the "Find and Replace" dialog, enable regex search, and search for something on line 7501 (`<` or `p` or whatever you want)
Expected result: the search should succeed quickly.
Actual result: the search takes very long to succeed (or doesn't succeed at all in some cases?).
This issue does not happen if regex search and/or "search-highlighting" are disabled. When the search above is running, if you set "search-highlighting" to false via `gsettings`, it will make the search succeed almost instantaneously.
I initially encountered this issue while tinkering Mousepad code (the Xfce text editor), which uses on my system GtkSourceView 3.24.11. That's why I can also say that it is reproducible with GtkSourceView 3.24.11, and only for asynchronous searches: Mousepad currently runs only synchronous searches (so this issue is not reproducible with Mousepad master), and I'm precisely working to make them asynchronous.Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/97GtkSourceContextEngine: contexts from different languages do not retain styli...2022-01-14T18:55:03ZJeffery ToGtkSourceContextEngine: contexts from different languages do not retain styling in aggregatation(Tested with gtksourceview 4.4.0, gedit 3.34.0, Ubuntu 19.10)
If test-a.lang replaces `def:c-like-comment-multiline` (note: `style-ref="warning"`):
```xml
<context id="test-a-c-like-comment-multiline" style-ref="warning">
<start>/\*<...(Tested with gtksourceview 4.4.0, gedit 3.34.0, Ubuntu 19.10)
If test-a.lang replaces `def:c-like-comment-multiline` (note: `style-ref="warning"`):
```xml
<context id="test-a-c-like-comment-multiline" style-ref="warning">
<start>/\*</start>
<end>\*/</end>
</context>
<replace id="def:c-like-comment-multiline" ref="test-a-c-like-comment-multiline"/>
```
and test-b.lang also replaces `def:c-like-comment-multiline` (note: `style-ref="error"`):
```xml
<context id="test-b-c-like-comment-multiline" style-ref="error">
<start>/\*</start>
<end>\*/</end>
</context>
<replace id="def:c-like-comment-multiline" ref="test-b-c-like-comment-multiline"/>
```
then, when the definitions are used separately there is no issue.
Highlighted with test-a.lang:
![test-a-lang](/uploads/2097b9e0d311ea02d058ca8d88f16311/test-a-lang.png)
Highlighted with test-b.lang:
![test-b-lang](/uploads/a3ec35966244a9f63143933f382cfe75/test-b-lang.png)
But if these two definitions are referenced by an "aggregate" language (test.lang):
```xml
<context id="test-a">
<start>test-a {</start>
<end>}</end>
<include>
<context ref="test-a:test-a"/>
</include>
</context>
<context id="test-b">
<start>test-b {</start>
<end>}</end>
<include>
<context ref="test-b:test-b"/>
</include>
</context>
<context id="test" class="no-spell-check">
<include>
<context ref="def:c-like-comment-multiline"/>
<context ref="test-a"/>
<context ref="test-b"/>
</include>
</context>
```
then one of the replacement contexts (the "last" one, in some order) will be used for all three languages:
![test-lang](/uploads/dc95653f1c2870aca6409ddbc03b9b0f/test-lang.png)
This is probably working as designed, but I thought I should document this behaviour anyway.
(I encountered this while working on the HTML/CSS/JS definitions - html.lang references css.lang and javascript.lang to highlight code in `<style>` and `<script>` elements.)
This may become a more serious issue if there are more aggregate languages, e.g. if markdown.lang starts using other language definitions to highlight code in fenced code blocks:
```css
body { color: red; }
```
Test files:
* [test-a.lang](/uploads/c2254b5fb49ac1ce73520079815ea3fd/test-a.lang)
* [test-b.lang](/uploads/0472f9fe9ba6c6fee25d1a93c7cdd1d2/test-b.lang)
* [test.lang](/uploads/f87c7ee94975da2ea6dc4fcf0fe52889/test.lang)
* [file.test](/uploads/3f278643db56f3050a87d7ac290ef5f4/file.test)Backloghttps://gitlab.gnome.org/GNOME/gtksourceview/-/issues/14GtkSourceLanguage: Simple/keyword contexts do not correctly end grandparents2022-01-14T18:53:39ZJeffery ToGtkSourceLanguage: Simple/keyword contexts do not correctly end grandparentsTested with gedit 3.28.1 on Ubuntu 18.04. (Apologies if this has already been fixed in master.)
The structure:
* Grandparent container context A includes parent container context B
* Parent container context B includes child context C
*...Tested with gedit 3.28.1 on Ubuntu 18.04. (Apologies if this has already been fixed in master.)
The structure:
* Grandparent container context A includes parent container context B
* Parent container context B includes child context C
* Parent context B and child context C both have `end-parent="true"`
If child context C is a container context (has `<start>` element), then when it ends, parent context B and grandparent context A are both ended correctly.
But if child context C is a simple (`<match>`) or keyword (`<keyword>`) context, then parent context B will end but the grandparent context A will not end.
Test case:
[test.lang](/uploads/482f5de13dca5ce5bbceea7c12ea8e30/test.lang)
[end-parent.test](/uploads/e9e2600cdcb08a8527517eebe11cdc7f/end-parent.test)
[screenshot](/uploads/7a469969a5cde936e8c85773b5afa8f8/screenshot.png)Backlog