actually gedit *has* this feature, but it's a bit buggy at the moment.

For instance opening a file with "gedit +100 foo.txt", does open foo.txt and
moves the cursor to line 100, but it doesn't scroll the view to the cursor position.

Whoops, so it does. My verification process left something to be desired ;-). I
hope this bux is going to be fixed come 2.10; also, the man page needs to be
updated.

It could be we should scroll_to_cursor on expose.
See bug #102862.

Created attachment 37686 [details] [review]
patch

this patch seems to fix the problem for me: it adds an idle handler when the
document finished loading, so that the view to scroll actually exist.

Created attachment 37687 [details] [review]
above patch + doc position persistance

after the above patch, works also the feature of persisting the cursor position
in the metadata which was currently commented out.


However I'm not sure if we should enable it, since it's a bit confusing:
GtkTextView fills its contents incrementally, so you already see the doc and
you have a chance to start editing and at some points (when loading finished)
it jumps to the stored position.

I have a patch too that use the expose-event (it scrools on the first expose-event).

Created attachment 37705 [details] [review]
Patch against CVS HEAD (v. 1)

This patch should fix the problem.

It scrolls to cursor on the first expose-event so it does not have the problem
pbor described in his comment [i.e. "GtkTextView fills its contents
incrementally, so you already see the doc and you have a chance to start
editing and at some points (when loading finished) it jumps to the stored
position."]

It works well for me except in a particular case.
If I have an already running gedit and run "gedit +100 file" from a
gnome-terminal, sometimes gedit does not scroll to cursor. I think this is due
to the "focus-stealing" problem we already experiences with metacity (but I'm
not sure).

I have also update the man page and improved a bit the way gedit scrolls the
text while searching for text.

When loading a list of files, the first one is now set as active. It was the
last one before this patch. This change worries me a bit since I don't remember
if there was a reason it was setting the last one as active.
BTW, I think the new behavior is the right one.

I have not activated the feature of restoring the cursor position
from the metadata (which is currently commented out) since I think we are a bit
late in the development cycle to active this feature. I'm not sure it would be
appreciated by all the people, so probably we should discuss a bit about it and
 eventually provide a gconf key to disable it. 

Please, review and test this patch.

Created attachment 37714 [details]
IRC log with comments on my patch

uhm... actually after having tried, your patch doesn't work at all for me :/

I mean that doing gedit +100 ChangeLog, not only doesn't scroll but doesn't even
move the cursor to line 100 at all.

(the problem is in the change in gedit-document.c, I fixed it in my local copy
by making the "loaded" signal G_SIGNAL_RUN_FIRST instead of RUN_LAST...)

Created attachment 37739 [details] [review]
Patch against CVS HEAD (v. 2)

This new version of the patch solved the problem related to the activation the
first added view.
It still has problems in the case the user has an already running gedit and
runs "gedit +100 file" from a gnome-terminal. In that case, gedit does not
scroll to cursor as expected.

Created attachment 37742 [details] [review]
b-a-s patch

totally untested since bonobo activation server is borked on my machine...
paolo: does this patch help with the multiple instance case?


unrelated, but to make sure we don't forget: your v2 patch still blocks the
expose handler instead of disconnecting it.

Created attachment 37745 [details] [review]
Patch against CVS HEAD (v. 3)

This patch seems to solve all the problem we had with the previous ones.

Committed to CVS HEAD.