Re: gvim and geometry

2017-03-24 Fir de Conversatie Kazunobu Kuriyama 
2017-03-25 5:14 GMT+09:00 Charles E Campbell :

> Hello:
>
> On at least two machines, which both run Scientific Linux, I'm getting
> odd behavior with a -geometry command:
>
> gvim -geometry "316x40+0-0" somefile
>
> The file is opened on the bottom of the screen (316x40, open 0 pixels
> from left and 0 pixels from the bottom).
> Or, at least, that's what its supposed to do.  Sometimes it opens 0
> pixels from the top of the screen instead.
>
> I haven't found a way to get the problematic opening to occur with
> regularity -- I just did it ten times and it opened correctly, for example.
>
> Regards,
> Chip Campbell
>

Hi Dr. Chip,

First of all, I think we need to make sure how the geometry of an X11 app
is determined when it appears on the screen for the first time.

That's a result of a negotiation between the window manager in use and an
X11 app which is going to be substantiated on the screen.

As the argument to -geometry is seemingly always honored by the window
manager, it's natural that one might have an impression as if -geometry
were a command.

The reality is, however, that window managers are usually implemented to
take the argument as a hint to compute another geometry which it thinks is
suitable for the app's sharing the whole screen with other apps already
appearing on the screen, based on the geometry management policy of each
window manager.  The result of the computation is sent out to the X11 app
under negotiation as an X11 event, and, by convention, the app is expected
to follow the result as it it, not asking another negotiation.

Accordingly, the geometry which is actually used is not the one given by
the argument to -geometry, but the one the window manager computed, taking
it as a hint and into account as such.

Hence, it's not a surprise that X11 apps sometimes appear on the screen in
a way failing one's expectation, depending on the geometry management
policy of each window manager which is often subtle or obscure.

In addition to that, I think we need to consider another factor specific to
gvim.

Usually, geometry negotiations are done with respect to the geometry of the
top-level window of an app; it re-computes children's geometry based on the
geometry allocated to the top-level window by the window manager.  It's
really straightforward.

As to gvim, when it computes its geometry, it puts more emphasis on the
geometry of the text area than that of the top-level window.  Naturally,
the numbers of columns and lines do matter much more for Vim than the
values of x, y, width and height of the top-level window because it's THE
text editor :)  Plus, as can be seen in the richness of 'guioptions', the
text area is surrounded with GUI elements which can be added or removed
arbitrarily even at runtime, which gets the computation far more involved
than usual GUI apps.

While following the geometry management convention, gvim is struggling to
keep its values as a text editor.  The negotiation is always tough and
sometime fails, unfortunately, though I know that's a thing to be improved.

Best,
Kazunobu


> --
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

gvim and geometry

2017-03-24 Fir de Conversatie Charles E Campbell 
Hello:

On at least two machines, which both run Scientific Linux, I'm getting
odd behavior with a -geometry command:

gvim -geometry "316x40+0-0" somefile

The file is opened on the bottom of the screen (316x40, open 0 pixels
from left and 0 pixels from the bottom).
Or, at least, that's what its supposed to do.  Sometimes it opens 0
pixels from the top of the screen instead.

I haven't found a way to get the problematic opening to occur with
regularity -- I just did it ten times and it opened correctly, for example.

Regards,
Chip Campbell

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Coveralls not showing files

2017-03-24 Fir de Conversatie Bram Moolenaar 

For a few days now Coveralls no longer shows the line-by-line coverage
for files.  It just says "No data available in table".  Does someone
know what is going on?  I was hopeing the problem would be solved, but
it appears that is not happening.

-- 
hundred-and-one symptoms of being an internet addict:
199. You read this entire list of symptoms, looking for something
 that doesn't describe you.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Speed up parsing vim script (#1589)

2017-03-24 Fir de Conversatie Nikolay Aleksandrovich Pavlov 
2017-03-24 19:02 GMT+03:00 Pavol Juhas :
> What for? Initialization of table is very fast anyway. And Vim has to parse
> commands
> almost immediately, when source .vimrc for example.
>
> To avoid hashing every possible abbreviation of builtin commands and to
> handle user commands. hash table can be seeded with fully spelled commands
> and with their standard abbreviations (e.g., :s, :p, etc.). If .vimrc has
> other command abbreviations these would be parsed just once with STRNCMP and
> found in the hash table thereafter. I doubt there would be any noticable
> slowdown.

This would be tricky to use with user commands: every new added user
command may alter minimal abbreviation of other user commands. I
though would be fine with “user command defined first wins shortest
ambiguous abbreviation” (example below), but to do even this you need
to populate that hash table with user commands immediately at
definition or whether or not user command wins some specific
abbreviation will depend on when abbreviation is used relative to when
commands were defined.

Though there are possible fixes: e.g. when user command is defined
clear out all prefixes from the hash table in question.

Implementation looks easier if you do not use laziness, so I would not
say that this suggestion should be implemented. Still voting for
either constructing a prefix tree (memory efficient, but lookup is
going to be slower then other variant and this is harder to implement)
or hash with all possible variants of calling the command (CPU
efficient, easier to implement, but not memory-efficient).

---

Example: with

command FooBar :call FooBaz()
command FooBaz :call FooBar()

FooBar will win F, Fo, Foo, FooB and FooBa simply because it came
first, even though after FooBaz was defined all of these abbreviations
became ambiguous (current Vim behaviour).

>
> BTW, this would likely be quite fast even without seeding the hash table;
> such variant would avoid hassles maintaining a list of what should be
> pre-seeded.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
>
> --
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] `ygn` doesn't behave like `dgn` (#1587)

2017-03-24 Fir de Conversatie Ben Fritz 
On Thursday, March 23, 2017 at 12:00:55 PM UTC-5, rafaeln wrote:
> . only repeats a yank if you have se cpo+=y in your .vimrc.
> 
> 

I didn't know that, thanks!

However, "ygn" is still working as I would expect. The "gn" operator operates 
on the match *under the cursor*, or the next match. Since ygn leaves the cursor 
on the match I'd expect the next ygn (or .) to yank the same match. Delete 
works because the match is no longer there so the gn must apply to the next 
match instead. You could move the cursor between yanks to do what you want, of 
course.

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.