[vim] gtk3vim: no horiz. cursor movement visible after let &gcr and set ruler (#660)

98 views
Skip to first unread message

luchr

unread,
Feb 24, 2016, 2:41:41 PM2/24/16
to vim/vim

Hello,

the GTK3-support (since 7.4.1402) is really really cool. Thank you a lot.

I found one (crazy and subtle) bug (in my compiled 7.4.1411 version):

  1. Start gtk3vim with gtk3vim -u NONE -U NONE -i NONE
  2. Enter some text (in insert-mode of course)
  3. Leave insert-mode and enter :let &gcr = &gcr.",a:blinkon0"
  4. Enter :set ru
  5. Move the cursor horizontally (e.g. with the h key)

Expected behaviour: see block-cursor movement and position-update in ruler
Seen behaviour: block-cursor is not moved, but (internal) cursor-position is changed (can be seen in the position in the ruler)

I can reproduce this bug only with the ruler-option and only if I change the option gcr with let. The bug didn't show up, if I use the set-command to change the option gcr.


Reply to this email directly or view it on GitHub.

toothpik

unread,
Feb 24, 2016, 9:09:04 PM2/24/16
to vim...@googlegroups.com
On Wed, Feb 24, 2016 at 11:41:05AM -0800, luchr wrote:
> Hello,

> the GTK3-support (since 7.4.1402) is really really cool. Thank you a lot.

> I found one (crazy and subtle) bug (in my compiled 7.4.1411 version):

> 1. Start gtk3vim with `gtk3vim -u NONE -U NONE -i NONE`
> 1. Enter some text (in insert-mode of course)
> 1. Leave insert-mode and enter `:let &gcr = &gcr.",a:blinkon0"`
> 1. Enter `:set ru`
> 1. Move the cursor horizontally (e.g. with the `h` key)

> Expected behaviour: see block-cursor movement and position-update in ruler
> Seen behaviour: block-cursor is not moved, but (internal) cursor-position is changed (can be seen in the position in the ruler)

> I can reproduce this bug only with the ruler-option and only if I change the option `gcr` with `let`. The bug didn't show up, if I use the `set`-command to change the option `gcr`.

I am having similar cursor movement problems when I build with GTK3 --
also when I run a bash script that starts 3 gvim windows specifically
sized and positioned I get two identical warnings:

(gvim:32738): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

the script that starts the windows can be seen at

https://github.com/toothpik/toothpik-s-.vimrc/blob/master/bin/ws

-tp

Kazunobu Kuriyama

unread,
Feb 24, 2016, 10:00:48 PM2/24/16
to vim...@googlegroups.com
Thank you for the report.

I'll look into the cursor issue shortly.  But before going to that, I'm going to give my answer to another issue raised by @toothpik about runtime warnings.

> (gvim:32738): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

This sort of warnings are usually issued when a user tries to resize the app window too small (and normally, the window manager and GTK usually honor the request, and the resize is done at the cost of disappearance of some part of the GUI such as menubar items or toolbar icons).

The warnings come from the GTK internal and the result of the negotiation between the user and the window system on resize. There's little room for programmers to intervene between them.

Best regards,
Kazunobu Kuriyama



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

nuko8

unread,
Mar 5, 2016, 8:54:56 PM3/5/16
to vim/vim

Thank you for reporting.

A patch for fixing the issue was included in the upstream master a few hours ago.

Hopefully, this works for you.

Regards,
Kazunobu Kuriyama

toothpik

unread,
Mar 5, 2016, 10:28:48 PM3/5/16
to vim...@googlegroups.com
On Sat, Mar 05, 2016 at 05:54:40PM -0800, nuko8 wrote:
> Thank you for reporting.

> A [patch](https://github.com/vim/vim/releases/tag/v7.4.1497) for
> fixing the issue was included in the upstream master a few hours ago.

> Hopefully, this works for you.

I for one now see proper cursor movement when I build with GTK3, I also
do not see those ... oops ... I almost mis-spoke -- when I run the
script that throws up 3 small gvim windows I still see 2

(gvim:30088): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
assertion 'extra_space >= 0' failed

warnings (one of the three must be big enough to not trigger the
warning)




Kazunobu Kuriyama

unread,
Mar 6, 2016, 12:16:59 AM3/6/16
to vim...@googlegroups.com
Thank you for your prompt reply.

2016-03-06 12:28 GMT+09:00 toothpik <toot...@gmail.com>:
(gvim:30088): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
assertion 'extra_space >= 0' failed

It's a runtime warning and depends on the environments in use --- GUI width, font family, font size, display device etc.

Probably, that particular warning was issued because the specified width was too small to display the whole menubar.

If you care about it, how about changing the widths of the two small gvim to another larger value so that GTK won't complain about it?  You can't make the width smaller than the value proper for your environments to display the whole menubar, anyway.


luchr

unread,
Mar 6, 2016, 7:39:44 AM3/6/16
to vim/vim

Closed #660.

luchr

unread,
Mar 6, 2016, 7:39:44 AM3/6/16
to vim/vim

Thank you very much, Kazunobu Kuriyama. Patch 1497 fixed the issue for me.

Bye
C. Ludwig

toothpik

unread,
Mar 6, 2016, 10:15:46 AM3/6/16
to vim...@googlegroups.com
On Sun, Mar 06, 2016 at 02:16:56PM +0900, Kazunobu Kuriyama wrote:
> Thank you for your prompt reply.

> 2016-03-06 12:28 GMT+09:00 toothpik <toot...@gmail.com>:

> > (gvim:30088): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
> > assertion 'extra_space >= 0' failed

> It's a runtime warning and depends on the environments in use --- GUI
> width, font family, font size, display device etc.

> Probably, that particular warning was issued because the specified width
> was too small to display the whole menubar.

menubar? who uses menubars?

> If you care about it,

a large "if" indeed

> how about changing the widths of the two small gvim to another larger
> value so that GTK won't complain about it?

no, those widths were chosen specifically to fit their contents

> You can't make the width smaller than the value proper for your
> environments to display the whole menubar, anyway.

oh? I'd say I can, because I am, and I'm getting that ugly warning --
as of yet I've seen no ill effects from it, it's just ... ugly

--
_|_ _ __|_|_ ._ o|
|_(_)(_)|_| ||_)||<
|

Kazunobu Kuriyama

unread,
Mar 6, 2016, 10:35:36 AM3/6/16
to vim...@googlegroups.com
2016-03-07 0:15 GMT+09:00 toothpik <toot...@gmail.com>:
On Sun, Mar 06, 2016 at 02:16:56PM +0900, Kazunobu Kuriyama wrote:
> Thank you for your prompt reply.

> 2016-03-06 12:28 GMT+09:00 toothpik <toot...@gmail.com>:

> > (gvim:30088): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
> > assertion 'extra_space >= 0' failed

> It's a runtime warning and depends on the environments in use --- GUI
> width, font family, font size, display device etc.

> Probably, that particular warning was issued because the specified width
> was too small to display the whole menubar.

menubar?  who uses menubars?

That's is the widget which is referred to as the field `menubar` of the global variable `gui` of the type `gui_T`.  See `gui.h`.
 

> If you care about it,

a large "if" indeed

> how about changing the widths of the two small gvim to another larger
> value so that GTK won't complain about it?

no, those widths were chosen specifically to fit their contents

But GTK warned you they were not, didn't it?   Note that the warnings were not issued by the code I wrote.  It came from the GTK internal, as I wrote previously.  I can't stop them.

> You can't make the width smaller than the value proper for your
> environments to display the whole menubar, anyway.

oh?  I'd say I can, because I am, and I'm getting that ugly warning --
as of yet I've seen no ill effects from it, it's just ... ugly

You won't see any ill effect because GTK ignores the wrong width specification.  That's the meaning of "Gtk-CRITICAL"; GTK is going to correct the wrong instruction given by the user.


--
_|_ _  __|_|_ ._ o|
 |_(_)(_)|_| ||_)||<
              |

