It allows user to record some keystrokes combination and replay it, for example change something minor in five places. That simple feature was in the wishlist for plugins, I've implemented it in the most simple way.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/460
-- Commit Summary --
* Added folder keyrecord
-- File Changes --
A keyrecord/AUTHORS (1)
A keyrecord/COPYING (339)
A keyrecord/ChangeLog (0)
A keyrecord/ChangeLog~ (10)
A keyrecord/Makefile.am (4)
A keyrecord/NEWS (0)
A keyrecord/README (33)
A keyrecord/README~ (56)
A keyrecord/src/Makefile.am (10)
A keyrecord/src/keyrecord.c (228)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/460.patchhttps://github.com/geany/geany-plugins/pull/460.diff
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/460
This pull request aims to be a complete support for systems without gvfs-fuse or fuse installed. It supersedes #963 (I'm creating a new pull request because there are some changes to the used approach, not just addressing issues from the original pull request).
The main changes of this pull request compared to #963 are:
1. More fine-grained approach to GIO usage - previously I for instance replaced all g_file_test() usages with GIO (depending on the configuration) but now it's done only for files which can possibly be remote (i.e. not for config files etc.). If not remote, g_file_...() is still used.
2. Got less crazy about USE_GIO_FILE_OPERATIONS Geany configuration and use this one only when opening/closing documents is involved in the IO. This is when things can go wrong when mixing IO methods. But for other things there's no need to maintain both g_file_...() implementation and GIO implementation and only one of them is used (depending on whether the file can be remote).
3. There's no new plugin API - basically I think plugins don't need to know the value of USE_GIO_FILE_OPERATIONS as they aren't involved in opening/closing documents. If a plugin wants to support remote files, it should use GIO. All existing API functions that could possibly involve file IO have been converted to use GIO. It's not completely black and white as some functions are also used by Geany for opening documents so these still test the USE_GIO_FILE_OPERATIONS value. Not having the file IO functions in the API leads to some duplication of code in plugins but it's not that bad and probably better than adding more and more utility functions to the API.
4. It now works not only when gvfs-fuse is uninstalled, but also when fuse is uninstalled. I was still getting the remote location mounted before I uninstalled fuse and discovered more problems on the way. I recommend testing with fuse uninstalled.
5. Some things like file properties of remote files, TM or saveactions support were missing in the previous pull request. Everything should work now.
6. TM works only for parsing edited file's buffers - there's no support for parsing remote files (we'd have to change ctags for this). I think this is OK as loading complete projects over network could take ages and everything would be frozen as we use blocking GIO. For the same reason I don't plan support for remote projects in my projectorganizer plugin. I haven't really checked how other plugins behave but I don't expect big problems. doc->file_name and doc->real_path can now be URI and if plugins do some reasonable error checking, there should be no problem and they should fail gracefully if they don't use GIO. (I haven't checked but IMO plugins shouldn't read/write doc->file_name as this would interfere with the opened buffer in Geany. Most of the checks I've seen were like if (doc->file_name != NULL) {...}).
7. I didn't get too crazy about saveactions plugin GIO support - it now only supports saving backups into a local directory and not to a remote one. I think nobody will really use remote URI as a location for backups - it would be rather impractical and slow. But can easily add this if someone thinks the opposite.
Apart from the minor limitations I mentioned, I'm not aware of anything missing - I believe this pull request ticks all checkboxes from #1145 with the exception of Windows support which I probably won't do myself and which can be done later independently of this pull request.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1414
-- Commit Summary --
* Replace g_file_test() with a GIO variant when needed
* Update utils_get_path_from_uri() to return URI when using GIO
* Keep URIs in utils_tidy_path()
* Use g_file_new_for_uri() when needed
* Don't create separate tagmanager library
* Preserve URIs in tm_get_real_path()
* Allow parsing remote files opened in the editor
* Merge implementations of write_data_to_disk() and utils_write_file()
* Use gtk_file_chooser_get_uri() in file opening/saving dialogs
* Add GIO version of document_rename_file()
* Use GIO in utils_get_file_list_full()
* Add file reading utils function
* Load project config files using the new utility function
* Remove unnecessary utils functions
* Use g_file_set_contents() instead of utils_write_file() for local files
* Use GIO in utils_mkdir()
* Add GIO implementation to utils_is_file_writable()
* Use GIO for filetypes_detect_from_file()
* Eliminate g_path_is_absolute() direct calls
* Use GIO for file properties dialog
* saveactions: Make backups work for remote files
* Document that document file_name and real_path can be URIs
-- File Changes --
M configure.ac (1)
M plugins/export.c (23)
M plugins/filebrowser.c (74)
M plugins/htmlchars.c (2)
M plugins/saveactions.c (108)
M src/Makefile.am (25)
M src/callbacks.c (10)
M src/dialogs.c (78)
M src/document.c (137)
M src/document.h (4)
M src/filetypes.c (31)
M src/keybindings.c (8)
M src/keyfile.c (8)
M src/libmain.c (13)
M src/msgwindow.c (8)
M src/osx.c (2)
M src/project.c (74)
M src/sidebar.c (2)
M src/stash.c (3)
M src/symbols.c (1)
D src/tagmanager/Makefile.am (32)
M src/tagmanager/tm_source_file.c (54)
M src/tagmanager/tm_source_file.h (3)
M src/toolbar.c (2)
M src/ui_utils.c (8)
M src/utils.c (351)
M src/utils.h (24)
M src/win32.c (4)
-- Patch Links --
https://github.com/geany/geany/pull/1414.patchhttps://github.com/geany/geany/pull/1414.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1414
I have selected an executable from a subdir of `E:\Projects` and when pressing the run button it says "The system cannot find the file specified", which is odd since the the "Setup Program" dialog allowed me to select the file using the file dialog, so I know the file exists Perhaps it's just a misleading error message?
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/337
When linewrap is in effect the height of the overlay is not adjusted if the old line is too long.
Overlay when line wrap is activated.
Overlay when line wrap is off.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/425
Windows filenames (NTFS) may contain unicode characters. Passing the filename to `geany.exe` as command line argument does not open the file.
At startup, it can get all arguments in UTF-16, and convert them to UTF-8. So filenames containing unicode characters can be passed to `geany.exe`.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1258
-- Commit Summary --
* Provide utf-8 command line arguments on Windows
-- File Changes --
M src/main.c (36)
-- Patch Links --
https://github.com/geany/geany/pull/1258.patchhttps://github.com/geany/geany/pull/1258.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1258
I'm coming from AkelPad and this is what I'm missing. There is a function Remove Unique Lines already and I'm looking for exactly the opposite.
Example use case: insert one list, enter an empty line, insert another list, execute, see the lines unique to each list.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/516
This simplifies translations by being less redundant.
Note: label variable is not freed because `keybindings_set_item()` currently assumes static strings but for plugins, so we need not free the label right away. It's not a real problem though, as this string
is required during the whole process' lifetime, so it'd use just as much memory anyway.
Closes #953.
---
I'm not certain this is a great way to fix, but it works. Opinions welcome.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1058
-- Commit Summary --
* Use a format string instead of repeating almost the same string 9 times
-- File Changes --
M src/keybindings.c (39)
-- Patch Links --
https://github.com/geany/geany/pull/1058.patchhttps://github.com/geany/geany/pull/1058.diff
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1058
In Geany for Windows: There is a wrong behaviour of accented
letters (e.g. Czech keyboard) when Caps lock is on: All accented
letters like ě, š, č, ř, ž, ý, etc. are lower case while they should
be upper case. It is known bug in Gtk+
https://bugzilla.gnome.org/show_bug.cgi?id=165385
but it was recently fixed and the fix was already released
in Gtk+ 3.22.7 - see
http://ftp.gnome.org/pub/gnome/sources/gtk+/3.22/gtk+-3.22.7.news
Please update the Gtk+ version used by Geany Windows builds
to Gtk+ 3.22.7 to fix this bug in Geany for Windows.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1374
Add `parfor` to the list of keywords to be highlighted in Matlab script sources. `parfor` is a Matlab keyword that can be used in place of `for` to achieve parallel processing.
Although `parfor` is technically a function, its use is syntactically equivalent to traditional `for`, and therefore it should be treated the same in terms of syntax highlighting.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1021
-- Commit Summary --
* Add parfor to Matlab keyword list
-- File Changes --
M data/filedefs/filetypes.matlab (2)
-- Patch Links --
https://github.com/geany/geany/pull/1021.patchhttps://github.com/geany/geany/pull/1021.diff
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1021