Last year I brought up the topic of Geany having an incremental search
backward feature. Nick mentioned
(http://lists.uvena.de/pipermail/geany/2007-September/001665.html)
that it might eventually get implemented.
Since then, when using Geany, I've tried using Ctrl-F to move focus to
the search bar (incremental search forward), Shift-Ctrl-g to go
backward, and Ctrl-E to bring focus back to the editor. The problem
though, is that it still feels quite clumsy to me. So, I've got 2
ideas for improvement:
1. Since Geany is a GUI editor/IDE, and it's got a toolbar, how about
having a (possibly optionally visible) checkbox widget associated with
the Search field, such that when checked, does the search in the
opposite direction? That would seem to be an easy way to provide
incremental search backward. If you think it looks like an ugly hack,
you could always leave the checkbox's visibility off, by default, and
then provide a sub-checkbox for "Prefs --> Toolbar tab --> Items
section --> Show Search field" to make it visible. As long as users
could toggle the checkbox (while visible) by hitting an Alt key combo
(like other GUI parts), it would speed up editing a lot, IMO.
2. When I do an incremental search for something that's already
visible on the page, and the cursor gets there, I don't think Geany
should automatically scroll to center the view. The reason is, when
you're using incremental search to move around on the page, you've
usually already got the location you're headed to in the corner of
your eye. If the view scrolls while you're on the way there, it's
jarring. Also, I may just be going there to set a bookmark, and then
heading back to where I was. Having the screen flop all over the place
while just moving around the visible view is disorienting. :)
2.A. Incidentally, I think that using Ctrl-. and Ctrl-, (moving
between bookmarks) should behave the same way (as described above)
when the target bookmark is already visible on the screen.
Thanks,
---John
Hi,
Release early, release often. So I'm doing ;)
Last weeks I started to write a little plugin that helps me to create
newly LaTeX-documents and manage them after that. Right now, it's just a
little wizard to help to create new documents and don't type things like
\documentclass [baa]{foo} so often. Well, nothing more like a nice
gimmick IMHO. But since I was inspired by Emacs/aucTeX in combination
with my personal experience, I've got a big number of ideas.
I've uploaded the source to my Geany folder at
http://frank.uvena.de/geany/geanylatex-0.1.tar.gz2
Maybe it's useful for somebody.
The plugin should compile with Geany 0.13svn r 2177 and newer.
Compiling at any Windows platform is _completely_ untested and expected
to doesn't work at all ;)
Regards,
Frank
Hello World, hello Enrico,
Geany 0.13svn >= 2188 (Latest windows build), Windows XP Professional
I have a file in the editor, mode is Win (CRLF), encoding UTF-8 (no
BOM). If I lookt at it in a hex editor, it is correctly saved with line
endings 0x0D, 0x0A.
If I mark (a part or all) the file, copy it into the clipboard and paste
it into geany, it is still correct. If I paste it into another editor,
the line endings look like 0x0D, 0x0D, 0x0A, e.g. 0x0D appears twice
(adding an extra line in the other editor and sometimes even compiler
errors if it is source code)...
Best regards
Andreas
--
("`-''-/").___..--''"`-._
`o_ o ) `-. ( ).`-.__.`)
(_Y_.)' ._ ) `._ `. ``-..-'
_..`--'_..-_/ /--'_.' .'
(il).-'' (li).' ((!.-'
Andreas Tscharner andy(a)vis.ethz.ch ICQ-No. 14356454
The latest version of Scintilla has many more filetypes supported than
the version currently used by Geany. It's not that hard to port Geany
over to using Scintilla 1.75 (I was able to do it this afternoon in
about half-an-hour after poking around). This doesn't provide the
filetype information used by Geany (e.g. colors, keyword list, etc as
defined in filetype.lang) to do the syntax highlighting, but it does
put the lexer framework in place, and such information can easily be
obtained, maybe from SciTE or the language specification or any other
text editor. If I'm right about this, it shouldn't be too hard to add
a lot of new languages at once to Geany. Then again, I'm new to Geany's
internals, so please correct me if I'm wrong.
Scintilla 1.75 also offers several other improvements. I myself am
partial to the fact that it can render indentation guides over blank
lines. Does it seem like a good idea to move to this newer version of
Scintilla after the 0.13 release?
--
Taylor Venable http://real.metasyntax.net:2357/
foldr = lambda f, i, l: (len(l) == 1 and [f(l[0], i)] or
[f(l[0], foldr(f, i, l[1:]))])[0]
Hi,
just for your interest:
on Friday, 18.01.2008 about 14:00 UTC uvena.de(the server where this
list is hosted) will be down for a system upgrade and some maintenance
work.
I think it will be up again on Saturday with all services(mainly this
mailing list and the webserver).
You should be able to send mails to this list anyway but they won't be
delayed, so don't be surprised ;-).
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.key
Hi all plugin authors,
>From http://lists.uvena.de/geany/2008-January/002462.html:
On Thu, 3 Jan 2008 12:31:06 -0600
"Jeff Pohlmeyer" <yetanothergeek at gmail.com> wrote:
> IMO, the names from pluginmacros.h should be all uppercase.
> I know this will break all of the existing plugins, but I think it is
> much better in the long run, it makes the code more readable,
> at least for me.
I've committed alternative macros in pluginmacros.h that use a 'p_'
prefix, instead of all uppercase. Enrico & I think this is more
readable and consistent. The macro names after the prefix are the same
as the first word in the core function name - e.g.:
document_open_file() -> p_document->open_file()
The variable name macros are unaffected.
The old macros will still be available in pluginmacros.h until after the
next release, so there is no rush to update external plugins, but it is
advisable to do so when you can.
Please let me know if there are any problems with this.
Thanks,
Nick
Hi ...
Am I the only person that have problems loading files on startup from a
project ?
If I startup Geany, and then load a project it get all the session files
from this project, as it is supposed to. But if I quit Geany, and start
it again Geany load the project as I expected, but no project files
(from project session) are open anymore :-(
This use to work ...
My config say :
"Load files from the last session" checked
"Use project-based session files" checked
Any idea as to how ?
/BL
I think that a good way to access GeanyLua plug-ins via the keyboard
would be to have one main GeanyLua key binding that you could hit to
get GeanyLua to listen for the *next* key and then run the appropriate
plug-in for you from there. That is, use a "prefix key". For example,
you could use the letter 'r' to reach `reverse.lua`, and get to it by
hitting a prefix key combo like, say, Ctrl-!. The whole command would
then be: Ctrl-! r (hit Ctrl-!, release, then tap 'r').
The main idea is, I'd rather not play games trying to find unused key
combos for every Lua plug-in script that I plan on using regularly.
And I want to be able to access these regularly-used plug-ins very
quickly via the keyboard.
Can I get the main GeanyLua plug-in to respond to one main key combo
like that (ex. Ctrl-!)? And, if so, any recommendations on how I could
then make it hand-off to the selected Lua script after I hit the next
key?
Thanks,
---John
Another new version of GeanyLua, this release adds:
* Support for dynamic loading of third-party Lua modules.
* The ability to arrange menu items in arbitrary order.
* A new "keygrab" function for accessing multiple script
actions from a single keybinding.
Along with a few bug fixes (and maybe even a few new bugs!)
http://yetanothergeek.justfree.com/geanylua/
- Jeff
When I search a file using grep's -w switch, or using the
"whole word" search option in other editors, if the search
term begins or ends with a non-word character, the editors
I tested will still find the match, but Geany does not.
For instance, Geany does not treat "return;" (sans quotes)
in the same way as (most?) other editors.[1]
Is this a bug, or intended behavior?
- Jeff
[1] NEdit,SciTE,Metapad,Delphi,CRedit,ConTEXT,gnumeric