toothpik

unread,
Mar 6, 2016, 12:06:47 PM3/6/16
to vim...@googlegroups.com
On Mon, Mar 07, 2016 at 12:35:34AM +0900, Kazunobu Kuriyama wrote:
> 2016-03-07 0:15 GMT+09:00 toothpik <toot...@gmail.com>:
> > On Sun, Mar 06, 2016 at 02:16:56PM +0900, Kazunobu Kuriyama wrote:
> > > 2016-03-06 12:28 GMT+09:00 toothpik <toot...@gmail.com>:
> >
> > > how about changing the widths of the two small gvim to another larger
> > > value so that GTK won't complain about it?
> >
> > no, those widths were chosen specifically to fit their contents

> But GTK warned you they were not, didn't it? Note that the warnings were
> not issued by the code I wrote. It came from the GTK internal, as I wrote
> previously. I can't stop them.

> > > You can't make the width smaller than the value proper for your
> > > environments to display the whole menubar, anyway.
> >
> > oh? I'd say I can, because I am, and I'm getting that ugly warning --
> > as of yet I've seen no ill effects from it, it's just ... ugly

> You won't see any ill effect because GTK ignores the wrong width
> specification. That's the meaning of "Gtk-CRITICAL"; GTK is going to
> correct the wrong instruction given by the user.

I feel compelled to point out that GTK, for whatever correction it made,
did not alter my requested window width

the two warnings are both coming from one of the three windows, the
narrowest one, my calendar window, which I create with the -geometry
option to be 22 characters wide, and which, when it paints, is exactly
22 characters wide
Reply all
Reply to author
Forward
0 new messages