gedit issueshttps://gitlab.gnome.org/GNOME/gedit/-/issues2024-03-12T18:51:39Zhttps://gitlab.gnome.org/GNOME/gedit/-/issues/586Rewrite and re-add the plugin "Open links"2024-03-12T18:51:39ZTill MRewrite and re-add the plugin "Open links"Thank you for all your development work! The plugin "Open links" got removed in version 43, when gedit used Tepl again. However, the plugin is very useful. Please try to adjust it and add it again, if possible.
More info: https://gitlab...Thank you for all your development work! The plugin "Open links" got removed in version 43, when gedit used Tepl again. However, the plugin is very useful. Please try to adjust it and add it again, if possible.
More info: https://gitlab.gnome.org/GNOME/gedit/-/merge_requests/129#note_1516921
The last version: https://gitlab.gnome.org/GNOME/gedit/-/tree/42.2/plugins/openlinkshttps://gitlab.gnome.org/GNOME/gedit/-/issues/583File Browser Panel plugin: know if some files have been filtered2023-12-06T16:33:14ZswilmetFile Browser Panel plugin: know if some files have been filteredFile Browser Panel plugin: know if some files have been filtered.
See https://gitlab.gnome.org/GNOME/gedit/-/issues/581
Instead of `(Empty)`, if there are filtered files not shown in a certain directory, show `(Filtered)` or something ...File Browser Panel plugin: know if some files have been filtered.
See https://gitlab.gnome.org/GNOME/gedit/-/issues/581
Instead of `(Empty)`, if there are filtered files not shown in a certain directory, show `(Filtered)` or something like that.
This could perhaps be generalized: every time a file is filtered and not shown in the list of files, have a button or something to show them.
Currently we need to do a right click --> Filter --> change the options (e.g., "Show Binary").https://gitlab.gnome.org/GNOME/gedit/-/issues/582File Browser Panel plugin: make its features more discoverable2023-12-06T16:24:26ZswilmetFile Browser Panel plugin: make its features more discoverableFile Browser Panel plugin: make its features more discoverable.
See for example: https://gitlab.gnome.org/GNOME/gedit/-/issues/581
A right click is necessary to access the features from the context menu.
GNOME LaTeX also has an embedd...File Browser Panel plugin: make its features more discoverable.
See for example: https://gitlab.gnome.org/GNOME/gedit/-/issues/581
A right click is necessary to access the features from the context menu.
GNOME LaTeX also has an embedded file browser in its side panel, so gedit could take inspiration from it.
But the gedit File Browser Panel plugin has more features compared to the gnome-latex one.https://gitlab.gnome.org/GNOME/gedit/-/issues/580Skip save dialog for untitled document with only blank contents2023-12-02T10:58:17ZArthur CharguéraudSkip save dialog for untitled document with only blank contents[file loading and saving][enhancement]
When an untitled document has never been modified, exiting gedit does not prompt a "save as" dialog box.
However, if an untitled document is edited, then is left with empty contents, the "save as" ...[file loading and saving][enhancement]
When an untitled document has never been modified, exiting gedit does not prompt a "save as" dialog box.
However, if an untitled document is edited, then is left with empty contents, the "save as" dialog box shows.
I see no reason why a user may worry about losing changes to a blank document.
I would therefore suggest to relax the condition for skipping the "save as" dialog box
- from current behavior: skip save dialog if no change has been ever made
- to a new behavior: skip save dialog if the contents is made of only spaces, tabs, and newlines.https://gitlab.gnome.org/GNOME/gedit/-/issues/577Add EditorConfig support2023-08-31T12:09:32ZswilmetAdd EditorConfig supportAdd EditorConfig support.
See: https://editorconfig.org/
Requirements:
- No synchronous I/O.
- Support for any GFile (so remote files too, that rely on gvfs).
- When a certain config is applied, know where it comes from (so the user ca...Add EditorConfig support.
See: https://editorconfig.org/
Requirements:
- No synchronous I/O.
- Support for any GFile (so remote files too, that rely on gvfs).
- When a certain config is applied, know where it comes from (so the user can understand and see the information: if it comes from EditorConfig (which file(s)), if it comes from a modeline, or the default gedit preferences, etc.).https://gitlab.gnome.org/GNOME/gedit/-/issues/573open "save as" dialog when attempting to save non-writable file2023-08-08T16:15:40ZTimon Gehropen "save as" dialog when attempting to save non-writable fileA family member of mine just lost multiple hours of work after editing a Thunderbird attachment in gedit.
Thunderbird opened the text file as a non-writable temporary file and they did not notice before closing the document.
If the file...A family member of mine just lost multiple hours of work after editing a Thunderbird attachment in gedit.
Thunderbird opened the text file as a non-writable temporary file and they did not notice before closing the document.
If the file is not writable, allowing edits but just ignoring CTRL+S is bad application design. It's just asking for data loss to happen.
There are the following common ways applications are addressing this, implementing one is sufficient, but I think it's best to implement both:
1. Do not accept edits to the file in the GUI if it is not writable. (This is what e.g. emacs is doing.)
2. Treat "Save" like "Save As...". (This is what e.g. libreoffice is doing.)https://gitlab.gnome.org/GNOME/gedit/-/issues/571suggestion: don't backslash-unescap when using non-regexp-search2023-08-01T03:14:47ZChristoph Anton Mitterercalestyo@scientia.orgsuggestion: don't backslash-unescap when using non-regexp-searchHey.
When searching in a document not using regular expressions, gedit (at least as of 44.2) still treats `\n`, `\\` as backslash escapes, i.e. the LF and literal `\` characters - while `\` alone as a search term is also valid (and matc...Hey.
When searching in a document not using regular expressions, gedit (at least as of 44.2) still treats `\n`, `\\` as backslash escapes, i.e. the LF and literal `\` characters - while `\` alone as a search term is also valid (and matches the single literal `\`).
I'd say most people do rather not expect that and it seems rather unnatural for a **text** editor, as most of the backslash-escape characters (other than perhaps tab and newline) are not typical for text files.
Wouldn't it make sense to only consider them in regexp mode, or provide another checkbox that allows to select whether they're used?
Right now one always have to manually escape the search strings, if one wants too look e.g. for the literal `\n`.
Cheers,
Chris.https://gitlab.gnome.org/GNOME/gedit/-/issues/570macOS: test with GtkHeaderBar2023-07-29T10:41:03ZswilmetmacOS: test with GtkHeaderBarI've just released gedit 46, and it contains the 'headerbar' build option (see `meson_options.txt`).
By default the 'headerbar' option is in automatic mode, which means that on macOS the headerbar is not present.
But it's possible to f...I've just released gedit 46, and it contains the 'headerbar' build option (see `meson_options.txt`).
By default the 'headerbar' option is in automatic mode, which means that on macOS the headerbar is not present.
But it's possible to force the 'yes' value for the 'headerbar' option.
==> Does gedit **with** headerbar works on macOS? How does it look?
(I don't have a macOS system to test, so help is welcome).https://gitlab.gnome.org/GNOME/gedit/-/issues/569Text wrapping cannot be disabled on individual files, because line-col-menu G...2023-08-10T02:36:55Zlxylxy123456Text wrapping cannot be disabled on individual files, because line-col-menu GMenu is removedI recently switched from gedit 43 to gedit 44, and I realized that the menu on the line and column numbers is removed at this commit https://gitlab.gnome.org/GNOME/gedit/-/commit/8d1954083fc5c96be1a789cbbaed3f3cb0a27754
Version 43.alpha...I recently switched from gedit 43 to gedit 44, and I realized that the menu on the line and column numbers is removed at this commit https://gitlab.gnome.org/GNOME/gedit/-/commit/8d1954083fc5c96be1a789cbbaed3f3cb0a27754
Version 43.alpha (Fedora 37):
![43](/uploads/b1fb69ac60a8c8d1d07dc590f6831da0/43.png)
Version 44.2 (Debian 12):
![44](/uploads/7cc4a25d90733fb798b5b42970fc99a3/44.png)
I am wondering whether this menu can be added back. I frequently use this menu when opening different types of files. For most of my files I enable text wrappingvia the Preferences Dialog. However, when I occasionally view files with long lines (e.g. `/var/log/apache2/access.log`), I disable text wrapping using the line-col-menu GMenu. Without this menu, I cannot disable text wrapping for some files while keeping it enabled on other files.
Is it possible to revert https://gitlab.gnome.org/GNOME/gedit/-/commit/8d1954083fc5c96be1a789cbbaed3f3cb0a27754 and similar commits? Or is it possible to develop a gedit extension to bring the menu back? Otherwise is there a workaround to this problem? Thank you.https://gitlab.gnome.org/GNOME/gedit/-/issues/566Allow opening links with Shift+click or similar2024-03-12T18:51:39ZJake HerrmannAllow opening links with Shift+click or similarCurrently, with the Open Links plugin, the user can right-click a URL to open it from a context menu. However, it would be faster and more convenient to also have the ability to Shift+click or Ctrl+click on URLs to open them.Currently, with the Open Links plugin, the user can right-click a URL to open it from a context menu. However, it would be faster and more convenient to also have the ability to Shift+click or Ctrl+click on URLs to open them.https://gitlab.gnome.org/GNOME/gedit/-/issues/561Gedit unable to save to network share2023-05-30T13:10:55ZDONALD HINDERMANGedit unable to save to network shareWhen i open files with Gedit from a network location, SMB in my case, i am unable to save them. When i save i get and error
"Could not save the file "/home/user/SMB-mounted-network-location/test/file.txt
Unexpected error: Error renami...When i open files with Gedit from a network location, SMB in my case, i am unable to save them. When i save i get and error
"Could not save the file "/home/user/SMB-mounted-network-location/test/file.txt
Unexpected error: Error renaming temporary file: Resource temporarily unavailable"
and in the same folder from where i opened "file.txt" a temporary file is created ".goutputstream-EG2451". I have checked the permissions on the SMB server for the ".goutputstream-AO9U51" temporary file and it is exactly the same permissions as that of "file.txt".
**file.txt permissions**
```
----------+ 1 user other 13 May 28 21:37 file.txt
0:group:testg:read_data/write_data/append_data/read_xattr/write_xattr
/execute/delete_child/read_attributes/write_attributes/delete
/read_acl/write_acl/write_owner/synchronize:inherited:allow
```
**.goutputstream-EG2451 permissions**
```
----------+ 1 user other 13 May 30 03:02 .goutputstream-EG2451
0:group:testg:read_data/write_data/append_data/read_xattr/write_xattr
/execute/delete_child/read_attributes/write_attributes/delete
/read_acl/write_acl/write_owner/synchronize:inherited:allow
```
The "user" is in the group "testg". I can open the same file with vi edit and save. I can also open LibreOffice documents from the same network location edit and save. The user can create directories on the network share, copy files/directories to, delete files/directories, etc. So no question that permissions are set correct. The group that the "user" is in has full permissions.
If i launch Gedit from cli i see a message on cli when saving the file "Hit unhandled case 27 (Error renaming temporary file: Resource temporarily unavailable) in parse_error."
I have read reports [1](https://askubuntu.com/questions/13843/gedit-sshfs-wont-save-vi-saves-fine) [2](https://unix.stackexchange.com/questions/52951/gedit-wont-save-a-file-on-a-virtualbox-share-text-file-busy) [3](https://gitlab.gnome.org/GNOME/glib/-/issues/438) [4](https://illumos.topicbox.com/groups/omnios-discuss/Tc4c6b72d6386f9fb/resource-temporarily-unavailable-when-saving-to-cifs-share-on-r151038) dating as far back as 12 years all with the same problem.
On issue [438](https://gitlab.gnome.org/GNOME/glib/-/issues/438) it is reported that "As far as I can tell, the problem is in the way glib saves a file by writing to a temporary file and renaming to the final name." and "I'll take a more serious look later but I'd start with gio/glocalfileoutputstream.c and particularly the function _g_local_file_output_stream_really_close which contains the error string "Error renaming temporary file".".
A duplicate issue [565](https://gitlab.gnome.org/GNOME/glib/-/issues/565) to issue 438 was opened and there a patch is provided that is said to fix this issue.
All that said, i am still unsure if this is in fact an issue with Glib or if the issue is with Gedit. But i can say that i don't experience this issue with any other software that i use and i keep all of my data on network shares. If another application did the same i would pick it up.
I have tested this on Fedora 37 and Debian 11.https://gitlab.gnome.org/GNOME/gedit/-/issues/559Possible issue running gedit on Mac since Homebrew update around 3rd of May 2...2023-08-15T00:22:59ZFrank ZeydaPossible issue running gedit on Mac since Homebrew update around 3rd of May 2023.After a recent update of Homebrew packages from 3rd of May 2023 (here the relevant extract of brew list -lt)
```
drwxr-xr-x 3 frankzeyda admin 96 May 3 23:47 gedit
drwxr-xr-x 3 frankzeyda admin 96 May 3 20:21 poppler
drwxr-xr-x ...After a recent update of Homebrew packages from 3rd of May 2023 (here the relevant extract of brew list -lt)
```
drwxr-xr-x 3 frankzeyda admin 96 May 3 23:47 gedit
drwxr-xr-x 3 frankzeyda admin 96 May 3 20:21 poppler
drwxr-xr-x 3 frankzeyda admin 96 May 3 20:21 tepl
drwxr-xr-x 3 frankzeyda admin 96 May 3 20:21 libgedit-gtksourceview
drwxr-xr-x 3 frankzeyda admin 96 May 3 20:21 libxml2
```
gedit seems not to start anymore on my MacBook Pro (Apple M1 Max, 32 GB, Ventura 13.1.1 (a)).
Here are some more details. Firstly, starting `gedit`, i.e., from the Terminal produces the following output:
```
(gedit:8990): GLib-GObject-CRITICAL **: 14:00:05.946: cannot register existing type 'GtkSourceStyleSchemeManager'
(gedit:8990): GLib-GObject-CRITICAL **: 14:00:05.946: cannot add private field to invalid (non-instantiatable) type '<invalid>'
(gedit:8990): GLib-CRITICAL **: 14:00:05.946: g_once_init_leave: assertion 'result != 0' failed
(gedit:8990): GLib-GObject-CRITICAL **: 14:00:05.946: g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
```
Secondly, no gedit application window pops up. Neither does any segmentation fault or crash seem to occur (hence I cannot attach a stack trace or similar) - the application merely stops responding until forcefully terminated.
I wonder of other Mac users with a similar OS version may be able to reproduce and/or confirm this behavior. I must say that I encountered sporadic crashes of gedit (about 50/50 chance it will start and not crash during operation) on Mac even before the above-mentioned update - I can elaborate on this if needed.
Best wishes, and let me know if you need further info.
Frankhttps://gitlab.gnome.org/GNOME/gedit/-/issues/554Critical message on startup related to GFileInfo2023-04-27T16:14:11ZArjun SureshCritical message on startup related to GFileInfoI am running gedit from Builder app
```
(gedit:2): GLib-GIO-CRITICAL **: 18:19:28.782: GFileInfo created without standard::is-backup
(gedit:2): GLib-GIO-CRITICAL **: 18:19:28.783: file ../gio/gfileinfo.c: line 1609 (g_file_info_get_is...I am running gedit from Builder app
```
(gedit:2): GLib-GIO-CRITICAL **: 18:19:28.782: GFileInfo created without standard::is-backup
(gedit:2): GLib-GIO-CRITICAL **: 18:19:28.783: file ../gio/gfileinfo.c: line 1609 (g_file_info_get_is_backup): should not be reached
```
similar to issue fixed by https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1143
caused by https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3261
g_file_info_get_is_backup used in repo at https://gitlab.gnome.org/GNOME/gedit/-/blob/master/plugins/filebrowser/gedit-file-browser-store.c#L1922
and another place is causing it .
In nautilius fix, they are using alternative method which doesn't throw the error.
if is_hidden is not populated to GFileInfo how gedit should behave ?https://gitlab.gnome.org/GNOME/gedit/-/issues/552If classic or tango color scheme, automatically switch to oblivion when switc...2023-08-12T12:49:59ZswilmetIf classic or tango color scheme, automatically switch to oblivion when switching to a dark GTK themeIf classic or tango color scheme, automatically switch to oblivion when switching to a dark GTK theme.
And vice versa (to the previous setting).
We know that classic and tango have light colors, and that oblivion has dark colors, so wh...If classic or tango color scheme, automatically switch to oblivion when switching to a dark GTK theme.
And vice versa (to the previous setting).
We know that classic and tango have light colors, and that oblivion has dark colors, so when the user switches the GTK theme to a dark/light theme, gedit could also switch its color scheme (or "style scheme").
See also: https://gitlab.gnome.org/GNOME/gedit/-/issues/547https://gitlab.gnome.org/GNOME/gedit/-/issues/551Add API to document keyboard shortcuts added by a plugin2023-02-01T19:02:27ZswilmetAdd API to document keyboard shortcuts added by a pluginAdd API to document keyboard shortcuts added by a plugin.
One of the best places to document a keyboard shortcut (or "accelerator", "keybinding") - currently - is in the Keyboard Shortcuts window, created with GtkShortcutsWindow.
The i...Add API to document keyboard shortcuts added by a plugin.
One of the best places to document a keyboard shortcut (or "accelerator", "keybinding") - currently - is in the Keyboard Shortcuts window, created with GtkShortcutsWindow.
The idea is:
- When a plugin is enabled, its keyboard shortcuts are documented in the GtkShortcutsWindow.
- When a plugin is disabled, its keyboard shortcuts are _not_ documented in the GtkShortcutsWindow.
So a plugin needs to have a way to register what keyboard shortcuts it adds to the application (for documentation purposes).https://gitlab.gnome.org/GNOME/gedit/-/issues/547Color schemes: classic and tango have white text on white background when dar...2023-08-12T12:49:59ZHosen TraegerColor schemes: classic and tango have white text on white background when dark GTK theme is enabled(![Bildschirmfoto_vom_2023-01-21_16-03-38](/uploads/acebbe2478f0a82b06e9c8c268bc83e0/Bildschirmfoto_vom_2023-01-21_16-03-38.png))
The current line highlight of the default theme causes the text to be unreadable when a dark theme is enab...(![Bildschirmfoto_vom_2023-01-21_16-03-38](/uploads/acebbe2478f0a82b06e9c8c268bc83e0/Bildschirmfoto_vom_2023-01-21_16-03-38.png))
The current line highlight of the default theme causes the text to be unreadable when a dark theme is enabled.
After doing some research i found that the file that causes this is the tango.xml file located in /usr/share/gtksourceview-4/styles
As a solution i would suggest replacing the current highlight color in line 58 of the tango.xml with another value, eg a transparent grey as rgba colour. This can be done in a way that there won't be any visible difference to the current state with light theme enabled.https://gitlab.gnome.org/GNOME/gedit/-/issues/546Add tooltips for the icons located in the main menu (revert, print and fullsc...2023-02-01T19:30:38ZswilmetAdd tooltips for the icons located in the main menu (revert, print and fullscreen actions)Add tooltips for the icons located in the main menu (revert, print and fullscreen actions).
For new users, it can be useful to better know what these icons do, especially for the Revert action.
So when hovering the mouse on an icon, sh...Add tooltips for the icons located in the main menu (revert, print and fullscreen actions).
For new users, it can be useful to better know what these icons do, especially for the Revert action.
So when hovering the mouse on an icon, show a tooltip.https://gitlab.gnome.org/GNOME/gedit/-/issues/540For all plugins: make it easy to know where a plugin adds its features2023-01-05T20:34:48ZswilmetFor all plugins: make it easy to know where a plugin adds its featuresFor all plugins: make it easy to know where a plugin adds its features.
From the preferences dialog, when we enable a plugin, it is not always obvious where the feature(s) is added and how to access/trigger it.
A plugin can add somethi...For all plugins: make it easy to know where a plugin adds its features.
From the preferences dialog, when we enable a plugin, it is not always obvious where the feature(s) is added and how to access/trigger it.
A plugin can add something to:
- the side panel.
- the bottom panel.
- the main menu.
- as keyboard shortcuts.
- and probably a few other possible things.
Of course there is always the full user manual, but it would be handy to know more easily where a plugin basically plug in things. Directly from the preferences dialog, as standard information for each plugin.https://gitlab.gnome.org/GNOME/gedit/-/issues/536macOS-specific code refresh and cleanup2023-07-29T10:41:03ZswilmetmacOS-specific code refresh and cleanupgedit has some macOS-specific code.
With time, it would be great to reduce the delta between the Linux version and the macOS version, to have cross-platform code.
See also the other issues filed with the macOS tag.
Help welcome, as I ...gedit has some macOS-specific code.
With time, it would be great to reduce the delta between the Linux version and the macOS version, to have cross-platform code.
See also the other issues filed with the macOS tag.
Help welcome, as I don't use macOS. Any takers?https://gitlab.gnome.org/GNOME/gedit/-/issues/535reinstate overview map2024-02-08T16:31:10ZBarnabás Pőczereinstate overview mapAs far as I can see, the overview map has unfortunately fallen victim to the reteplification of gedit. Would it be possible to restore it? Does the rationale outlined in 26899e0ba7c1390c098b61fc7a901d700c4e745c still apply?As far as I can see, the overview map has unfortunately fallen victim to the reteplification of gedit. Would it be possible to restore it? Does the rationale outlined in 26899e0ba7c1390c098b61fc7a901d700c4e745c still apply?