Hi all
Doing an unsuccessful search using the search dialog currently results
in a dialog popping up asking
"searchstring" was not found.
Wrap search and find again?
Clicking on the Find button results in a message in the status bar
saying "searchstring" not found.
Would it be possible to change the search field background to red in
this case, to give additional visual feedback that the search was
fruitless? In the same way that the search field in the toolbar does it.
Thanks!
Conrad
--
-----------------------------------------------------------------------------
Conrad D. Steenberg Ph.D. conrad.steenberg(a)caltech.edu
Scientific Software Engineer http://clarens.caltech.edu
Pierce Bio-Engineering Lab Mail Code 114-96
California Institute of Technology Pasadena, CA, 91125
Hi all,
I noticed today a new regression in LexHTML; Using comments in XML
clobbers the fold structure.
The comment 'opening' <!-- does not increase the fold level, but the
'closing' --> decreases the fold level. A simple fix is commenting out
the "if (foldHTMLPreprocessor)" on line 858, LexHTML.cxx
But be forewarned: I don't know exactly when this regressed or what
caused it.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Happy New Year to you guys ! Best wish to you and Geany :)
In reply to this discussion on the geany list:
http://lists.uvena.de/pipermail/geany/2008-December/003878.html
I did my own version of the patch (in attachment). It still have
following some flaws:
- - when you insert an autoclosed char and immediatly delete it, the
non-autoclose code kicks in anyway (I'm not sure how/where to deal
with the delete keys)
- - when inserting a quote (double or not), coming back before it and
inserting another one, the non-autoclose code kicks in anyway. Should
we test the next-char before non-autoclosing ?
- - the test for matching bracket seems a bit too greedy as autoclose
often doesn't kicks in because of a closing bracket few lines after.
Hadn't notice any lag with this code, however I wasn't notice lag with
Enrico's patch neither...so someone with an older computer should
probably check that.
Thanks for your next answer and review :)
- --
Guillaume (ioguix) de Rorthais
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkllg9QACgkQxWGfaAgowiIFBgCfa4Wrn7gOUrwUarMMAbgxI+Yy
hVwAn1FWzNd8eQeXL0oApICzvTdKGRF6
=WD/5
-----END PGP SIGNATURE-----
The attached patch moves the stuff in the tools->VC menu into
Current File
Current Directory
Current Basedirectory
This makes each menu cleaner.
Additionally, it allows adding new functionality without messing up the
current single menu even more,
such as revert for directory and basedirectory, or commit of single
files etc in the future.
Code-wise it does a little cleanup. The creation of each submenu is in a
seperate function, as well as the initialization of the hotkeys.
--
Kind regards
--------
Hi All,
Sorry for the long silence, I had a family health problem which had me away
from home and with only access to email, no upload or download. Now that I
am back I will be able to get on with the build-system updates, once I
remember where I was up to ;-). Since I stuffed up copying the source to my
laptop nothing has happened in the interim.
As I remember we were trying to come to a conclusion about commands for
header files for C and C++ which are currently explicitly prevented from
performing any compile or build.
The C++ work I have done in the meantime has re-inforced my desire to be
able to at least compile C++ headers by themselves to get out the
syntax typos because they tend to cause a lot of "flow on" errors in the
.cpp file and C++ generates such enormous error messages (see
http://www.parashift.com/c++-faq-lite/templates.html#faq-35.17 for an
example). Also I have noticed that Geany 0.15 is very slow when there are
lots of errors, maybe the regex parse is a bit slow, anyway that just makes
it more important to compile the .hpp file first.
The question seems to be how we handle having different commands for the
header files (different to the .cpp files that is) without creating new
filetypes for them.
My last proposal was for a "variant" of the filetype which allowed different
commands. The variant was identified by a subset of the filetypes
extensions. This is a slightly general solution configurable in the
filetypes or preferences files, or another option is something hard coded
specifically for header files, not my favourite :(.
Any other suggestions?
Cheers
Lex
Hi guys,
As you might have seen, last week I created a branch for redesigning of
GeanyVC's menu structure. For creating this, I branched the geanyvc
subfolder from trunk. This was ok IMHO for this topic but made me
thinking about how a branch could look like in future. I had a couple
of ideas and like to start some kind of poll about this topic ;)
1.) Always branch complete trunk with all plugins so e.g. waf is still
working. This would make some things more easier e.g. handling with git
svn, but would force somebody who did a svn co on the branch to waste
space on the hard drive
2.) Creating a folder structure similar to the tags section and then
putting the branch into the right folder:
|-- branches
| |-- backupcopy
| |-- filetree
| |-- geany-mini-script
| |-- geanydbg
| |-- geanydebug
| |-- geanydoc
| |-- geanylatex
| |-- geanyprj
| |-- geanysendmail
| |-- geanyvc
| |-- instantsave
| `-- spellcheck
|-- tags
| |-- backupcopy
| |-- filetree
| |-- geany-mini-script
| |-- geanydbg
| |-- geanydebug
| |-- geanydoc
| |-- geanylatex
| |-- geanyprj
| |-- geanysendmail
| |-- geanyvc
| |-- instantsave
| `-- spellcheck
`-- trunk
3.) Branching as needed analog to GeanyVC_menu_redesign, were only
code is included, that is really needed for the branch.
I'd prefer suggestion 1, but I really like to know your opinion. ;)
Cheers,
Frank
--
http://frank.uvena.de/en/
Hey,
I just thought about how external plugins could/should install their
documentation files[1], if any.
The usual location would be $prefix/share/doc/pluginname but I think
with multiple plugins installed, this could clutter up the doc
directory a little bit. At least when the plugins are installed in a
global default prefix like /usr. Then users end up with something like
/usr/share/doc/externdbg
/usr/share/doc/geanylatex
/usr/share/doc/geanyvc
/usr/share/doc/spellcheck
Especially for plugins which are not prefixed by 'geany' (which is by
no means necessary IMO) this could be ugly, especially when plugins are
packaged by distributions.
(currently the geanylua plugin installs documentation in
$prefix/share/doc/geany/ which is even worse, plugins should not
install anything into Geany's doc or datadir)
So, my suggestion would be to make a recommendation for plugin authors
to install documentation files into
$prefix/share/doc/geany-plugins/${pluginname}
example:
/usr/share/doc/geany-plugins/externdbg
/usr/share/doc/geany-plugins/geanylatex
/usr/share/doc/geany-plugins/geanyvc
/usr/share/doc/geany-plugins/spellcheck
This way, the global doc dir won't be cluttered so much and plugin
documentation files will be installed together in a common directory.
What do you think?
[1] Documentation files mean not only some kind of user documentation
but also the usual README, AUTHORS, COPYING, ... files.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
This patch changes file loading behaivor, as to changing the working dir
automatically to the dir of the loaded file, instead of something (to
me) random (current behavior).
Some apps depend on the working dir being the dir where the executable
is. And those who don't don't care about working dir at all, so this is
a good change.
--
---------------
Best regards,
Thomas Martitz
---------------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Comment By: Enrico Tröger (eht16)
> Completely unrelated to Geany.
> HTTP usually doesn't support write operations, right? So how do you want
> to write files to it or even mount it?
Opening a file through HTTP works with g_file_new_for_uri(), but yes,
write operations will fail.
> Instead, use dav:// assuming your server supports it. Then you can mount
> it as usual and after having mounted it, you can open and edit files on
> it.
I dunno how to do it "as usual" since I use Nautilus 2.22 for now that
AFAIK doesn't really support GIO, and I dunno how to mount a location
with GVFS without Nautilus… But yes, I understand the meaning :)
> Yes, that's the way. And when we save the file in Geany, we set an ignore
> flag to ignore the next 'file has changed' signal. And there probably begin
> the problems.
> Also, this works only if the file was actually only changed which happens
> when saving with Geany. When you save the file with Gedit, it (probably)
> won't work because Gedit first saves the file into a temp file, then move
> it to the real file. So, the real file is never 'changed' but 'created'.
> And the 'created' notification is currently ignored at all.
Hum… I've just tried with Gedit modifying an opened file in Geany, and
the tab becomes orange, but when I start to modify it again, Geany
tells me that the file was not found on the disk, asking me whether I
want to save it… and if I say yes, then ask me if I want to overwrite
the existing file. Well, not perfect (but I personally don't mind
about that since this feature helps me mostly for files modified by a
script).
> This doesn't really explain your problems, I think. But is one of the
> things I meant when saying 'not yet 100% functional'. Let me give it
> another try tomorrow and in the meantime just revert to before r3484 :).
OK, I see. And yes, just take the time you need and let us (me?) know
when we can test your new efforts :)
>
>
> Too bad, I hoped there was something real exotic which would explain the
> behaviour :).
Hey no, sorry :D
> P.S.: quoting in the tracker is awful. Moving to the mailing list?
Yeah, great idea!
Just ask me if you need any other test or information.
Regards,
Colomban
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkl1BcIACgkQyqbACDEjVWhKpACg3Z8Z3cpGhLD6ZnrMYOpbFwTh
mD4AoIZvuldC/BPFpYraJmg+/o+GuRCe
=kOgp
-----END PGP SIGNATURE-----