Present version fails to build (somewhere around glib crate) and it’s too old to figure out why. Updated instead.
Tagged version unusable with current pango (redraw issues, missing command line, etc) without backported patch, although other related fixes (e.g. shifting colored characters) from https://github.com/daa84/neovim-gtk/issues/208 couldn’t apply cleanly on ths commit.
Present version fails to build (somewhere around glib crate) and it's too old to figure out why. Updated instead.
Tagged version unusable with current pango (redraw issues, missing command line, etc) without backported patch, although other related fixes (e.g. shifting colored characters) from https://github.com/daa84/neovim-gtk/issues/208 couldn't apply cleanly on ths commit.
I’m generally not a fan of exlibs in this context (exheres should be as static as possible... code sharing is actually a problem), but doesn’t matter much.
Well, currently they can use similar install procedure (based on makefile revisions in tagged and master). My point here is: if that becomes problem for future versions, relevant parts can be offloaded again.
> code sharing
Well, currently they can use similar install procedure (based on makefile revisions in tagged and master). My point here is: if that becomes problem for future versions, relevant parts can be offloaded again.
Present version fails to build (somewhere around glib crate) and it’s too old to figure out why. Updated instead.
Tagged version unusable with current pango (redraw issues, missing command line, etc) without backported patch, although other related fixes (e.g. shifting colored characters) from https://github.com/daa84/neovim-gtk/issues/208 couldn’t apply cleanly on ths commit.
@hasufell waiting for approval or merging in, say, two weeks in case you don’t care .
Moved into exlib, build+install tested for both versions.
(NeovimGtk:23745): GLib-GIO-ERROR **: 01:45:31.695: Settings schema ‘org.gnome.desktop.interface’ is not installed
Guess it’s fine without PREFIX set:
Removed from recommended metadata in
8886e87da9
I’m generally not a fan of exlibs in this context (exheres should be as static as possible... code sharing is actually a problem), but doesn’t matter much.
I’m pedantic, but
unset s
, although it’s not needed here... I consider it good practice in bash.As usual, I forgot to
local
it. Fixed.Well, currently they can use similar install procedure (based on makefile revisions in tagged and master). My point here is: if that becomes problem for future versions, relevant parts can be offloaded again.
Reviewers
38572bd717
.