Re: Issue with vim and GtkFileChooser

[Emmanuele Bassi <ebassi gmail com>]

On Sat, 2008-07-26 at 16:34 +0200, Guido Berhoerster wrote:


> > so, if you're seeing writes to that file you'll have to find the calls
> > to gtk_recent_manager_add_item() or gtk_recent_manager_add_full().
> 
> $ grep gtk_recent vim71/src/*.c | wc -l
> 0
> 
> There is no use of GtkRecentManager in the vim source.
> 
> Yet using strace on vim reveals this
> 
> [...]
> open("/home/gber/.recently-used.xbel.WBHYEU", O_RDWR|O_CREAT|O_EXCL, 0666) = 15
> fcntl(15, F_GETFL)                      = 0x8002 (flags O_RDWR|O_LARGEFILE)
> fstat(15, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcbd288f000
> lseek(15, 0, SEEK_CUR)                  = 0
> write(15, "<?xml version=\"1.0\" encoding=\"UT"..., 218) = 218
> close(15)                               = 0
> munmap(0x7fcbd288f000, 4096)            = 0
> rename("/home/gber/.recently-used.xbel.WBHYEU", "/home/gber/.recently-used.xbel") = 0
> stat("/home/gber/.recently-used.xbel", {st_mode=S_IFREG|0644, st_size=218, ...}) = 0
> [...]
> 
> on every keypress, mouseclick etc.

I have no idea. the FileChooser only job is to read the file to get the
contents; I would expect to see a lot of read() operations.

the only time when a gtk+ application writes to the recently used files
storage and it's not calling the GtkRecentManager API directly is when
the gtk+ main loop level reaches 0 - which is to say after the first
gtk_main() call in the whole application returns (this is needed to
ensure that the file is not left in an inconsistent state); all other
writes are definitely explicit. I seriously doubt that vim spins the
main loop and the stops it at every key press - it would be quite
insane.

I wrote both the RecentManager and the FileChooser recently used files
list support, so I'm at loss here as much as you.

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net