On Tue, 20 May 2008 16:08:20 -0700, Kent <kent(a)uoregon.edu> wrote:
> I had problems printing the manual
> http://geany.uvena.de/0.14/index.html with firefox in "letter" size.
> It was dropping the last 5 to 12 characters on long lines. I finally
The manual wasn't really intended to be printed.
> width: 50em;
Does changing the width to 50em generally, i.e. also for other paper
formats like A4?
Does anyone have a clue? Is there any reasonable width value?
Alternatively, we could generate the manual for printing without any
width value, then it takes as much width as available. This should work
fine when printing.
P.S.: As Nick already said, please don't hi-jack other threads. This
makes it really hard to follow the discussion with threaded views. I
intentionally start a new thread with this answer.
Get my GPG key from http://www.uvena.de/pub.asc
I'm currently playing with geanylua 0.7 and geany 0.14. As you may see, I'm a Lua newbie and this is part of my first script...
I would line to extract the remaining part of a line but without trailing whitespaces and without the \n.
Here a snippet of my code, where _to is the starting point of the needed string and curr_line is the result of geany.lines(..):
if ( #curr_line > (_to+1) ) then
if _strip_from then
print(string.format("strip from pos %d to %d",_strip_from,_strip_to))
Email: Joerg Desch <jd DOT vvd AT web DOT de>
I contacted the main developper of Geany to ask him if integrating a PHP
Debugger in Geany was planned. Unfortunately, there is no plans for this.
I would like to have this in Geany since it is the only primary thing
that prevent Geany from beeing a major PHP IDE to my opinion. It has
many advantages over other IDE's i used for PHP : straight foward &
simple, fast, lightweight, not too many dependencies (easier for cross
platform), fit for more than one language.. etc. I think you know the
I have basic knowledge in C++ so i don't think I would be able to do it
myself but with some help I would be glad to participate in this project
if someone is willing to this.
However, here are some explanations on how a debugger works, what work
should be done to integrate this into Geany
First of all, a PHP debugger is an extension your load in the php.ini
file on your PHP developement server as usual extention for PHP. There
are mainly 3 debuggers available for free to install on your web server :
- xdebug (free open source) http://xdebug.org/
- zend debugger (free, not open source)
- DBG (free open source) : http://sourceforge.net/projects/dbg2
These debuggers opens a port on your test server ie. Zend Debugger (the
one I used the most) opens normally port 10000. It uses this port to
communicate with the app ie. Geany (with the client debugger running in
BG) to listen to where breakpoints should be. It also sends stack
information, current line, current file, etc. like a normal debugger would.
On unix, a PHP debugger is normally a .so file (shared object). On
windows, a DLL file. The .so or .dll file must match the PHP version you
are using. Only the main version and sub version must match. ie PHP
5.2.25 would need a debugger named xxx.5.2.so for unix/linux. This is
for the server part. Not all debuggers provides different versions for
different versions of PHP... DBG for example supports all major PHP
versions with the same DLL or .SO. Zend however do provide different DLL
or SO for all PHP versions
I dont know the internal mechanics of the debugger but I know how to
install it. However, the free debugger DGB would be a nice way to
introduce PHP debug into Geany since it is open source. Also, PDT for
eclipse supports Zend Debugger and I'm pretty sure it is open source (so
is Eclipse!) so we can see how to do it (unfortunately in java..so a bit
of java understanding is needed here).
In order to add this functionnality in geany, these must be implemented :
- A communication channel between the debugger & Geany.
Perhaps there is a client & server part for each debugger.
In DBG, a command line utility is available to debug a page without an
Starting to debug a page on apache server is done this way by url call:
Just appending the green part to the url fires up the debugger...
or by the commandline this way :
>set mode on
>set mapurlroot http://localhost/
>set mapremoteroot /usr/local/apache/htdocs/
>set maplocalroot /usr/local/apache/htdocs/
DBG have a DBG-cli as a client you can capture command line output in
Geany & interract with the debugger in background.
Communication between app & debugger may vary from one to another... not
sure it is always as DBG does...
- Stack pannel : Displays variables values, expandable object structures
& values within objects, ...
- Watch pannel : displays infos about a variable each time it encounters
- Local stack (normally presented as thumbs in the same pannel as stack.
- Output view (optionnal but useful)
- Errors view... the errors PHP encounters while parsing the page.
- A browser plugin for firefox (similar to zend toolbar, a must have. I
guess I could do that, its in XML... so I'm ok with this !). This
plugins allows a browser to start a debugging process & opens the file
- A debugger configuration dialog. Sets the base path of the server so
files are converted tu urls by the app when you start debug from the app.
- A setting to automatically add breakpoints on first line & ending line
of a script.
- A clear all breakpoints setting
- A clear all breakpoints in project setting
- A test debug connection functionnality (tells if the debugger works)
- A port setting to change the port used (don't know how this might work...)
- The ability to bind a key combination to hide all debugger pannels
(they take a lot of screen space and have to be showed & hidden often)
In the edit area :
- Clicking on a line number toggles a breakpoint. Normally visible by
changing bg color of that line.
- When a breakpoint is reached, the BG color of that line must change to
something really visible.
- As PHP debugger goes into included files, files containing a
breakpoint should automatically open & have focus
- While debugging is stopping on a breakpoint, you should be able to add
other breakpoints in any file live (without restarting debugger)
I know that the app ie Geany has to controls the debugger. For example
you normally have a play button, a step into, step out & a stop buttons
to control debug progression. The app must send a signal to the debugger
port/or hidden commandline to tell continue to it. In DBG it is a
command issued on the command line in an hidden shell...
I'm pretty sure all the vars are not queryed by the app. Ie. the app
dont know which vars should be in the stack. Instead the debugger send
all vars & values to the app. & the app displays them blindly.
* For local & general stack views, I think the app must do something for
this... I'm presuming the app must know in which object/function we are
and filter the stack data to reflect the local view... not sure after
reading a bit on DGB thought.
* I never looked into a debugger code neigther I unsterstand how the
communication works between the app & debugger so I am making
assumptions here (where there is a * before a line)...
Other infos you might find useful :
- I never saw a PHP debugger run fast. Is is all slow, I suspect the
debuggers from being coded in an awful way...
- Only one debugger can run on a PHP install. That means that if you
install one by loading the extension in your PHP.ini file, you have to
remove it & load the extension for the second, then restart apache to
make it work.
- Zend Debugger : I came across a couple of innacuracies with Zend
Debugger particularly in complex PHP apps. A script was not working, a
bug in there somewhere maked it stop. I debugged this script with Zend
and it passed throught it without an error. So I am suggesting to take
another debugger than that one or add multiple debuggers possibility to
Geany (this feature is not present in any IDE I saw, would be nice thought).
- There is a toolbar for firefox to use with DBG debugger (from
NuSphere) so this a bit less work !
- DBG is free and has been in the market for a long time... as long as
- xDebug is fairly new
- I heard bad & good comments with xDebug but never tried it. Seems like
it is not ready for stability & accuracy yet. However it may have
evolved since these comments.
That is all I can think of right now...
I'll check if I can find a more in depth doc about how to communicate
with a debugger in the point of view of Geany. There is a brief view of
how to communicate with the debugger in the DBG CLi sources in the
I attached you DBG C++ source code so you can see by yourself...
Included DBG CLI (client commandline)
& DBG (server part)
Let me if someone is interested in doing this plugin for geany...
I personnaly would choose DBG for the debugger but that should be more
discussed before doing anything.
I'm not that common with working on Windows, but I recognized a behaviour
of the Geany W32 today where I'm not sure, if it is optimal. When marking
more then one file and click on 'open with Geany', for very file a new
instance of Geany is started. Can somebody of you give me some input on