When trying out symbolic links on windows i noticed links breakage when geany saves files accessed through such a link.
Steps to reproduce:
1) Prepare link:
```powershell
$myDesktop = "$($env:USERPROFILE)\Desktop"
New-Item -path "$myDesktop\target.txt"
New-Item -path "$myDesktop\symbolic.txt" -ItemType SymbolicLink -Value "$myDesktop\target.txt"
```
> Note:
> Last statement needs admin privileges (at least until creators update or adapting a policy setting).
2. Use geany to edit ``$myDesktop\symbolic.txt`` and save
Expected behaviour:
Content of ``$myDesktop\target.txt`` reflecting latest edit while ``$myDesktop\symbolic.txt`` still pointing to that file.
Observed behavior:
``$myDesktop\target.txt`` is never touched by the edit. ``$myDesktop\symbolic.txt`` is now a regular file.
This was observed using version 1.30.1
--
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/1533
## General:
* New plugin: keyrecord (PR #460)
* OS X: Use path relative to bundle (PR #569). Affected plugins:
* GeanyGenDoc
* GeniusPaste
* GitChangebar
* Overview
* PoHelper
* Scope
* Add a note to plugins which are currently orphaned and might not
receive further fixes (PR #540). Affected plugins:
* Geanydoc
* GeanyExtrasel
* GeanyInsertNum
* GeanyLua
* GeanyPG
* GeanyPrj
* GeanyVC
* PrettyPrinter
* Scope
* Shiftcolumn
* Treebrowser
## Addons
* Enable Mark Word also for newly opened documents (PR #563)
## Automark
* Extend documentation (PR #582)
## GeanyDoc
* Make OK the default button in interactive mode (PR #566)
## GeanyExtrasel
* Fix issues related to Scintilla Rectancle select (PR #568)
## GeanyLua
* Pass a GdkKeymap to gdk_keymap_* functions to prevent crashes on
Windows and critical warnings on other platforms (PR #586)
## GeanyMacro
* Pass a GdkKeymap to gdk_keymap_* functions to prevent crashes on
Windows and critical warnings on other platforms (PR #586)
## GeanyNumbersBookmarks
* Pass a GdkKeymap to gdk_keymap_* functions to prevent crashes on
Windows and critical warnings on other platforms (PR #586)
## GeniusPaste
* Update configuration for shipped pastebins (PR #551)
## GitChangebar
* Fix spurious line wrapping (PR #564)
## LineOperations
* Add a feature to keep unique lines (PR #560)
## PrettyPrinter
* Add missing README, COPYING, NEWS and AUTHORS files (PR #580)
## ProjectOrganizer
* Fix a crash by ensuring project is open before
trying to expand the tree (PR #555, PR #557, PR #559)
## Scope
* Correct a misleading error message (PR #561)
## Spellcheck
* Stop processing if the document gets invalid to prevent crashes
while file gets closed during long check runs (Issue #547)
* Add style mappings for Rust and PHPSCRIPT
## Updatechecker
* Remove deprecated soup call (PR #541)
## Internationalization
* Updated translations: de, es, pt
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/geany/geany-plugins/releases/tag/1.31.0
Geany can detect a document’s filetype from an explicit Emacs-style mode declaration. The docs say:
> The `GEANY_DEFAULT_FILETYPE_REGEX` default value is `-\*-\s*([^\s]+)\s*-\*-` which finds Emacs filetypes.
In fact, this only works if the captured name case-sensitively matches a Geany filetype name. So `-*-Sh-*-` works, but `-*-sh-*-` doesn’t. `-*-reStructuredText-*-` works in Geany, but not in Emacs, which expects `-*-rst-*-`.
Perhaps the [Geany filetypes table](https://github.com/geany/geany/blob/35a5d457f48c92ecb71b5a2ecf7d7187… should have an “Emacs mode name” field (like it already has a “human title” field), to be matched case-insensitively.
Failing that, at least the docs should be clarified.
--
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/1531
Fixes #1527 as discussed there.
In `win32_show_color_dialog`, `utils_scale_round` is not necessary at all because [`Get{R,G,B}Value`](https://msdn.microsoft.com/en-us/library/windows/desktop/dd144923.aspx) already return 0..255, which we can immediately render as hex.
The resulting code behaves correctly for me under all configurations: Linux and Windows, GTK+2 and GTK+3, with or without native Windows dialogs. (The native [Windows color dialog](https://i-msdn.sec.s-msft.com/dynimg/IC534143.png) does not show `#RRGGBB`, but it does show the individual R, G, B bytes, and I checked against those.)
However, I still have no idea why @elextr was unable to reproduce #1527 while I can easily reproduce it in all configurations (with GTK+ color picker).
I’m also not sure why I remember not having this issue in the past, but it’s likely that I only used the color chooser a few times back then, so I may have missed it.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1536
-- Commit Summary --
* Fix converting color to hex for insertion
-- File Changes --
M src/utils.c (14)
M src/win32.c (5)
-- Patch Links --
https://github.com/geany/geany/pull/1536.patchhttps://github.com/geany/geany/pull/1536.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/1536
Git master, Linux, GTK+2 and GTK+3.
1. Select *Tools* → *Color Chooser*.
2. Pick some color.
3. Click *OK* (GTK+2) or *Select* (GTK+3).
Expected result: Geany inserts the color that I picked.
Actual result: sometimes (randomly, in about half of the cases) Geany insert a slightly different color. For example, if I pick #655252, it might insert #655252 or #655151.
I didn’t have this problem on Geany 1.27.
--
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/1527
([from #1445](https://github.com/geany/geany/pull/1445#issuecomment-313235665))
On Windows (8.1 here), Geany has problems working with files whose full path, when encoded in UTF-8, takes up 260 or more bytes. Such a path is possible if it contains non-ASCII characters.
In particular:
- Geany silently refuses to open more than one such file, instead jumping to the first one, as if they were identical.
- When such a file appears in the goto-symbol pop-up menu, its name is not shown.
- When it is selected from such a pop-up, Geany correctly navigates to the file, but a message is printed to the console (if running with `--verbose`):
Geany: utils_tidy_path: assertion 'g_path_is_absolute(filename)' failed
--
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/1534
It seems newer cppcheck versions are too sensible to uninitialized loop
variables when the loop is created by a macro.
This might be a bug in cppcheck or it just cannot check the loop
properly. By initializing the affected variables explicitly, cppcheck
is happy while the unnecessary initialization should not have any
impacts.
The nightly builds for Debian Unstable are currently broken because of this.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/590
-- Commit Summary --
* Initialize loop variables to make cppcheck happy
-- File Changes --
M addons/src/ao_tasks.c (2)
M autoclose/src/autoclose.c (4)
M commander/src/commander-plugin.c (2)
M geanyextrasel/src/extrasel.c (2)
M geanygendoc/src/ggd-tag-utils.c (20)
M geanylatex/src/geanylatex.c (2)
M geanylua/glspi_doc.c (4)
M git-changebar/src/gcb-plugin.c (4)
M keyrecord/src/keyrecord.c (2)
M overview/overview/overviewui.c (2)
M projectorganizer/src/prjorg-main.c (2)
M projectorganizer/src/prjorg-menu.c (6)
M projectorganizer/src/prjorg-project.c (16)
M projectorganizer/src/prjorg-sidebar.c (8)
M projectorganizer/src/prjorg-utils.c (2)
M scope/src/scope.c (6)
M scope/src/utils.c (2)
M spellcheck/src/gui.c (2)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/590.patchhttps://github.com/geany/geany-plugins/pull/590.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/590
Specifically, with Geany-1.30.1 (default install) on Win7/32-bit, when accessing help from within preferences, help fails to open and the following error is reported in the status bar:
*Failed to open URI: "C:\Program Files\Geany\share\doc\geany\html\index.html#editor-features-preferences": The system cannot find the file specified.*
(The `index.html` file is in that exact location, but it is not being found.)
When opened manually from within IE, the help file opens fine and the URI shown in IE is:
`file:///C:/Program%20Files/Geany/share/doc/geany/html/index.html#editor-features-preferences`
The primary difference being the `file:///` appended to the beginning, but that simply looks to be.how IE reports the URI in the address bar rather than any cause of the failure to open. My only guess is that there is a parse error somewhere, perhaps with the jump reference within the page being tacked on the end of the filename (e.g. `#editor-features-preferences`)
I apologize for initially filing under the different unrelated bug. This is a low-priority issue. Let me know if you need me to provide anything else.
--
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/1522
](http://dialog](https://i-msdn.sec.s-msft.com/dynimg/IC534143.png)){kind=link}