UPDATE: vim

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

UPDATE: vim

f.holop
is it a rocket? is it an aeroplane? is it the emacs
killer?

it is all that and much more, the new and shiny vim 8.
many new features but it compiles so please test and commit :}

-f
--
when you come to a fork in the road, take it!

vim.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: vim

Stuart Henderson
On 2016/09/15 01:09, frantisek holop wrote:
> is it a rocket? is it an aeroplane? is it the emacs
> killer?
> --- pkg/PLIST-main 10 Aug 2016 15:54:29 -0000 1.15
> +++ pkg/PLIST-main 14 Sep 2016 23:06:30 -0000
> @@ -17,6 +17,15 @@ bin/vimtutor
>  @man man/man1/vimdiff.1
>  @man man/man1/vimtutor.1
>  @man man/man1/xxd.1
> +share/applications/vim.desktop

This should be in PFRAG.no-no_x11-main (otherwise you need
update-desktop-database bits in PLIST-main and an extra dep on
desktop-file-utils).

> +share/icons/hicolor/48x48/apps/gvim.png
> +share/icons/locolor/
> +share/icons/locolor/16x16/
> +share/icons/locolor/16x16/apps/
> +share/icons/locolor/16x16/apps/gvim.png
> +share/icons/locolor/32x32/
> +share/icons/locolor/32x32/apps/
> +share/icons/locolor/32x32/apps/gvim.png

Also to no-no_x11-main - and I think this needs an x11/gtk+3,-guic dep
and gtk-update-icon-cache @execs (portcheck should tell you about this).

The rest looks sane, will test later.

>  share/vim/
>  share/vim/${P}/
>  share/vim/${P}/autoload/
> @@ -444,6 +453,7 @@ share/vim/${P}/ftplugin/rrst.vim
>  share/vim/${P}/ftplugin/rst.vim
>  share/vim/${P}/ftplugin/ruby.vim
>  share/vim/${P}/ftplugin/sass.vim
> +share/vim/${P}/ftplugin/scala.vim
>  share/vim/${P}/ftplugin/scheme.vim
>  share/vim/${P}/ftplugin/screen.vim
>  share/vim/${P}/ftplugin/scss.vim
> @@ -582,6 +592,7 @@ share/vim/${P}/indent/rrst.vim
>  share/vim/${P}/indent/rst.vim
>  share/vim/${P}/indent/ruby.vim
>  share/vim/${P}/indent/sass.vim
> +share/vim/${P}/indent/scala.vim
>  share/vim/${P}/indent/scheme.vim
>  share/vim/${P}/indent/scss.vim
>  share/vim/${P}/indent/sdl.vim
> @@ -661,6 +672,7 @@ share/vim/${P}/keymap/polish-slash_iso-8
>  share/vim/${P}/keymap/polish-slash_utf-8.vim
>  share/vim/${P}/keymap/russian-dvorak.vim
>  share/vim/${P}/keymap/russian-jcuken.vim
> +share/vim/${P}/keymap/russian-jcukenmac.vim
>  share/vim/${P}/keymap/russian-jcukenwin.vim
>  share/vim/${P}/keymap/russian-jcukenwintype.vim
>  share/vim/${P}/keymap/russian-yawerty.vim
> @@ -1239,6 +1251,7 @@ share/vim/${P}/syntax/samba.vim
>  share/vim/${P}/syntax/sas.vim
>  share/vim/${P}/syntax/sass.vim
>  share/vim/${P}/syntax/sather.vim
> +share/vim/${P}/syntax/scala.vim
>  share/vim/${P}/syntax/scheme.vim
>  share/vim/${P}/syntax/scilab.vim
>  share/vim/${P}/syntax/screen.vim

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: vim

f.holop
Stuart Henderson, 15 Sep 2016 10:11:

> On 2016/09/15 01:09, frantisek holop wrote:
> > is it a rocket? is it an aeroplane? is it the emacs
> > killer?
> > --- pkg/PLIST-main 10 Aug 2016 15:54:29 -0000 1.15
> > +++ pkg/PLIST-main 14 Sep 2016 23:06:30 -0000
> > @@ -17,6 +17,15 @@ bin/vimtutor
> >  @man man/man1/vimdiff.1
> >  @man man/man1/vimtutor.1
> >  @man man/man1/xxd.1
> > +share/applications/vim.desktop
>
> This should be in PFRAG.no-no_x11-main (otherwise you need
> update-desktop-database bits in PLIST-main and an extra dep on
> desktop-file-utils).

it was indeed fishy that suddenly it showed up in the
main PLIST.

> > +share/icons/hicolor/48x48/apps/gvim.png
> > +share/icons/locolor/
> > +share/icons/locolor/16x16/
> > +share/icons/locolor/16x16/apps/
> > +share/icons/locolor/16x16/apps/gvim.png
> > +share/icons/locolor/32x32/
> > +share/icons/locolor/32x32/apps/
> > +share/icons/locolor/32x32/apps/gvim.png
>
> Also to no-no_x11-main - and I think this needs an x11/gtk+3,-guic dep
> and gtk-update-icon-cache @execs (portcheck should tell you about this).

