On Jul 2, 2013, at 6:29 AM, "Christian Brabandt" <[email protected]> wrote:
> On Mon, July 1, 2013 17:45, Ingo Karkat wrote:
>> Hello Vim developers,
>>
>> I noticed a regression:
>>
>> $ vim -N -u NONE
>> :echo "foo"
>> " The intro message is cleared, the (now empty) UI does not show "foo".
>> " Expected behavior: The intro message stays visible, the command-line
>> shows "foo".
>>
>> This happens with any command that echoes a single line, e.g. also with
>> :set ic?, or :nmap. Only the very first command (output) is affected;
>> subsequent commands (after the intro message was cleared) show up fine.
>> I see this in Vim 7.3.1280 (huge build on Ubuntu 13.04/x64), but not in
>> Vim 7.3.712. It also doesn't happen in GVIM, only in the terminal UI.
>
> I don't see this for vim -u NONE -N (and I suspect, this is terminal
> related), but for me this happens, because I have a plugin, that resets
> some highlighting groups whenever the statusline is drawn. This triggers
> a do_highlight() call, which in turn calls redraw_win_later() and resets
> must_redraw, although it has been set to zero earlier in update_screen()
>
> This patch fixes it for me, but I am not sure, this also fixes your
> issue:
>
> diff --git a/src/screen.c b/src/screen.c
> --- a/src/screen.c
> +++ b/src/screen.c
> @@ -327,6 +327,7 @@
> {
> win_T *wp;
> static int did_intro = FALSE;
> + int cur_must_redraw = must_redraw;
> #if defined(FEAT_SEARCH_EXTRA) || defined(FEAT_CLIPBOARD)
> int did_one;
> #endif
> @@ -335,16 +336,16 @@
> if (!screen_valid(TRUE))
> return;
>
> - if (must_redraw)
> - {
> - if (type < must_redraw) /* use maximal type */
> - type = must_redraw;
> + if (cur_must_redraw)
> + {
> + if (type < cur_must_redraw) /* use maximal type */
> + type = cur_must_redraw;
>
> /* must_redraw is reset here, so that when we run into some weird
> * reason to redraw while busy redrawing (e.g., asynchronous
> * scrolling), or update_topline() in win_update() will cause a
> * scroll, the screen will be redrawn later or in win_update(). */
> - must_redraw = 0;
> + cur_must_redraw = 0;
> }
>
> /* Need to update w_lines[]. */
> @@ -356,7 +357,7 @@
> if (!redrawing() || updating_screen)
> {
> redraw_later(type); /* remember type for next time */
> - must_redraw = type;
> + cur_must_redraw = type;
> if (type > INVERTED_ALL)
> curwin->w_lines_valid = 0; /* don't use w_lines[].wl_size now */
> return;
> @@ -594,6 +595,7 @@
> gui_update_scrollbars(FALSE);
> }
> #endif
> + must_redraw = cur_must_redraw;
> }
>
> #if defined(FEAT_CONCEAL) || defined(PROTO)
>
>
> --
Sadly, the bug is still alive with this patch...
In addition to those unexpected behaviors that have been reported so far, the
"bug" looks to manifest itself only when vim runs on an xterm for the first
time. In other words, if you invoke vim on a newly opened xterm and follow the
instructions to reproduce the bug, you'll see it. But after quitting that vim
and then invoking another vim process there, the bug's gone somewhere...
The behavior I've just mentioned happens independently of the options -N -u
NONE. Also, it happens not only with a 'huge' vim but also with 'normal' and
'big' ones.
Interestingly, vim running on Terminal.app (an xterm variant tailored for
Mac(?)) doesn't show such behaviors at all. Furthermore, a non-GUI version
that depends on darwin shows the same problematic behaviors, but a non-GUI
version that *doesn't* depend on darwin (in other words, a non-GUI but *X11
dependent* version) works well. (The problem might be relevant to ICC and/or
SM...?)
That said, the vim shipped with MacOS X 10.8.4, the version of which is 7.3 and
looks no patch applied, not linked against X11, works well. This suggests that
the early patch-levels of 7.3 are free from this particular bug.
So it looks the problem lies in (lack of) some interaction between the terminal
initialization done by vim and that of xterm.
Hopefully, this partial observation could save someone's time and labor (I'm
also trying to fix it, but can't find a good solution to it till now.)
- KK
--
--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
