gvim as provided in the Fedora packages does not support session restore
(i.e. reopening with the same buffers) because it does not integrate
with the GNOME nor KDE desktop environments.
Recompiling with gnome support helps: as a proof of concept, I've added
a vim-gnome subpackage to the spec file, see
which is based on the current F16 (updates) spec. It provides a
gnome-vim binary which is "gvim + gnome integration" and works with KDE
It's only POC because I think we need to decide about the package
structure (see also https://bugzilla.redhat.com/show_bug.cgi?id=311061).
vim can be compiled resp. is currently in Fedora in these shapes:
* with minimal features: subpackage vim-minimal
(or /usr/bin/ ;) )
* with enhanced features and without X library support: not in Fedora
* with enhanced features and no GUI: subpackage vim-enhanced
(these support vim in xterm and such specifically and depend on X
* with enh. features and gtk based GUI: vim-X11 (sic!)
* with enh. features and gtk based GUI via GNOME libs: not in Fedora
This one integrates with the usual GNOME and KDE session management and
is provided as gnome-vim in my spec above.
* with motif/athena/nextaw: okay okay...
I think gnome-vim is really needed, but it could be provided as above
(maybe plus gnome-view etc.), as an alternative (vim-gtk and gnome-vim
as alternatives for gvim using the alternatives system) or as a
subpackage providing gvim directly (so that you can install at most one
of gtk/gnome versions).
Also, we may want to rename vim-X11 to vim-gtk, any maybe even provide
an X-less vim-enhanced. What do you think?
We are building a leading edge Operating System, but still use only 8bit colors
by default in our terminal (I don't know about KDE… I stay under
GNOME, gnome-term (xterm)).
This limit the colors of many applications like vim, screen, tmux, weechat…
As seen (quick but not exhaustive check), all dependencies for xterm
in 256 colors are there,
we just need to define `TERM=xterm-256color' in order to get 256 colors…
So what would be needed?
I have just done the long-awaited update of pari from 2.3.x to 2.5.x in
Rawhide, which has associated soname and API changes. The delay was
mainly due to there being no movement upstream in porting perl-Math-Pari
to the new API, so I have given up on that and introduced a libpari23
package that perl-Math-Pari is now built against.
As a result of the introduction of the libpari23 package, there should
be no broken dependencies caused by this update, but new builds of
packages using libpari will use the new version. We're not envisaging
there being any big issues with this but if there are, please report
them on the pari upgrade ticket (http://bugzilla.redhat.com/821191) and
we'll try to help.