So, I'm always having multiple dozens of files open, some of which
define even more symbols.
At that point I began to really miss the search you can do in the file
open/save dialog (while typing search, the gtk docs say interactive or
typeahead search).
I looked at it and got it sort of working (see
http://www.alice-dsl.net/simonemartitz/geany.png), however I ran into
some problems.
a) switching focus to the editor widget. When using the keyboard to do
the search, the first match will be selected. As of now, selecting
something in the list automagically switches the focus to the editor.
That is of course unwanted while you're searching as it will stop and
break the search basically upon entering the first character. In a work
around, I disabled this switching if the selection happened by using the
keyboard. This works well for the symbol list, but not at all for the
open file list (which still changes the focus).
b) opening files doesn't bring it in front anymore. I removed the
"changed" signal for the open file list as it's incompatible with
searching. but that broke opening files as the mechanism to bring the
open file up relies on the sidebar here. For this, I thought the
"bringing the new doc up" code could be moved to the opening document
code (document.c), and the sidebar handler just does a call
document_open_file(). Would that work?
So, I basically want to discuss about a) if this feature is wanted and
b) about the two problems that showed up.
I really love this feature already.
Attached is my diff.
Best regards.
On Thu, 27 Aug 2009 01:58:28 +1000, Andrew wrote:
Hey,
this is a somehwat different topic, so I broke up the thread.
>would it be possible to have either a different strip command or some
>switch somewhere so that strip trailing whitespace results in this
>(using . for spaces/tabs):
>
> for i in (@blah){
> ...print "$i\n";
> ...
> ...print "BLAH!\n";
> }
>
> Instead of this:
>
> for i in (@blah){
> ...print "$i\n";
>
> ...print "BLAH!\n";
> }
>
>Note that in the first the spaces/tabs are left to end at the current
>indent level, I suspect that there is a large amount of extra code to
>make this work as the strip will have to get clever and understand
>about a lot more things than it currently does.
I see what you mean, I just wonder why?
:)
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hi,
After some ongoing discussion as well as a little stagnation of
development of geanyVC we decided to move development of the plugin
complete to geany-plugins combined release. This means for users of the
geany-plugins tree they will also use the latest version as the
trunk/geanyvc path will get deprecated and removed from subversion
soon.
Cheers,
Frank
--
http://frank.uvena.de/en/
Hi all.
Everybody knows that Geany has menu item "Document > Strip trailing
spaces" and option to do it automatically when a document is saved. My
proposal is another command, something like "Strip trailing blank
lines", to remove blank lines in the end of file (as they are absolutely
useless there).
I wrote new `editor_strip_trailing_newlines' function (see the attached
patch). Currently I call it directly from `document_save_file' if
`strip_trailing_spaces' setting is set. Of course, it's not how it
should be. Maybe separate menu item and option should be added, like for
trailing spaces. Alternative way is to combine those, i.e., rename
"Strip trailing spaces" to "Remove excessive whitespace" :-) These all
are usability issues, with which I don't like to deal. If any of the
developers has an opinion upon those, I'll consider it and update the patch.
P.S. My code leaves one trailing newline if `final_new_line' setting is
set. Otherwise, it removes all trailing newlines. I believe it is right.
Hi All,
The configurable build system has been merged into the latest trunk (>r4120).
This is a significant change which provides considerable flexibility
for configuring the operation of the build menu. Please read the
manual for the new capabilities ;-) including hidden settings.
To support this extra functionality extra fields have been added to
the geany.conf, project and filetype files and some older fields are
no longer used. Old format information is still read so that the
configuration files do not need to be updated. Older versions of
Geany should ignore the new fields and the new Geany does not write
old fields so their interaction should be minimal. I have been using
both versions for some time without problems.
The semantics of the new system is slightly different to the old one
so a mapping had to be chosen between old configuration information
and the new system. The mapping chosen is intended to make the
semantics of old format configuration files remain the same. The
mapping is not documented and should not be relied on as it may be
changed without notice to ensure that it meets that intention. Please
let us know of any difficulties as this is a complex area and it has
been tricky to get the interactions right.
Let us know of any other problems, or good things too of course :-)
Enjoy!!
Cheers
Lex
This seems to be due to G_GNUC_WARN_UNUSED_RESULT not being available
until GTK 2.10 at line 330 in keybindings.c
Either remove or #ifndef #define it to nothing
Cheers
Lex
2009/8/27 nightly.geany.org <eht16(a)users.sourceforge.net>:
> Geany GTK 2.8 build test failed at: waf build
>
> See http://nightly.geany.org/misc/build_gtk28_stderr.log for details.
>
> Last error message:
> ../../gtk28_test/src/build.c:2359: warning: excess elements in scalar initializer
> ../../gtk28_test/src/build.c:2359: warning: (near initialization for 'default_cmds')
> ../../gtk28_test/src/build.c:2363: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
> ../../gtk28_test/src/build.c:2446: error: old-style parameter declarations in prototyped function definition
> ../../gtk28_test/src/build.c:2444: error: expected '{' at end of input
> Build failed
> -> task failed (err #1):
> {task: cc build.c -> build_3.o}
>
>
> http://nightly.geany.org/
> _______________________________________________
> Geany-commits mailing list
> Geany-commits(a)uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-commits
>
On Sun, 30 Aug 2009 03:56:02 +0000 (UTC), noreply(a)nightly.geany.org
wrote:
Lionel,
>Plugins GTK 2.8 build test failed at: waf build
>
>See http://nightly.geany.org/misc/build_gtk28_plugins_stderr.log for
>details.
>
>Last error message:
>../../gtk28_test_plugins/codenav/src/codenavigation.c:209: error:
>(Each undeclared identifier is reported only
>once ../../gtk28_test_plugins/codenav/src/codenavigation.c:209: error:
>for each function it appears
>in.) ../../gtk28_test_plugins/codenav/src/codenavigation.c:251:
>warning: comparison between signed and
>unsigned ../../gtk28_test_plugins/codenav/src/codenavigation.c:260:
>warning: implicit declaration of function
>'g_strcmp0' ../../gtk28_test_plugins/codenav/src/codenavigation.c:311:
>warning: ISO C90 forbids mixed declarations and code Build failed
maybe you want to fix the error.
g_strcmp0() is only available in newer GLib versions but not with GLib
2.8 which we try to stay compatible with.
The most easiest fix is to use Geany's utils_str_equal() which does
also NULL-safe string comparison. But note it returns TRUE or FALSE,
not the difference between the strings.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hi All,
A question for the Geany translation/intltool expert.
I have been creating a Latex filetype file for the build-system branch which
contains labels for the menu items which need translation, "View PDF File"
and "View DVI File" for example.
The filetype is read in a locale sensitive manner and should load any
translations that are in the file, and my reading of the intltool
documentation leads me to believe that it should be able to extract marked
entries from config files like filetype.latex and include them in the
translation process alongside the source code strings and then merge the
translations back into the config file.
What I can't work out from the documentation is how do I tell intltool to do
it. I read it as it will include desktop.ini and other known files but it
doesn't tell how to include other files. X-S
Can anyone help please.
Cheers
Lex
I'm afraid I'm not used to mailing-lists, especially when using the digest version. I've posted my response without the subject, so I copy it again here.
I'm sending also the patch, this time it's the full version with the tagmanager/txt2tags.c file correctly included.
>I'm just wondering whether it isn't possible to extend the Markdown
>parser to parse txt2tags files as well.
it's problably possible because the txt2tags tags don't interfere with the markdown for this part. But...
>This way we wouldn't need to
>add yet another filetype in Geany.
yet the extension for txt2tags files is different. And in case I or someone manage to write the scintilla lexer, the rest of the txt2tags syntax would interfere with the markdown one.
>Your patch doesn't list any changes to Scintilla code,
I didn't include it, maybe I could have done it (without the scintilla lexer)? I'm still not satisfied with my scintilla lexer, because I managed only to highlight the tags and not the text. I'll propose it in a later revision.
Besides, the first time I inserted my changes, I did it on the released version 0.18, so I had to do it again with the svn version later.
