While in general one should avoid returning big structs for performance
reasons, it's no big problem for small structs and it can lead to more
readable code.
Having this check on for everything seems to be too strict - if someone
is returning big structs like crazy, someone will probably notice during
the review. Otherwise it's no problem.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/529
-- Commit Summary --
* Remove -Werror=aggregate-return from travis flags
-- File Changes --
M .travis.yml (2)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/529.patchhttps://github.com/geany/geany-plugins/pull/529.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/529
Since the plugin doesn't only show the changebar but allows also jumping to next/previous hunks and will hopefully also allow undoing hunks via #531, it might be a good idea to have a menu with these actions e.g. as the Tools submenu so they are easier to discover by the users.
--
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/534
Right now it's only possible by hovering mouse over the changebar in the sidebar but it would be nice to have a keyboard-only-friendly way to show it. There could be a keybinding that shows the popup with diff for the hunk at the cursor position.
--
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/533
This commit (or maybe the next one, which further modifies this loop) breaks the functionality on programming language files other than C. That is, it works on .c and .h files, but it stopped showing tasks for example on .vhd (VHDL language) files, even if the tasks are inside comments!. Comments in VHDL start with: --
The comment style, as defined in filetypes.vhdl, is applied on the geany editor, so I guess sci_get_style_at and highlighting_is_comment_style calls would return valid values even for .vhd files
--
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/commit/236363f0e7dfab7db8690cc051a53…
I have configured some build commands for my project:
In Commander, I can invoke independent commands (such as “Run tests”) and execute commands (such as “Run on test input”), but not filetype-specific commands (such as “Pylint”). It seems like Commander just doesn’t see their labels:
---
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/462
When a quick glance at a definition is needed often, going back an forth (Alt+left / Alt+right) in the same window appears less useful than using the split window to view that symbol definition for as many glances as needed.
Is it reasonable to extend splitwindow.c with such a feature?
If yes, would a widget (checkbox/toogle icon?) in the split window toolbar be enough to show this behaviour is active?
--
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/1394
Geany has a preference called “Use project-based session files”. When it’s enabled, a project’s open files are saved on project close and reopened on project open.
I would like a per-project setting to change this behavior such that open files are **opened, but not saved**. In other words, I want to “freeze” a specific set of files to be opened with the project.
My use case: a blunt way to preload a project’s local tags. I have several projects consisting of a few dozen source files each, and I find that simply opening them all at startup is a good way to have all the tags handy. I don’t want heavyweight approaches like Project Organizer.
But I can think of other use cases as well.
Right now I have a blunt patch that relies on the user manually writing `readonly_session=1` in the `.geany` file. I guess that wouldn’t be acceptable for Geany core? What do you think the UI for this feature should look like? Or is it appropriate for Geany core at all?
--
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/1397