<frown> bring in gtk+3 just for a bunch of icons?
there is already an icon in pixmaps.  couldn't this
wait until we actually build vim (also) with gtk+3?

> The rest looks sane, will test later.

thanks for looking into it.
will run portcheck now every time.

-f
--
excellent day to have a rotten day.

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: vim

Antoine Jacoutot-7
On Thu, Sep 15, 2016 at 11:18:09AM +0200, frantisek holop wrote:

> Stuart Henderson, 15 Sep 2016 10:11:
> > On 2016/09/15 01:09, frantisek holop wrote:
> > > is it a rocket? is it an aeroplane? is it the emacs
> > > killer?
> > > --- pkg/PLIST-main 10 Aug 2016 15:54:29 -0000 1.15
> > > +++ pkg/PLIST-main 14 Sep 2016 23:06:30 -0000
> > > @@ -17,6 +17,15 @@ bin/vimtutor
> > >  @man man/man1/vimdiff.1
> > >  @man man/man1/vimtutor.1
> > >  @man man/man1/xxd.1
> > > +share/applications/vim.desktop
> >
> > This should be in PFRAG.no-no_x11-main (otherwise you need
> > update-desktop-database bits in PLIST-main and an extra dep on
> > desktop-file-utils).
>
> it was indeed fishy that suddenly it showed up in the
> main PLIST.
>
> > > +share/icons/hicolor/48x48/apps/gvim.png
> > > +share/icons/locolor/
> > > +share/icons/locolor/16x16/
> > > +share/icons/locolor/16x16/apps/
> > > +share/icons/locolor/16x16/apps/gvim.png
> > > +share/icons/locolor/32x32/
> > > +share/icons/locolor/32x32/apps/
> > > +share/icons/locolor/32x32/apps/gvim.png
> >
> > Also to no-no_x11-main - and I think this needs an x11/gtk+3,-guic dep
> > and gtk-update-icon-cache @execs (portcheck should tell you about this).
>
> <frown> bring in gtk+3 just for a bunch of icons?

That does not bring gtk+3 at all.

--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: vim

f.holop
In reply to this post by Stuart Henderson
next try.

moved icons no-no_x11, added gtk+3,-guic RDEP,
decided to drop the vim.desktop file, gvim is already there.


portcheck seems to have problems with this port,
probably because its mandatory FLAVOR selection?

/usr/ports/editors/vim$ /usr/ports/infrastructure/bin/portcheck
1 line(s) longer than 80 chars in Makefile
Fatal: You must select one GUI interface: no_x11, gtk2, athena or motif (in editors/vim)
*** Error 1 in /usr/ports/editors/vim (/usr/ports/infrastructure/mk/bsd.port.mk:3469 '.BEGIN': @exit 1)
Fatal: You must select one GUI interface: no_x11, gtk2, athena or motif (in editors/vim)
*** Error 1 in /usr/ports/editors/vim (/usr/ports/infrastructure/mk/bsd.port.mk:3469 '.BEGIN': @exit 1)
Fatal: You must select one GUI interface: no_x11, gtk2, athena or motif (in editors/vim)
*** Error 1 in /usr/ports/editors/vim (/usr/ports/infrastructure/mk/bsd.port.mk:3469 '.BEGIN': @exit 1)
in -main, FLAVOR "gtk2": Python module without compiled version, consider using ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py: share/vim/vim80/
tools/demoserver.py
in -main, FLAVOR "athena": Python module without compiled version, consider using ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py: share/vim/vim8
0/tools/demoserver.py
in -main, FLAVOR "motif": Python module without compiled version, consider using ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py: share/vim/vim80
/tools/demoserver.py
in -main, FLAVOR "no_x11": Python module without compiled version, consider using ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py: share/vim/vim8
0/tools/demoserver.py
Fatal: You must select one GUI interface: no_x11, gtk2, athena or motif (in editors/vim)
*** Error 1 in /usr/ports/editors/vim (/usr/ports/infrastructure/mk/bsd.port.mk:3469 '.BEGIN': @exit 1)
Fatal: You must select one GUI interface: no_x11, gtk2, athena or motif (in editors/vim)
...
...
...


--
many would be cowards if they had enough courage.

vim.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: vim

f.holop
In reply to this post by f.holop
resubmitting 8.0 with latest patchlevel.
no real changes from last time.

please test and commit

-f
--
does the name "pavlov" ring a bell?

vim.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: vim

Laurence Tratt
On Sun, Sep 25, 2016 at 11:14:25PM +0200, frantisek holop wrote:

Hello Frantisek,

> resubmitting 8.0 with latest patchlevel.
> no real changes from last time.

This has been working well for me all day on amd64 -- thanks!

Although it's not directly related to the port, I wonder if we might also
take this opportunity to think about the versions that we provide binary
packages for. At the moment it's:

     SUBDIR += vim
     SUBDIR += vim,gtk2,lua
     SUBDIR += vim,gtk2,perl,python,ruby
     SUBDIR += vim,gtk2,perl,python3,ruby
     SUBDIR += vim,no_x11
     SUBDIR += vim,no_x11,lua
     SUBDIR += vim,no_x11,perl,python,ruby
     SUBDIR += vim,no_x11,perl,python3,ruby

