Re: [anjuta-devel] Search Dialog in Anjuta 3.2?

[Sébastien Granjoux <seb sfo free fr>]

Hi Andreas,


Le 09/02/2012 23:51, Andreas Volz a écrit :
> I've often problems after intensive debugging session. For example
> after 30-60 minutes and 10 times restarting application in gdb. All
> simple cases are working well.

That's the worst case, I will try to check it more in details. If you 
find a way to reproduce a bug, I'm interested to know how you get it.


> Maybe there's one point to improve the crash situation. Most time I'm
> just frustrated, because after crashing my project isn't saved and I've
> to reopen all my files, breakpoints,...

It happens to me even when not using the debugger. Currently the session 
information is saved only when you close the project, perhaps we can 
save it regularly.


> Maybe you should save more often of provide some sort of "crash
> assistant" like openoffice has one. So after a crash user should be
> able to just continue at the same place. This would improve the
> situation.

I don't like the crash assistant of open office. By example, currently 
each time I start it, open office try to recover a file on a removable 
media so it fails each time.


> Ok, just after some first try of code::blocks and codelite you may be
> right. But I've not yet looked into new eclipse autotools support.

The last time I check, the eclipse support was more a syntax highlight 
than a real parsing of the autotools project. But perhaps it's enough 
for you. If it's better I'm interested to know.


> There's just one limitation that troubles me. I've just created a
> ticket for it.
> https://bugzilla.gnome.org/show_bug.cgi?id=669780

Yes, I know. There is another ticket for this :)
https://bugzilla.gnome.org/show_bug.cgi?id=474993

It's in my todo list. I have even add it on the roadmap as to be done 
for 3.4 but I want to do it correctly so it's not that easy.


> With old anjuta version it wasn't possible to create (never mind), but
> project manager showed files. Now it doesn't even parse them correct
> and show files. Bad as I've to use file browser to access my code files.

This is a bug added with the rewrite of the autotools support. It is 
fixed in anjuta 3.3.x. It's really difficult to avoid such issue.
Perhaps you could use the unstable version, you will get fixes much 
faster (it adds some other troubles too).


> > Then for this bug
> > https://bugzilla.gnome.org/show_bug.cgi?id=669359, we need to add a
> > preference somewhere but it shouldn't be a problem.
> Yes, this is my current problem. Reason I don't use Scintilla is that
> there this bug is even more worse at the moment. :-)

Ok, I think we can fix it for 3.4.


> So it'll fight against the problem that you
> will just do a svn update and get all including conflicts and stuff you
> don't like from the trunk. With the idea of viewing differences before
> just getting them you prevent problems in front and could choose what
> to merge into your local copy. If you've ever just updated a trunk
> where 20 other peoples commit also you know the problem.

I don't have much trouble getting everything from a repository and 
solving conflict afterward even when merging branches. You don't have to 
look at changes that are merged automatically. But, I'm using meld quite 
often, mainly for comparing file not under version control. Indeed it's 
better to see changes side by side instead of looking at a context diff.


> But keep on the good work! I see the progress in Anjuta over the years.
> I was just frustrated, because some use cases aren't working for me any
> longer. If you say there's some work on it I'm happy. :-)

I understand, I'm using Anjuta too. Thanks for you comments.


Regards,

Sébastien