I'm happy to announce a new version of GeanySendMail plugin, a little
plugin for Geany to send a document as attachment using the preferred
mail client. Since 0.3 I did a few changes and added a nice new
* Adding support for creating a mail with recipients email
(Patch by Timothy Boronczyk)
* Added placeholder for file's basename (Idea by Timothy Boronczyk)
* Added build support for Windows (not very well tested)
* Updates at translation, documentation and build system
With release of Geany 0.15 this plugin depends on latest version of
Geany. 0.14 or below are not longer supported.
I've uploaded the source code as well as updated the website.
Frank Lanitz <frank(a)frank.uvena.de>
For some reason, Geany often (though not always!?) displays a blank line (as
indicated by line numbers) at the end of files even if there really isn't one.
This can be quite irritating, as some scenarios require a (possibly even exactly
one) trailing blank line.
Is this a bug?
Hi Enrico, hi Nick,
thanks for the explanations. I'm still using Geany 0.13, and my local
version of the manual does not contain the note on \r and \n matching in
regular expressions - that's why I was a bit lost.
Would be cool to have multi-line support in the future - fingers crossed
that the Scintilla devs will implement it!
I need some advise with search and replace and newline with Geany.
Consider the following lines:
This is an example
"line starting with quotes
line starting without quotes
I want to find every line that does NOT start with a quote and replace
the new line character that preceed it. In other words, all lines not
starting with a quote should be joined with the previous line.
In Geany, when only using the Option "Use regular expressions", the \n
pattern does not find any new line characters. When I only apply "Use
escape sequences", it finds the new lines. But using both options
together again does not work.
As i need to find all lines not starting with a quote, I have to use a
regex [^"] AND be able to find new lines...
Am I missing some setting here or is it a bug, that "Use regular
expression" does not recognize \n? Or is there another regex syntax for
matching new lines that would work?
Thanks for your help!
I guess it is better to write in english here so I will try not to write
in french and not to make too many mistakes.
I use Geany to write Pascal programs and to compile them with fpc, that
is Free Pascal.
When I click on the "Compiler" Button, I get a "Compilation terminée
avec succès" when my program has no error. Nice.
And I get a "Compilation échouée" (french for compilation failed) when
my program is wrong. But where are the details (error type, error line,
First of all I would like to say, I love this program, I love how it is much
easier to configure than gnome-text-editor.
Now for my questions (2):
I have edited the filedefs.asm file so that it will work for mips isa.
Everything is great except for one thing, the comments. Geany won't
recognized anything following # as a comment.
The only way I have found for Geany to treat everything to the right of #
correctly is by doing CTRL - D to comment a line. Here is the fun part, the
symbol it inserts is whatever is in the "comment_open= " field. Well I tried
having "comment_open=#" but that doesnt work, if I try something like
"comment_open=;" geany treats it as a one line comment when I CTRL-D that
So any idea how to get Geany to treat # correctly would be great.
The second question is if there is a special keyword I could use so that
Geany would color a label. For reference a label is anything preceding a
":". As a HUGE bonus is there any way that Geany could keep track of the
labels so that when it is used in the code some where geany will color it?
Example of Label
LOOP: addi $1,$0,3
Thanks to all for the comments/suggestions so far.
To be sure that I have been clear, when I talk about the Geany build system
I am only talking about the ability of Geany to invoke builders, not the
system used to build Geany and nor am I talking about incorporating any
specific system into Geany nor about incorporating specific support for any
system(s) into Geany, just general support for any command that can be run.
As Enrico said, simple is better.
Our approach to build tools is that they vary in performance, capabilities
and system requirements and individual projects make their decisions based
on technical, practical and philosophical grounds. When we then use their
pachage we arn't going to change the build system since we would have to
re-do it each time a new release happened. So we end up using lots of
On a specific note, the developer who told me about the -o simply stopped
using the facility when he had problems, and so didn't notice it had been
fixed. He has been sent to read the release notes 50 times ;-).
Having now had a chance to read the code and talk to my developers some
more, I am in a better position to discuss how the system currently works
and how we might like it to work.
To ensure I understand it, the current system works as:
1. Compile, build and run are filetype specific and get their command from
the filetype config (question what is runcmd2 config for?)
2. Make all. Make Object and Make custom are not file specific but add
different targets to the make command stored in preferences or default
a. since Make Object needs to find a target name it uses the current
file name + '.o' (seems to be hard coded irrespective of platform)
b. 'all' is hard coded
c. custom reads from a dialog
3. %e and %f are substituted in the build command
4. directory to run the resulting command is project file directory or
source file directory depending on preference
5. output is parsed for errors based on filetype, not sure how it works if
there are mixed languages or compiler types, which filetype does it use?
6. output is parsed for "Entering directory" messages to find the source
file with errors (since the error message doesn't have the full path and the
same filename could occur be in several directories)
The problems with this system are:
1. potential confusion from two ways of building without it being obvious
that this is the case
2. make command taken from the preferences means the user has to change the
commands when moving from software with on one system to software with
3. there are a couple of hard coded pieces
The solution to 2. and 3. is to store everything make related with the
source tree, not with the preferences, and the suggested place to store it
is the project file.
In terms of the compile command, it *may* be useful for a quick syntax check
but since the user would have to remember what options and symbols need
defining, it could be risky, and I certainly would not use the result of
such a compile, and the object file would have to be removed so that the
builder would re-build the file properly. All in all I see small gain but
lots of potential for pain and would agree with Enrico that it may be best
to remove the compile command. (however see my second thoughts later)
I suggest the following changes for the three 'make' commands:
1. to keep the menu size the same and so not have to fiddle with the latex
stuff that replaces the build menu, add a fourth 'make' command to replace
the compile command, longer term the latex stuff should be in its own menu
2. each of the four 'make' commands should have its own menu label and
complete command string stored in the project file
3. one of the 'make' commands should retain the behavior of asking with a
dialog for targets/options to be added to the command stored in the project
This system has several advantages:
1. it looks relatively simple to implement
2. if can be set up to work exactly as now (well, except for no compile and
an extra make)
3. it gains a degree of platform independence, eg 'make object' could have
the command 'make %e.o' on unix or 'nmake %e.obj' on windows, and those of
us using both targets just have two project files: 'my_proj_win.geany' and
'my_proj_lin.geany' with the appropriate settings. Note it makes the target
platform independent of the platform geany is running on, without
complicating geany's life.
4. by having variable menu item names we remove the need to remember that,
in the 'newt_adventures' project, the 'make all' menu actually means
'jabberwok the gingrich' This is why I think that this is something that
goes in the base product not in a plugin, from what I can see plugins can't
modify these menus.
Variable numbers of commands and submenus I'd postpone until later, if at
all, and agree with Nick that project type templates are plugin territory,
anyone out there want to code one.
That just leaves the file type specific build and run commands to consider.
The file type dependent behavior is correct for single file type systems
where there is no build system.
However consider developing a 'c' extension to python, the compile/build
should indeed be dependent on the c file open for editing, but the run
command is the python script that imports and tests my c extension, and that
command should not be stored against the c file type. This potential
conflict exists for any mixed language system. (No I wouldn't remember to
switch to the python file before running)
Also consider the behavior of the build menu item in the presence of a build
system, either the menu item does something independent of the build system
:-( or it invokes the build system, in which case it should be project
dependent not file dependent for all the reasons outlined above.
You will note that the problems develop in a project specific context, so I
propose a solution in that context, if a build and run command is present in
the project file then that command takes precedence over the filetype
specific commands. In fact based on this solution I may even go back on my
previous thought and might allow a simple compile command again for syntax
check, especially if it didn't actually save its output file or did a lint
or similar ;-).
For completeness the "entering directory" string should be made
configurable, again just put it in the project file.
The only other code needed would be a tab in the preferences for these
project specific commands and settings, but as the tab is fixed layout it
should be easy to do with glade.
And then the documentation needs to be updated to explain the operation of
the system, it is simple, can have defaults so simple systems work out of
the box, but is not obvious without some explanation.
Finally one other suggestion, while looking for where the filetype specific
commands are set, I had to look in the code because the menu "set includes
and arguments" was not obvious, perhaps it should be changed to "set build &
run commands" or something similar.
Hi all -
I've just been trying to compile Geany from the most recent Git
snapshot, and came across this error message.
andy@obsidian ~ $ cd geany
andy@obsidian ~/geany $ ./configure
./configure: line 1710: syntax error near unexpected token `geany,'
./configure: line 1710: `AM_INIT_AUTOMAKE(geany, 0.15)'
andy@obsidian ~/geany $
So, just wondering - has anyone else seen this?