Hi all,
I just made a test build of Geany Plugins 1.22 for Windows.
A little surprisingly for me, it all worked fine on the first attempt :).
I only had problems loading the Geany-Lua plugin with some strange error
message which I didn't investigate yet:
http://pastebin.geany.org/EUmwJ/
The error message occurs on plugin loading. I'm not sure whether it is
caused by my system or something else.
If anyone wants to test it, any feedback is appreciated.
The installer...
http://www.uvena.de/tmp/geany-plugins-1.22_setup_testbuild.exe
... requires an existing Geany 1.22 installation.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Matthew Brush <notifications(a)github.com> wrote:
> @elextr FWIW, the files `makefile.win32` and `win32env.mk` (and geanypy.nsis for the installer and README.win32 for the instructions) are needed for `src/makefile.win32` to be useful.
>
> @eht16 Any chance you could get some time to try getting the Waf build system working so it can be built on Windows?
Taking cause from Geanypy, there are 2 small problems with $subject:
- no header fiels are installed, or maybe they are copied somewhere
outside the $prefix. Copying the headers manually is OK.
- geany.pc contains paths with single backslashes, and plugins build
fails with "c:path1path2...: no such file or directory". Replacing
with forward slashes works. All other .pc files I've checked under
win32 use forward slashes.
I haven't tried the latest git though.
--
E-gards: Jimmy
Hi Enrico,
We have had a report on IRC that running geany on the windows command
line will only open files in the Geany install directory unless you
use the full path.
eg C:\somepath> geany somefile.txt
will open installpath\somefile.txt not somepath\somefile.txt.
And with the "Open new documents from the command line" option set it
creates somefile.txt in the install dir since it doesn't exist there.
Suspicion is falling on
https://github.com/geany/geany/commit/775ef628688c69de34640e12666aed5762a80…
As the most experienced windowser (and the committer of that change)
could you look at it please?
Cheers
Lex
Hi All,
Its about that time of year when we have our annual discussion on
separating session data from config/project data :)
By session data I mean the list of currently open files and MRU list.
The advantages (that I can see):
1. Save config/project as its changed and not rushed at quit time (and
the quit save doesn't happen in the absence of a working, portable,
session management capability)
2. Save session data periodically, or as it changes, or whenever,
without touching the config/project files. So the config isn't at
risk if the session save goes wrong.
The only disadvantage for user config (that I can see) is that it adds
one file, say geany.session.conf alongside geany.conf
For project sessions just using another file in the same place as the
project file is more of a problem since project files can be in the
project tree and some people like to save them in VCS. So users would
have to make sure that their git.ignore (or whatever the other VCSes
use) is edited each time so that the session file isn't saved in the
VCS.
A better option, especially since sessions are inherently user
related, is to store them in the user config location (or subdirectory
thereof). But how to link these files to the project files?
The proposal is that each project gets a UUID generated when it is
created (or when its opened without one) which is saved in the project
file. This uuid is the name of the session file in the
${GEANY_CONFIG}/sessions directory. That way, when a project is
opened, it is easy to uniquely find the session file if it exists.
Using things like filenames, project names etc will always have
clashes. Libuuid is used by GTK so it will always be available on all
platforms we use and so making the UUID is one call. (Pity GTK doesn't
expose it though)
The number of session files can be left to grow like weeds, or can be
trimmed to a (configurable) maximum number deleting the oldest when
needed.
This proposal isn't about a proper session management capability,
there isn't one that works on enough platforms to be worth including.
Any thoughts welcome.
Cheers
Lex
Hello,
I just wanted to let you know that I'm working on a new splitwindow
implementation and I would like to have early input. But, also as a
warning, I'm progressing only slowly because I'm at the final phase of
my master thesis which currently needs more attention that Geany hacking.
Anyway, we all know about the limitations of the splitwindow plugin.
They include (not a complete list):
- the other view can only have one document
- you cannot undo/redo: you need to select the tab in the main notebook
to do that
- state is not saved/restored across Geany restarts
- it's completely awkward because the other view shows a doc that's also
in the main view, editing in the other view will change the main view at
the same time.
- you cannot toggle between the views with a keybinding (e.g. ctrl+tab)
- weird focus behavior
- more...
My plan is to reimplement splitwindow using a different approach: by
having two real, independemt notebooks, one primary and one seconary.
New docs will be opened in the primary one by default, but can be moved
to the secondary one at will. This means that no document can be shown
in both at the same time which makes it a loss less awkward. It also
lets us lift the other limitations:
- undo/redo will work
- state can be saved across restarts (config file format will probably
need some changes for this)
- toggling with keybindings between views can work
- you can arbitrarily assign docs to views using different methods
The nice things about splitwindow that should be probably be kept:
- chose between horizontal and vertical split
- automatic sizing of the views
- anything else?
Unfortunately Geany's core is pretty hardcoded as to assume one (and
only one) notebook for documents. This means that for this various
changes to Geany core are necessasry, some of which may be difficult to
do without breaking the plugin API/ABI. Some are gonna hate this but I'm
not currently planning do this as a plugin because the core needs a lot
of changes anyway for breaking the single notebook assumption. But I'm
very open for discussion which is why I'm writing this early.
I already have an experimental version up and running that doesn't even
require all that much changes[1] and it seems to work nicely. See
this[2] screenshot.
So, any opinions?
[1]: https://github.com/kugel-/geany/tree/splitwindow2
[2]: http://www.alice-dsl.net/simonemartitz/default/splitwindow2.png
Best regards.
Hi all!
While playing with colors for pairtaghighlighter plugin, I saw that
Scintilla is using BGR instead of normal RGB. I found existing code in
Geany source to use it in my plugin.
utils_invert_color from utils.c deals with replacing blue with red, but
with mistake.
Below are results of my testing with random color:
11111111 11001100 10011001 - input color
10011001 11001100 11111111 - result of my function (rgb2bgr)
00000000 00110011 01100110 - result of utils_invert_color
A little source file is attached.
If it is really mistake (maybe I don't know something), I will do commit
and pull request.
Any comments about this?
--
Best regards,
Volodymyr Kononenko
http://kononenko.ws
To all those who were adamant that Geany must support windows, what about
providing some support to the nice man on the bug list?
http://sourceforge.net/p/geany/bugs/1001/
Cheers
Lex
PS Matthew you are excused since you have already tried to help.
Hello folks,
I like this nice editor and I am interested to know if it would be possible
to add Harbour (www.harbour-project.org) language to it with syntax
highlighting, intellisense, etc...
I tried to read the “hack geany” webpage but I have to admit it was
confusing to me...
How can I add Harbour to it? I have a list of functions, commands and
directives. Some things are like in "C" (comments, directives). Harbour is
powerful wrapper from xBase to "C". Very interesting project in special for
all the programmers from the Clipper and other xBase dialects that have an
opportunity to make real 32 / 64 bit applications with the flexibility and
easiness of xBase syntax.
Example of some functions:
AADD( <aArray>, <xValue> ) --> xValue
ABS( <nExpression> ) –> nPositive
ACHOICE( [<nTop>] , [<nLeft>] , [<nBottom>] , [<nRight>] , <acItems> ,
[<aSelectable>], [<cUserFunc>] , [<nFirstItem>] , [<nFirstRow>] ) -->
nSelectedItem
ACLONE( <aArray> ) –> aClone
#include 'cFile'
#declare cVar xValue
etc...
More examples online (CA-Clipper 5.3):
http://www.itlnet.net/programming/program/reference/c53g01c/menu.html
Harbour for those who doesn’t know what is:
http://en.wikipedia.org/wiki/Harbour_(software)
Maybe it’s easier to let you know it is an way better extension of
CA-Clipper (also known as DBase, Flagship, xBase, xHarbour). It is a
intuitive and powerful language.
Thanks for any help.
Regards,
Mario Wan Stadnik
Harbour programmer
Am 24.10.2013 05:39, schrieb Lex Trotman:
>
>
> PS On the recycling of doc structures and doc->is_valid, this does
> have the advantage (for a structure where miscellaneous pointers to
> the structure are going to exist in Geany and plugins) that doc
> pointers will always point to a geanydocument struct. So the is_valid
> test is always right. If the memory was returned and re-cycled into
> some other struct, the old doc pointers could point to anything, and
> could just as easily appear a valid document. So its safer than the
> alternative, but the requirement to check is_valid really does need
> more visibility since its an unusual idiom.
The recycling & is_valid thing is completely bogus. It is wastes memory
unnecessarily.
The is_valid thing is giving false security. Because a doc becomes valid
again after it was recycled you cannot be sure that the document is
still the same. Yet DOC_VALID() gives a false positive here if code
missed the document-swap behind the scenes. So basically code that cares
about GeanyDocument cannot rely on DOC_VALID() anyway.
The _only_ way to make sure things are alright is to cleanup
per-document stuff in the "document-close" signal handler. If you don't
connect to this signal your per-document code is broken, regardless of
doc->is_valid. Even worse, this brokenness is hidden by valid doc
pointers, whereas it would otherwise crash and suggest debugging the
problem properly. The right way is to NULL'ify any cached document
pointer in the signal-handler which makes recycling pointers unnecessary.
Also, recycling the pointers is only possible because the document array
never shrinks. So if you had opened a large number of documents and
close many of them you waste a lot of memory.
I vote for removing this idiom and transition the documents array to a
GList which gives other nice advantages.
Best regards.
Hi all,
On 10/20/13 21:01, RPG wrote:
> * add removing pairing brace by Shift+BackSpace
> * do not add semicolon in #define-s
> * add semicolon after class and struct
> * now works with GTK3+ (thanks Matthew Brush for patch http://pastebin.geany.org/r2VKS/)
> * added scrollbar for settings
> * improve semicolon completion
> * added help
> * added Tab jump to enclosed char (thanks Thomas Martitz: https://github.com/kugel-/geany-plugins/commit/7f19c3035abf6f8a7fa66c7b4c1e…)
now that we have a quite feature rich auto-close plugin (I didn't
test/use it but it already looks more mature than what we have in Geany
core), I wonder whether we could drop the now somewhat redundant and
always buggy code in Geany core which provides the same feature.
Any opinions?
Pavel: I guess the auto-close plugin is at least as production ready as
the current buggy code in Geany and so can be used as replacement?
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
