Congratulations with the Geany 0.13 release, I've been following the
trunk for a while, and noticed the version bump the other day.
I use Geany a lot for Django based development as of lately, I love the
new project manager, how it loads the last open files I had open for
each project, as I re-open that project.
I also like the feature, where each project can have it's own build
command, I use this for my Django projects, set it to something python
manage.py runserver... etc
The thing I sometimes get however, is if I have already typed something
prior into the VT terminal prior, the execute button does not work, and
at the bottom of the Geany window it reads:
Could not execute the file in the VTE because it probably contains a
command
I then have to manually type the python manage.py runserver in the
terminal.
I was wondering, if it was possible to maybe add a new option in Geany,
a tickbox in the options, something like "Force break previous commands
in VTE on execute", so if you hit the execute button, and if this option
is enabled, it would send a ^C signal to the VTE, regardless of what's
running in it, and then always execute the program.
Would this be difficult/possible to implement?
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 all,
I am happy user and maybe future developer of geany, and I am using it
on my laptop that has a 7" 800x480 screen however it does not fit!!
Would a developer be so kind to change some things in the code like:
My available space to render windows are something like (800x480 - panel
sizes 2x40) = 800x400)
Change the minimal hard coded sizes of all windows, so main screen and
setting dialogues.
Kind regards,
Jelle
Hi,
I just noticed that website says: RPM for Slackware.
However, Slackware uses .tgz packages, so this may confuse users.
Anyway, thanks for Geany and keep up the good work.
Regards,
--
Milan Babuskov
http://www.flamerobin.org
Hello list,
Recent convert to Geany here! I love how it runs fast (*cough*Kate*cough),
doesn't have any desktop-environment dependencies (*cough*Bluefish*koff),
and uses a modern GUI toolkit (*cough*NEdit*hack). Please keep on trucking.
I would like to submit a patch (against SVN) to add two features that I've
found very useful:
1. Allow specifying the line number in a document on the command line using
traditional Unix "+NNN" syntax. This makes Geany compatible with tools
like Cscope, and countless others.
2. Allow specifying the line number---and optionally the column---in a
document on the command line using a ":NNN" or ":NNN:NN" suffix. This is
not so traditional, but it means that you can (for example)
cut-and-paste part of a typical GCC warning line...
foo/bar/baz.h:340:6: warning: "_MSC_VER" is not defined
...and very quickly have a usable command line:
$ geany foo/bar/baz.h:340:6:
(The trailing ":" is ignored. Yes, I know, you can invoke the compiler
via the IDE, which parses the warnings... I often work with
nightly-build log excerpts, however, so this is convenient for that.)
Implementation notes:
* GLib's option-parsing facilities can't handle "+" options. What I did was
pull those out before GLib gets to them, replacing each with a new
"--dummy" option that does nothing. This is better than handling the
option after the fact, because then you have to write your own logic to
remove the option from argv[]. (Or handle it as a special case when you
parse the non-option arguments.)
* cl_options needs to be initialized before we look at the "+" option, lest
we blow away the user's specified line number.
* get_line_and_column_from_filename() tries to be strict about the syntax
of the line/column-number suffix, to help avoid unfortunate cases like
$ touch ifconf.08:00:69:02:10:05
$ geany ifconf.08:00:69:02:10:05
At most, it allows a trailing ":", for cut-and-paste friendliness.
--Daniel
--
NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef?
EMAIL1 = skunk(a)iskunk.org ## don't smell bad--- (/o|o\) /
EMAIL2 = skunk(a)alum.mit.edu ## it's the people who < (^),>
WWW = http://www.******.org/ ## annoy them that do! / \
--
(****** = site not yet online)
Just noticed another minor display (or maybe doc) issue: if I set the
hidden pref show_editor_scrollbars=false, contrary to the docs, the
scrollbars never appear -- even when the document is longer than what
the view can display. I can still scroll down via the scroll wheel
though.
Interesting sidenote, Geany's horizontal scrollbar at the bottom is a
bit odd in the way that it lets you scroll way out to the right even
if you don't have any long lines. It tends to make me think I've got a
really long line somewhere in my doc. One way I've seen this feature
work in other editors is, the size of the scrollbar slider grippy
thingy at the bottom varies depending on the max line length *of only
the lines currently visible in the view*. More commonly though, the
size of the slider thingy just gets set based on the length of the
longest line in the whole doc, and that works very well.
---John
When searching in a document, it's nice how the window view gets
centered on the search term (when the search term is further down the
page, out of view from where you started).
However, when scrolling with the mouse, if one scrolls all the way to
the bottom, you end up with a mostly-blank window, with only the last
line showing at the top. It would probably be more useful if, when
scrolling all the way down, the view were left in the same way as if a
search had landed you at the last line of the doc (that is, with the
last line somewhere near the middle of the window). Or possibly with
the view centered, like what "Scroll to current line" does.
---John
I change my keybinding so that Ctrl-F gets me to the incremental
search field in the toolbar (I set Ctrl-Alt-F to get me the original
Find dialog, though typically don't ever use it), but the "Search -->
Find" menu item still says "Ctrl+F" after it. The keybindings are
listed correctly in "Help --> Keyboard Shortcuts" and in "Preferences
--> Keybindings", and searching works as it should.
---John
Hi there.
Today I've tried the new Geany release with my Windoze XP installation. I've removed the previous SVN build (the one from uvena.de) and installed the "complete installer" with GTK to get the printing support. Geany is up and running now.
After that, I've downloaded Geanylua 0.6.1 und installed it using the VBS script.
The "plugin manager" can see the plugin, and I'm able to active it. But now, if I try to call the settings button, I always get the error message "The Geanylua plugin failed to load.."! There is also no LUA script menu entry available.
I've tried several other location for the DLLs and the scripts and got the soma message all the time.
Whats wrong?
Bye
--
Email: Joerg Desch <jd DOT vvd AT web DOT de>
Hi!
I just noticed that on Windows (tested with XP & Vista) Geany 0.13
crashes when it loads a project which has non-ascii characters in its
name (or path). Geany has no problems when it creates the project.
If I open files with non-ascii characters in their names via normal open
dialog, Geany reads and shows their contents fine. So the problem
appears only when the non-ascii characters are in a project's name(or
path). Just before the crash, Geany displays an error dialog saying that
it can't open the file.
My Linux machine is in a bad shape so I can't test this on it.
The non-ascii characters I used are UTF-8 'ö' and 'ä' (hex c3 b6 and c3 a4).
Best regards,
-Harri