Of course, vim has enough FLAVORs that no reasonable number of combinations
will keep everyone happy. But given the increasing number of languages that
extensions are written in (I use extensions in Lua and Python myself, so I
can no longer use a binary package), I wonder if we should simply add lua
into what has already more-or-less-become the "all the languages binary
package"? So something like:

     SUBDIR += vim
     SUBDIR += vim,gtk2,lua
     SUBDIR += vim,gtk2,lua,perl,python,ruby
     SUBDIR += vim,gtk2,lua,perl,python3,ruby
     SUBDIR += vim,no_x11
     SUBDIR += vim,no_x11,lua
     SUBDIR += vim,no_x11,lua,perl,python,ruby
     SUBDIR += vim,no_x11,lua,perl,python3,ruby

Compared to Python and Ruby, lua is a pretty small dependency (e.g. ~25x
smaller binary package than Python on amd64).


Laurie
--
Personal                                             http://tratt.net/laurie/
Software Development Team                                http://soft-dev.org/
   https://github.com/ltratt              http://twitter.com/laurencetratt

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: vim

f.holop
Laurence Tratt, 26 Sep 2016 22:08:
> Of course, vim has enough FLAVORs that no reasonable number of combinations
> will keep everyone happy. But given the increasing number of languages that
> extensions are written in (I use extensions in Lua and Python myself, so I
> can no longer use a binary package), I wonder if we should simply add lua
> into what has already more-or-less-become the "all the languages binary
> package"? So something like:

i proposed the same thing long time ago.

the whole port is a bit strange with the forced
GUI selection.  even servers have been installing
xbase for a long time, so why not get rid of no_x11,
make gtk2 the default GUI and make one kitchen
sink version with all the languages?
(except the python/python3)

would there be interest in this?

in any case adding lua makes sense to me

>      SUBDIR += vim
>      SUBDIR += vim,gtk2,lua
>      SUBDIR += vim,gtk2,lua,perl,python,ruby
>      SUBDIR += vim,gtk2,lua,perl,python3,ruby
>      SUBDIR += vim,no_x11
>      SUBDIR += vim,no_x11,lua
>      SUBDIR += vim,no_x11,lua,perl,python,ruby
>      SUBDIR += vim,no_x11,lua,perl,python3,ruby

-f
--
the next sentence is true.  the last sentence was false.

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: vim

Stuart Henderson
On 2016/09/26 23:51, frantisek holop wrote:

> Laurence Tratt, 26 Sep 2016 22:08:
> > Of course, vim has enough FLAVORs that no reasonable number of combinations
> > will keep everyone happy. But given the increasing number of languages that
> > extensions are written in (I use extensions in Lua and Python myself, so I
> > can no longer use a binary package), I wonder if we should simply add lua
> > into what has already more-or-less-become the "all the languages binary
> > package"? So something like:
>
> i proposed the same thing long time ago.
>
> the whole port is a bit strange with the forced
> GUI selection.  even servers have been installing
> xbase for a long time, so why not get rid of no_x11,
> make gtk2 the default GUI and make one kitchen
> sink version with all the languages?
> (except the python/python3)
>
> would there be interest in this?

I use no_x11 because this is something I don't want to break any more
than necessary, and that reduces risk of things getting messed up with
library updates.

I originally used no_x11 because historically X used to be built
separately from base snapshots and it was quite likely to hit things
being out-of-sync. That's not much of a problem now that the snapshot
process changed, but there have also sometimes been problems with glib
updates in the past leaving packages that use it not working, so I still
choose no_x11.

I wouldn't see a problem with losing athena and motif flavours though.

> in any case adding lua makes sense to me

Generally yes. But I'd like to know what pkg_add -u says when you
have one of the current kitchen-sink packages installed and you
point it at a PKG_PATH which has a choice of the proposed new set
of packages. If it offers a choice of which to install I think
that would be reasonable, but if it fails to update then we
probably want some @pkgpath magic.

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: vim

Edd Barrett-3
In reply to this post by f.holop
On Mon, Sep 26, 2016 at 11:51:49PM +0200, frantisek holop wrote:
> Laurence Tratt, 26 Sep 2016 22:08:
> > Of course, vim has enough FLAVORs that no reasonable number of combinations
> > will keep everyone happy. But given the increasing number of languages that
> > extensions are written in (I use extensions in Lua and Python myself, so I
> > can no longer use a binary package), I wonder if we should simply add lua
> > into what has already more-or-less-become the "all the languages binary
> > package"? So something like:
>
> i proposed the same thing long time ago.

On a semi-related note, there is a bug in either gvim or gtk2 which
causes an X crash if the default acceleration method is used on an Intel
graphics card.

In the past, I have used the motif flavour to work around this. Not sure
if that is a reason to not GC it. Especially given that you can work
around the bug by using UXA acceleration.

In case anyone is interested, here is a thread about that bug:
http://marc.info/?l=openbsd-x11&m=146411135423711&w=2

--
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk