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
Hi,
Up till now we've tried to stay compatible with ANSI C89 because of
GTK+-stack doing so (unless I missed the real reason?).
I propose we update to allowing C99 for the following reasons:
- restricted character set support in <iso646.h> (originally specifed in
AMD1)
- wide-character library support in <wchar.h> and <wctype.h> (originally
specifed in AMD1)
- restricted pointers
- variable-length arrays
- fexible array members
- complex (and imaginary) support in <complex.h>
- type-generic math macros in <tgmath.h>
- the long long int type and library functions
- increased translation limits
- remove implicit int
- the vscanf family of functions
- reliable integer division
- universal character names
- extended identifers
- binary foating-point literals and printf/scanf conversion specifers
- compound literals
- designated initializers
- // comments
- extended integer types in <inttypes.h> and <stdint.h>
- remove implicit function declaration
- preprocessor arithmetic done in intmax_t/uintmax_t
- mixed declarations and code
- integer constant type rules
- integer promotion rules
- vararg macros
- additional math library functions in <math.h>
- foating-point environment access in <fenv.h>
- IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
- trailing comma allowed in enum declaration
- %lf conversion specifer allowed in printf
- inline functions
- the snprintf family of functions
- boolean type in <stdbool.h>
- idempotent type qualifers
- empty macro arguments
- new struct type compatibility rules (tag compatibility)
- _Prama preprocessing operator
- standard pragmas
- __func__ predefned identifer
- VA_COPY macro
- additional strftime conversion specifers
- LIA compatibility annex
- deprecate ungetc at the beginning of a binary file
- remove deprecation of aliased array parameters
(Source: list is 2nd hand from
http://www.open-std.org/JTC1/sc22/wg14/www/docs/n869/)
And that's just improvements since 1999 (way back when I was in high
school), not to mention more recent changes in the latest C11 standard.
I think for us the most likely consequences are:
- Coding in the new millennium style :)
- Microsoft Visual C++ compiler is not C99 conformant and plans not to
ever be AFAIK (of little consequence since we don't compile with MSVC).
- Allowed to use // style comments
- Allowed to declare loop counter-style variable inside the for loop.
- Use standard C instead of G*-portability wrappers in various place
(bool, fixed-width ints, etc.).
This is just sort of random, but I feel that some our code could be
better if we depended less on G*-stack and more on (>10 year old) ISO
standards.
P.S. Sorry for the bikeshed bait.
Cheers,
Matthew Brush
From the C99 discussion:
lex:
>>> Unless we follow the example of gcc itself and upgrade to C++ :)
me:
>> Not sure that's a good idea for Geany now, although I'm glad that gcc
>> did it. They use a restricted subset IIRC. I miss templates and RAII in
>> C though.
I now think gradually using a (quite heavily restricted) subset of C++98
for *some* source files might be better than moving to C99 (more on that
below). I still support C99 over just C90 though. (I don't do a lot of
Geany coding now, but I plan to do some from time to time, so obviously
this is just my opinion and less important than more active devs).
Reasons:
* No build problems for Long Term Support distros that don't support C99
(but clearly do compile scintilla's C++98).
* RAII - this is a pretty essential feature for safe resource
management. It's a stupid acronym though, it's basically automatic
scoped destruction:
http://en.wikipedia.org/wiki/Resource_Acquisition_is_Initialization
* References can be useful in making code more readable vs pointers.
* Developer enjoyment, productivity & gaining more experience with C++.
(This might be an incentive for e.g. me to spend more time working on
Geany). This has to be offset against those that might need to learn
e.g. RAII.
* Possibly we might use some STL containers internally.
* Possibly we could use a GObject wrapper for safe reference counting. I
don't want to add any dependencies on C++ libraries though.
* Possibly we could have some template function utilities instead of
unsafe macros. Although I think most header files should be kept C90
compatible.
matt:
> +1. While I'm also not sure it's a good idea in Geany and certainly
> won't be pressing for it anytime soon, 90% of C++'s crumminess is due to
> backwards compatibility with C, so I think it should be (theoretically,
> not socially) possible to gradually transition from one to the other in
> a project like Geany without too much pain.
colomban:
> I doubt it, C++ is sufficiently different from a C program not to be
> compilable by a C++ compiler in many cases -- even if it is just for
> some implicit casts C++ requires to be explicit (IIRC), and there are
> plenty. Or maybe it depends what "too much pain" means:)
>
> Also, I doubt it's any kind of sensible either, because good C++ use is
> sufficiently different from C to require large rewrite. In this case,
> better rewrite everything and don't keep the clumsy code
I disagree it *requires* a large rewrite. You can make *good* use of
some C++ features without having *idiomatic* use of C++. (E.g. dmd, the
reference D compiler is not written in idiomatic C++ - it doesn't use
the STL really, but it's still good code).
I think it would be quite manageable. If we did this, I suggest just
converting one source file at a time, and only files that can benefit
from RAII and/or the more powerful type system.
We would also need to disable some C++ features. I hoped we could do
that with g++ flags, but I've only found this so far:
-fno-rtti (disable runtime info for object inheritance)
There ought to be a way to disable mixed code and declarations, but
maybe not.
I don't know if this can be enforced by g++, but I suggest we disallow
these keywords:
class
dynamic_cast
friend
mutable
operator
throw
virtual
That could be enforced with a 'make check' build target.
Thoughts?
Regards,
Nick
Hi,
There was a bug report about message window sizing issues that seems to
be caused by the Scope plugin:
https://sourceforge.net/p/geany/bugs/988/
I'm not sure how to "move" the ticket to the Geany-Plugins bug tracker
so I'm just sending it here.
If I recall correctly from writing MultiTerm, there's a bug in VTE
library where it doesn't size itself properly (maybe something related
to using width in characters instead of pixels) and it goes super-huge
by default.
For MultiTerm, I remember I had to perform an explicit
gtk_widget_set_size_request(wid, N, N) where N was any arbitrary size
smaller than expected (I think I chose 100 or 10 or something). Also,
I'm not positive, but the VTE widget might also need to be placed in a
GtkFrame or similar, and then into an GtkHBox with a GtkVScrollbar
(using the VTE's adjustment) next to the VTE into the GtkHBox. I
probably just copied how Geany did it, I don't remember for sure, but it
works anyway. I could be completely wrong on the cause of the bug, I
just wanted to mention since I remember fighting VTE for same issue.
Cheers,
Matthew Brush
Hi all, long time ago i was written snippets file, so i want to send you
updated version + html/css/js snippets added from Tomasz Karbownicki.
Also i want to propose improvements for parsing those snippets but i
will write for this later.
Hi,
I just want to throw this out there since I already made it:
http://pastebin.geany.org/7YHWE/
It's the diff of a branch which replaces every single redundant G* type
with its standard C counterpart. I have a branch with commits for each
type, starting from the only one that changed (WRT to recent C99
discussions), but I just pasted here a combination patch of removing all
redundantly-named, non-standard C types.
Of note is:
- I left gboolean where it would break a function signature with respect
to GCC warnings.
- I left all guchar, gushort, guint, gulong, etc types, because, lets be
honest, it's just nicer to type.
- gpointer (and gconstpointer) was special because it masked the pointer
* behind its typedef and so broke lines with multiple gpointer
declarations on the same line (easily fixable since there's no such
thing as void type in C).
- I think patch includes changes to stdint types (ex. gint16, guint32)
but I think we shouldn't change these as GLib assures them and the C99
standard does not in theory (and is not many in use).
I don't mean to apply this patch directly, just to spur discussion about
whether Geany should be using standard C types or pointlessly typedeff'd
G* types where there is an existing and cross-platform standard type.
The one big point I can see against is; "We already do like that", so
there's no point in repeating it, it's totally valid and avoids
(potentially, although I'm pretty sure not) breaking in obscure ways
some mysterious code, but since I made the patch anyways, I'd thought
I'd post it for comments. If you see some fundamental issue, of course
feel free to point out.
I mostly want to solicit feedback on this topic in general rather than
bikeshed my patch specifically as pasted.
P.S. I'll not proceed further on this without more input from Geany
developers and community.
Cheers,
Matthew Brush