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
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!
I saw this code in src/symbols.c at line 1917:
while (sci_get_style_at(sci, start) != fn_style
&& start < max_pos) start++;
If start >= max_pos then sci_get_style_at will be called (with out of
bounds value?) and then the loop will bail out.
I suggest that the condition is reordered as:
while (start < max_pos
&& sci_get_style_at(sci, start) != fn_style)
start++;
Then sci_get_style_at will only be called if start is less than max_pos.
It is just my humble suggestion.
Best regards,
Daniel
Hey all,
this topic has been brought up already a couple of times, for example on
[1].
What do you think about dropping Waf support in Geany and in the
Geany-Plugins project?
While I was defending Waf in Geany, I somewhat changed my mind. Not
because I don't like it anymore, but I increasingly see the efforts in
maintaining two (to be exactly three for Geany) build systems is too
much. Since the make/MSYS build system support seems to get better and
better due to Nick's and Dimitar's work on it, I thought about dropping
the Waf support. It seems nobody knows it well enough and probably
except for a few users nobody is using it.
(And obviously I don't do so much anymore and also lost a bit interest
in maintaining forever.)
The other thing is that Waf causes often problems for distro packages,
especially for the Debian folks [2].
So, I'd go the easy way in this case and just remove Waf. Then we only
need to maintain the autotools based build system for non-Windows
systems and the make based for Windows.
For Geany-Plugins, we would need to get something working on Windows but
maybe we could re-use Geany's make based system for Windows here.
What do you guys think?
[1]
http://sourceforge.net/tracker/index.php?func=detail&aid=3460449&group_id=1…
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645190
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hi,
Now that 1.22 is out, how about removing the MSYS build dependency
under Win~1? I tried to compile Geany with the default MinGW make,
without any MSYS, and there were some easily fixable problems:
cd foo && $(MAKE) -f makefile.win32 && cd ..\..
does not work, probably requires some sh. But if we depend on GNU make
(which seems to be the case, since we're using ifdef/else/endif), it's
easier and shorter to:
$(MAKE) -C foo -f makefile.win32
Linking does not work, because the stock make supports \ only for
variables, not commands. But that's even easier to fix:
STLIBS
= ../scintilla/scintilla.a ../tagmanager/tagmanager.a ../tagmanager/mio/mio.a
$(TARGET): $(OBJS) $(RES) $(STLIBS)
$(CXX) $(OBJS) $(RES) -o $(TARGET) $(STLIBS) $(ALL_GTK_LIBS)
$(WIN_LIBS)
with the added benefit that static library names are not repeated
literally.
There is also some inconsistency: CP = copy, but "cp -r" and "cp" at
the end of makefile. The install target can be rewritten as several
-$(MD) and non-recursive $(CP) commands, and no MSYS will be required.
RFC. If we consider this worthy, I can make the required changes.
--
E-gards: Jimmy
hey! It's about the bug
http://sourceforge.net/tracker/?func=detail&aid=3587465&group_id=153444&ati…
i tried to debug it by changing the buttons to YES No buttons, I figured
out that the document.c is the file associated with this bug.
original code
static void monitor_reload_file(GeanyDocument *doc)
{
gchar *base_name = g_path_get_basename(doc->file_name);
gint ret;
ret = dialogs_show_prompt(NULL,
GTK_STOCK_CLOSE, GTK_RESPONSE_CLOSE,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
_("_Reload"), GTK_RESPONSE_ACCEPT,
_("Do you want to reload it?"),
_("The file '%s' on the disk is more recent than\nthe current buffer."),
base_name);
g_free(base_name);
if (ret == GTK_RESPONSE_ACCEPT)
document_reload_file(doc, doc->encoding);
else if (ret == GTK_RESPONSE_CLOSE)
document_close(doc);
}
Modified code
static void monitor_reload_file(GeanyDocument *doc)
{
gchar *base_name = g_path_get_basename(doc->file_name);
gint ret;
ret = dialogs_show_prompt(NULL,
GTK_STOCK_CLOSE, GTK_RESPONSE_CLOSE,
GTK_STOCK_NO, GTK_RESPONSE_NO,
GTK_STOCK_YES, GTK_RESPONSE_YES,
_("Do you want to reload it?"),
_("The file '%s' on the disk is more recent than\nthe current buffer."),
base_name);
g_free(base_name);
if (ret == GTK_RESPONSE_YES)
document_reload_file(doc, doc->encoding);
else if (ret == GTK_RESPONSE_CLOSE)
document_close(doc);
}
How to test this code locally
when I try
make install
I get this output
[amit@localhost geany-1.22]$ make install
Making install in tagmanager
make[1]: Entering directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager'
Making install in mio
make[2]: Entering directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager/mio'
make[3]: Entering directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager/mio'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager/mio'
make[2]: Leaving directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager/mio'
Making install in include
make[2]: Entering directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager/include'
make[3]: Entering directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager/include'
make[3]: Nothing to be done for `install-exec-am'.
/usr/bin/mkdir -p '/usr/local/include/geany/tagmanager'
/usr/bin/mkdir: cannot create directory `/usr/local/include/geany':
Permission denied
make[3]: *** [install-tagmanager_includeHEADERS] Error 1
make[3]: Leaving directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager/include'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager/include'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory
`/home/amit/Programming/Geany/geany-1.22/tagmanager'
make: *** [install-recursive] Error 1
Can anyone please help me with this so that I can test this, also how to
submit the code (ie if I get it right)
ps: attaching the modified document.c.
Thanks
Regards
Amit
I noticed if I do a search from the toolbar and press return, it finds
the word, but focus remains in the search bar.
Isn't there a way to have it automatically set the focus to the text and
then I can use keyboard shortcuts to go from the current instance to the
next/prev.
I think this would be more intuitive:
1. Keyboard shortcut to the search toolbar.
2. Type a word.
3. Press enter and get taken to the first word with the focus on it.
4. Use other shortcuts to go from next/previous
5. Use the keyboard shortcut again to return to the toolbar to change
the search term.
I did things this way all the time before. In geany, it looks like I
have to use another shortcut in between?
1. Keyboard shortcut to the search toolbar.
2. Type a word.
3. Press enter and get taken to the first word *but focus remains in the
toolbar*.
4. *Press a shortcut to get to the editor*
5. Use other shortcuts to go from next/previous
6. Use the keyboard shortcut again to return to the toolbar to change
the search term.
Even if people like the latter way, maybe it could be a checkbox option
in preferences?
What do you guys think?
Thanks,
Steve
Hello,
This is a submission of a patch to support Abaqus files (inp files).
A lexer file already existed so I included the support, together with a
filetypes.abaqus for the keywords and a TagManager parser for the three
main sections (Parts, Assembly and Steps).
This patch has been tested and confirmed working on the master branch now.
Regards,
Baptiste
Hi All,
Along with the previous response on the icon, the following was proposal
was also received from Clement of the Mint distro:
"Another thing I wanted to ask you about, and I'm glad you contacted us, is
about the configuration of Geany as a text editor for users (as opposed to
developers). Geany is brilliant and I personally use it as a developer to
do most of my work in Python, C, PHP and other languages. But it could also
be a great contender for a default text editor in Linux Mint in replacement
of gedit. We're not happy at all with gedit 3, in particular when it comes
to searching and replacing occurrences in a text file. We considered
replacing it with Geany, with an older GTK2 version of gedit or even
forking it to provide a new tool dedicated to text editing.
What is your opinion on this? If we used Geany for this, we would hide all
developer features (symbols, buttons, statusbars..etc) from it. Would you
rather like us shipping a version of geany which by default looks like a
simple text editor (and so devs would have to go in the preferences and
re-enable all the normal features) or fork geany into a new project
dedicated to text editing (i.e. basically a dumbed down version of geany
with features removed). With a fork of course we'd give credit to geany in
our communication and within the tool itself, we'd work with you on making
sure you're happy with the end-result and the editor would have a distinct
generic name ("text editor" for instance) so it would be possible for users
to have both this editor and geany installed side-by-side and to open
documents with either of them. Let me know your thoughts on this. We're not
sure what the best approach is, but whether it happens now or later, we're
pretty sure gedit 3 isn't what we want to use going forward."
To kick the ball off, here is my thoughts on the topic.
First thought is that there is plenty of upside to such cooperation in
terms of attracting more contributors to the developer version of Geany.
The flip side of that is of course that more bugs would be reported and
expected to be fixed. (Bug reports are good, its the *expectation* that
they will be quickly fixed that is the problem.) I would hope that Mint
would be able to contribute to that effort.
I am not sure how much effort it would take to make the Geany UI able to
hide the "developer" features, it will be some complication for sure, but
probably not a big one.
If Mint use a "friendly fork" approach it does reduce the impact this has
on the Geany project, but it will also reduce the possible bugfixes that
come back to Geany (since the fork is different patches may not apply).
If we provide the "plain editor" version as an option on Geany it adds to
the workload, though I would hope that Mint would contribute to that extra
effort.
I am personally undecided at the moment, noting that Mint will do what is
appropriate for their distro, and it is up to us to try to engage with them
ina way that provides the maximum benefit for both groups.
Cheers
Lex
Hello.
I'm just introducing myself and explaining why I chose to add myself to
the devel list today, as well as providing a patch.
I'm a software developer who, if you can believe it, uses gedit as my
primary IDE. (You may have seen me recently in the IRC channel.)
After struggling with the division between gedit 2, gedit 3, and pluma
(MATE), I decided to look elsewhere for a light-weight IDE.
My initial impressions of geany are:
1. It runs with about half the RAM of gedit2 on my box.
2. The code seems easier to get in to.
3. It seems to be heading the direction I like and has the look and feel
I want.
4. Looks like any feature I miss from gedit I could contribute myself or
write a plugin.
So here is my attempt to get involved:
I've attached a patch that adds /Backspace/ to the keyboard events for
the file browser so you can go up a directory quicker. It's something I
noticed gedit had and I hope others may find it more convenient than
previous Alt+Up key combination (which still is there, this is just in
addition).
Sorry if I'm doing anything out of step, and I hope I can contribute :-)
Thanks,
Steven Blatnick