OS: Arch Linux
version: 1.30.1 gtk3 from Arch's AUR
With GTK3 on Wayland, vertical scrolling is laggy. When scrolling slowly, its fine but as soon as I scroll faster (possibly one line per frame is the threshold) it starts lagging. It immediately comes to the correct position when I stop scrolling, and occasionally updates while I'm scrolling (about 1fps). Everything works if the window is smaller then half the screen (screen resolution is 2560x1600), but there is still high CPU usage while …
[View More]scrolling.
I encounter the problem on Sway and Gnome on Wayland, but there is no issue on XFCE4 with X11.
Based on the high CPU usage and dependence on window size, my guess is that it is CPU rendering and, if more scroll events have come in before it is done rendering, it renders the next frame and keeps going until it has caught up.
--
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/1526
[View Less]
As a result of discussions in #1233 comments.
Overview:
- Allows proxy plugins to register to pre-match "glob-style" patterns for subplugins.
- Allows passing `NULL` to register to probe all potential subplugin files (ie. pattern `*`).
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1236
-- Commit Summary --
* Change proxy plugins to match by filename suffix
* Change from suffix to Glob-style pattern matching
* Allow proxies to …
[View More]pass `NULL` for the `patterns` parameter
-- File Changes --
M src/plugindata.h (4)
M src/plugins.c (101)
-- Patch Links --
https://github.com/geany/geany/pull/1236.patchhttps://github.com/geany/geany/pull/1236.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/1236
[View Less]
I'm trying to work on multiple projects at the same time, and currently Geany makes this a little difficult.
If I specify the project file in the Geany call, e.g.
geany myproject.geany &
Geany will re-use the running process and force me to close the current project before loading the new one.
If I launch a blank geany process:
geany &
then I can run an arbitrary number of Geany instances, but I have to manually load the project via the Project->Open dialog.
Can you …
[View More]please remove the check to re-use the current running Geany instance, and close the current project? I can't imagine why anyone would want or need that, since a single Geany instance can't handle more than a single project at once.
--
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/1493
[View Less]
Hello!
After last changes on 1.28 for GTK3, in trying once again to be if I could move to Geany with GTK3 , which I prefer over GTK2.
One thing I've noticed is that the colours of the toolbar does not match with the colours of the rest of the interface.
Here is a snapshot of my Geany with GTK - 3.0:
![screenshot from 2016-08-18 00-44-35](https://cloud.githubusercontent.com/assets/2631430/17756021/b001e…
I'm on Ubuntu 16.04 with Ambiance theme.
--
You are receiving this because you are …
[View More]subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1179
[View Less]
This issue is to track the design and implementation of filetype-specific plugin API to allow tighter integration and for plugins to provide advanced IDE functionality to replace or enhance functionality what Geany currently provides in a generic and basic form.
One of the key features of Geany is its lightweight, generally useful language-agnostic support (eg. TM/ctags, generic build commands, customizable default filetype configurations, etc) and it would not be good to start embedding deep …
[View More]knowledge of specific programming languages into the core, this is why it's crucial that such advanced (read: bloated) features remain completely contained in some kind of plugin. No user should pay the cost for such language support for languages they don't use. It's also important that Geany always provide at least its current baseline functionality. Some of the default functionality could indeed be moved into such a plugin, but it should always be the default/fallback and should work out-of-the-box.
Since, for better or worse, we're already tightly tied with the GObject framework (via GTK+) and a GObject-based plugin loader is in the works by @kugel, I propose we use GObject interfaces where appropriate to provide object oriented, language neutral extension points for some or all of the needed features. Some of these interfaces could take some cues from [GtkSourceView's APIs where a plugin implements a "provider" interface](https://developer.gnome.org/gtksourceview/stable/GtkSourceComple… if it wants to provide the particular feature.
I have experimented in the past at trying to integrate libclang into a plugin to provide some of this support for C/C++, but I assume much of it would transfer over to other languages such as using libpython to enhance Python support, or V8 engine to enhance JavaScript.
## Requirements
Though there are probably some things I have not thought of, some of the requirements I've come up while experimenting with implementing this kind of advanced language features and run into road-blocks with are as follows:
- [ ] Allow plugins to provide syntax highlight.
> Remark:
> This could be in the form of providing the Scintilla lexer, either by allowing plugging in as "container lexers" or by allowing plugins to provide a lexer library loaded dynamically into Scintilla (already supported by Scintilla). Alternatively we could provide some kind of interface non-specific to Scintilla for this and have Geany deal with making the styles appear on the screen. This is to allow for advanced semantic highlighting and the likes.
- [ ] Allow plugins to provide the symbols for the tagbar tree, based on their own knowledge of the current document.
> Remark:
> It has been suggested that TagManager (with appropriate enhancements) may be suitable as a means of providing this information to Geany. Some kind of hook/provider interface would still be required in all cases.
- [ ] Allow plugins to provide the auto-complete list, given the current location in the document and the part of the word already typed.
> Remark:
> In the future this could be extended to allow plugins to provide information required to insert those templates where, for example, if a particular function is completed, it inserts a "template" of the prototype and the caret jumps to the first editable position, like the function argument name, or if no arguments into the body of the template where the user probably wants to start typing, when you press tab it keeps jumping to the next editable template placeholder. Some IDEs such as XCode provide this, and I believe Scintilla has some kind of builtin support for implementing this. Further research is required. This particular enhancement could be added afterwards and should not block this issue.
- [ ] Allow plugins to provide a list of calltips to be shown when Geany shows the calltips.
> Remark:
> In the future this could be extended to support additional features like enhanced keyboard navigation, ability to display documentation comment text, etc. Such enhancements should not block this issue.
- [ ] Allow plugins to hook into the build system runner.
> Remark:
> Plugins should be able to provide not only the default build commands, but to dynamically modify them based on user's input (eg. through some configuration dialog they provide). This would allow plugins to do stuff like generating a Makefile based on the user's choices/source code and to update the build commands to run the Makefile in some particular directory, environment, etc.
- [ ] Allow plugins to provide diagnostics when build commands are run.
> Remark:
> This could include not just allowing them to add compiler messages (which is already kind of supported if the plugin inserts Make-like change-directory messages and such into the compiler tab view), but also a more specific than current API for displaying diagnostic messages such as adding those various coloured squiggly lines below errors, putting diagnostic icons (eg. warning, info, error, etc) into the margin for affected lines, and also providing Scintilla annotations or tooltips to give the user more detailed information about the error when hovering over the squigglied text or margin markers. It should also be possible for plugins to nest further information in the compiler messages tab's treeview, so that it can show more than one line, like perhaps in the case of multiple definitions, where the original location was or other such information which may not make sense as the main information line in the compiler tab but can still be useful for some kinds of errors.
## Development/Contribution Strategy
I propose that we create a branch on the main repo (eg. "ft-plugins") against which all pull requests are made. The branch should be kept up to date at regular intervals with the development branch (ie. master) to prevent it getting stale and unmergable. Although it's a significant additional overhead, it would be nice if we could, when merging any changes to master branch, merge them also to and ensure no conflicts with the "ft-plugins" (or whichever) branch.
Everyone who is able should feel free to edit this issue description, but please limit it to gramatical and formatting corrections, adding references/links or if obvious information is missing. Please do fix this description if you are able to improve what it conveys without changing the overall meaning.
Since the changes won't be made on the stable master branch, I propose that we are much more aggressive with making changes, and are much more laid back with what changes get merged, even if not 100% in agreement with them. Once a pull request is merged, it can always be improved, tweaked, or even reverted later. The most useful kind of contribution is actual pull requests/commits. It is often the case with changes to the master branch that discussion ends up defeating progress, so I propose rather than endless discussions we let the code do a lot of the talking. Code reviews are always welcome but should be accompanied by the appropriate patches/PRs/commits. If one is not able/willing to contribute patches/PRs/commits directly, I propose that they wait until the particular changes are ready to be merged back to the master branch to raise minor issues (who knows maybe the issue has been removed or fixed by then). Of course it's useful to discuss fundamental design flaws regardless if one is willing to contribute code or not (see below).
## Discussion Guidelines
Since Github comments are not an ideal discussion platform and can grow out of control, as well as to include more people, foster broader discussions (bikesheds), and in order to keep this issue nice and clean, I propose that we do all of the discussion on the development mailing list. This suggestion is only for this particular Github issue, and need not apply to all related PRs, of course. If nobody minds, I would like to delete extaneous comments on this Github Issue, and keep the comments limited to such stuff as progress reports, meta discussions about the Github issue iself (assignees, labels, milestones), notes about a related PR, etc.
If there is a particular item you wish to discuss, quote it in your mailing list message and provide your suggestions, comments, issues, etc. I propose we choose some unique kind of tag (eg. "FT-Plugins") to put in the subject line of each related mailing list thread to improve searchability. This way we can look back in the archives and easily find related discussions regardless whether they all happened to be nested under a single thread.
Please feel free to "add your reaction" (thumbs up or down) whether you like the overal proposal presented here, in principle, even if not some of the details.
--
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/1195
[View Less]
Anybody mind if I add `*.s` and `*.S` to `filetype_extensions.conf` for `ASM`? It's the extension commonly used by/for GCC/GAS.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/904
Using the following snippets I am able to expand 𝝰 to **alpha** but unable to expand < to <> unless I add < to wordChars which was not needed for 𝝰 which seems inconsistent? I think it would be helpful if symbols could be expanded in situations like **a<** without requiring a leading space, perhaps if they were listed in a symbol: "expandTheseItemsWithOutALeadingSpace" ?
[Special]
brace_open=\n{\n\t
brace_close=}\n
block=\n{\n\t%cursor%\n}
block_cursor=\n{\n\t%cursor%\n}\n%…
[View More]cursor%
wordchars=_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789#$%&:.
[Perl]
𝝰=alpha
<=<>
--
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/1560
[View Less]
Hello Geany Devs,
Feel free to close this issue if you feel that the time
investment or the functionality is not worth to be had
for the geany codebase.
Situation: I have just compiled geany successfully (again,
on a new computer actually).
I am not yet sure whether vte was found or not by geany.
I assume that it should work on my system; mate-terminal
starts fine and I can use it, and I think that mate-terminal
also makes use of vte.
Would it be possible to somewhere add some indicator as
…
[View More]to whether geany:
(a) has been compiled with VTE support or not
(b) whether libvte.so was found?
The reason I would like to have these two parts as indicator
whether everything worked fine, as far as geany is concerned.
I do not have a personal preference as to where the information
is stored. Perhaps a small mini-widget could be added that
displays this information, e. g. compile-time information
how geany was compiled. Vim has something similar on the
commandline, e. g. if you do "vim --version", you get a
lot of information such as a "Compilation:" setting that
tells you with which options vim was compiled.
As for whether libvte.so was found, perhaps a simple widget
in preferences could be used, in the "Terminal" subsection.
For example, if libvte.so (or vte.so, whatever the name was)
was not found, a simple mini-widget could be shown under
the Terminal subsection part, at Preferences, notifying
the user that vte is unavailable in some red colour, or
red colour of the widget's border.
I am not sure if this is actually worth to file an issue
request but as stated above, just feel free to close it
at any moment in time!
--
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/1545
[View Less]