Friday, May 7, 2021

Re: RedHat Athena: GUI vim is extremely slow using terminal

Hi,

I have tried building with the motif GUI, but it does not generate the GUI version of vim. I guess some headers are missing on my system. Unfortunately, I am not the admin on that machine, so my options on what to install are limited.

Also, I had motif gvim 8.1 on some older machine, the terminal support was equally slow.


On Fri, 7 May 2021 at 18:03, Dominique Pellé <dominique.pelle@gmail.com> wrote:
Aleksandr Jakušev wrote:

> I am trying to compile the latest vim 8.2 (official release,
> without later patches)

I don't know whether it will fix your problem, but I would
advise to use the latest from git which at the time I write
this is vim-8.2.2842.  By using vim-8.2.0000 (Dec 12, 2019),
you're missing a lot of bug fixes.

> The vim 7.4 is built with -DFEAT_GUI_GTK and various
> gtk header folders included. I don't have those headers
> on my server, that's why GTK GUI is not used by configure

What about trying with the motif GUI?

Regards
Dominique

--
--
You received this message from the "vim_use" 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 a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/m6hjxFc7xmI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAON-T_hUDBKnbQhtV1E5ZyRS8MtxxzzyW7rM%2B6hodWfLUseqTQ%40mail.gmail.com.


--

Best regards,

Alex J.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAMrm4fzoXivS_X7EfzKoDGd%2BV2t2Q7pnCvDz3YiMEpoj7KS%3Deg%40mail.gmail.com.

Re: RedHat Athena: GUI vim is extremely slow using terminal

Aleksandr Jakušev wrote:


> We have Red Hat Enterprise Linux Server release 7.8 (Maipo), which by default has
> vim 7.4 installed
> ...snip...
>
FYI, My X server is one of the latest versions of vcxsrv running on Win 10.

Ah, your X server is not running on the same machine (Win 10)
as where gvim runs (Linux). Running X applications remotely
is very slow (that's not specific to Vim).

Much faster would be to use vnc or rdesktop, so the
X server would be on the same Linux machine as GVim.

Dominique

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAON-T_j4VQb99RoLXMpV0%2Bb8Af6U2j81fWT58Y_JrsSbqmr9uA%40mail.gmail.com.

Re: RedHat Athena: GUI vim is extremely slow using terminal

Aleksandr Jakušev wrote:

> I am trying to compile the latest vim 8.2 (official release,
> without later patches)

I don't know whether it will fix your problem, but I would
advise to use the latest from git which at the time I write
this is vim-8.2.2842. By using vim-8.2.0000 (Dec 12, 2019),
you're missing a lot of bug fixes.

> The vim 7.4 is built with -DFEAT_GUI_GTK and various
> gtk header folders included. I don't have those headers
> on my server, that's why GTK GUI is not used by configure

What about trying with the motif GUI?

Regards
Dominique

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAON-T_hUDBKnbQhtV1E5ZyRS8MtxxzzyW7rM%2B6hodWfLUseqTQ%40mail.gmail.com.

RedHat Athena: GUI vim is extremely slow using terminal

Hi,

We have Red Hat Enterprise Linux Server release 7.8 (Maipo), which by default has vim 7.4 installed. I am trying to compile the latest vim 8.2 (official release, without later patches). I went the usual way: download the sources, configure (default settings, only --prefix redefined), make, make install ... And got the following build:

======================================================================
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May  7 2021 15:42:09)
Compiled by xxxxxxxxxxx
Huge version with X11-Athena GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_old_static
+arabic            +file_in_path      +mouse_urxvt       -tag_any_white
+autocmd           +find_in_path      +mouse_xterm       -tcl
+autochdir         +float             +multi_byte        +termguicolors
-autoservername    +folding           +multi_lang        +terminal
+balloon_eval      -footer            -mzscheme          +terminfo
+balloon_eval_term +fork()            +netbeans_intg     +termresponse
+browse            +gettext           +num64             +textobjects
++builtin_terms    -hangul_input      +packages          +textprop
+byte_offset       +iconv             +path_extra        +timers
+channel           +insert_expand     -perl              +title
+cindent           +job               +persistent_undo   +toolbar
+clientserver      +jumplist          +popupwin          +user_commands
+clipboard         +keymap            +postscript        +vartabs
+cmdline_compl     +lambda            +printer           +vertsplit
+cmdline_hist      +langmap           +profile           +virtualedit
+cmdline_info      +libcall           -python            +visual
+comments          +linebreak         -python3           +visualextra
+conceal           +lispindent        +quickfix          +viminfo
+cryptv            +listcmds          +reltime           +vreplace
+cscope            +localmap          +rightleft         +wildignore
+cursorbind        -lua               -ruby              +wildmenu
+cursorshape       +menu              +scrollbind        +windows
+dialog_con_gui    +mksession         +signs             +writebackup
+diff              +modify_fname      +smartindent       +X11
+digraphs          +mouse             -sound             +xfontset
-dnd               +mouseshape        +spell             +xim
-ebcdic            +mouse_dec         +startuptime       +xpm
+emacs_tags        -mouse_gpm         +statusline        +xsmp_interact
+eval              -mouse_jsbterm     -sun_workshop      +xterm_clipboard
+ex_extra          +mouse_netterm     +syntax            -xterm_save
+extra_search      +mouse_sgr         +tag_binary        
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "xxxxxxx/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -DFUNCPROTO=15 -DNARROWPROTO    -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linking: gcc   -L/usr/local/lib -Wl,--as-needed -o vim -lXaw -lXmu -lXext -lXt -lSM -lICE -lXpm -lXt -lX11 -lSM -lICE -ldl  -lm -ltinfo -lnsl  -lselinux -ldl           
======================================================================

The problem with this build is that the GUI version is very slow. For example, it takes about 6 sec to start. Below are some unnecessary large timings from the startup profiling:

==================================================
161.380  159.404: expanding arguments
...
1344.137  1143.949  1143.949: sourcing .../share/vim/vim82/ftplugin/man.vim
...
5302.964  3903.539: starting GUI
==================================================

Once started, gvim more or less works, until I decide to use the terminal functionality. This is where the things become really indecent. Forget using the terminal interactively, a simple ":term ls -l" takes several minutes to run. Gvim is unresponsive during this time. Once the terminal window becomes finished, gvim becomes responsive again, but will periodically hang if you decide to navigate in the finished terminal window. During gvim hanging, the call stack looks like this:

==================================================
PID 2468 - process
TID 2468:
#0  0x00007f3469b62c20     poll - /usr/lib64/libc-2.17.so
#1  0x00007f346943c022 - 1 _xcb_conn_wait - /usr/lib64/libxcb.so.1.1.0
#2  0x00007f346943d99f - 1 wait_for_reply - /usr/lib64/libxcb.so.1.1.0
#3  0x00007f346943db12 - 1 xcb_wait_for_reply64 - /usr/lib64/libxcb.so.1.1.0
#4  0x00007f346a7d70f0 - 1 _XReply - /usr/lib64/libX11.so.6.3.0
#5  0x00007f346a7bbd3f - 1 XAllocColor - /usr/lib64/libX11.so.6.3.0
#6  0x00000000005d238a - 1 - .../usr/local/bin/vim
#7  0x000000000059537a - 1 - .../usr/local/bin/vim
#8  0x0000000000595d1c - 1 - .../usr/local/bin/vim
#9  0x000000000059c73e - 1 - .../usr/local/bin/vim
#10 0x000000000043db48 - 1 - .../usr/local/bin/vim
#11 0x000000000043fba5 - 1 - .../usr/local/bin/vim
#12 0x00000000005fbf5c - 1 - .../usr/local/bin/vim
#13 0x00000000005fd17a - 1 - .../usr/local/bin/vim
#14 0x000000000040bcb2 - 1 - .../usr/local/bin/vim
#15 0x00007f3469a91555 - 1 __libc_start_main - /usr/lib64/libc-2.17.so
#16 0x000000000040d6f4 - 1 - .../usr/local/bin/vim
==================================================

Which makes me thing that the problem is GUI/X server related. And true, this does not happen in the console verion of vim.  FYI, My X server is one of the latest versions of vcxsrv running on Win 10.

I believe that the version of vim 7.4 that comes preinstalled is faster. Unfortunately, vim 7.4 does not have the terminal functionality to compare the same things, but its start-up times are much faster, without the lags above (same vimrc is used). The vim 7.4 is built with -DFEAT_GUI_GTK and various gtk header folders included. I don't have those headers on my server, that's why GTK GUI is not used by configure...

Any advice would be appreciated.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/24fcfb04-66e2-44f2-a3fb-21b274c11337n%40googlegroups.com.

Thursday, May 6, 2021

strange behavior with unicode related to visual block mode

Hi,

In my macro I observe strange behavior if try to paste manually
created block of lines, if it contains unicode chars. Pasting
rectangular region leads to some lines strangely "elongated" in
the result. If we paste pure ASCII content of same shape no
problem happens. Following vimscript demonstrates this problem
[1].

Another case which looks as well strange is "gv" command confused
with the range, if it contains some unicode chars. Firstly we
block select such a region, replace it content with blanks, and
finally try to visually select it again with "gv" - right border
of the new selection differs from original one. If now we do
replacement of the content again, we observe replacement is made
within different, slightly larger area. If the region in question
had in the beginning pure ASCII content no such problem happens.
Following vimscript demonstrates this problem [2].

Tested with "vim --clean" on cygwin 8.2.486, and one quite
outdated linux version 8.1.1741.

Are those things known already or do they have some good explanation
perhaps?

Many thanks for making vim, and vim makes my day since many years
already :), with best regards, Anton



[1] vimscript vim_unicode_align_test.vim BEGIN
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ene
call append(line('.')-1,'+------+')
call append(line('.')-1,'A|')
call append(line('.')-1,'B|')
call append(line('.')-1,'C|')
call append(line('.')-1,'+------+')

let buf1= '' .
\ ' üuü ' . "\n" .
\ ' uu u ' . "\n" .
\ ' üuü '

let buf2= '' .
\ ' uuu ' . "\n" .
\ ' uu u ' . "\n" .
\ ' uuu '

"let @a = buf1 " bad
let @a = buf2 " good

" convert content of @a to "visual block" selection yank result
call setreg("a", @a, "b")

call cursor(2,1)
execute('normal "ap') | " paste from @a

" result when "bad"
" +------+
" A üuü |
" B uu u |
" C üuü |
" +------+

" result when "good"
" +------+
" A uuu |
" B uu u |
" C uuu |
" +------+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[1] vimscript vim_unicode_align_test.vim END



[2] vimscript vim_unicode_gv_test.vim BEGIN
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ene

let good = 1
if good
call append(line('.')-1,'+------+')
call append(line('.')-1,'A uuu |')
call append(line('.')-1,'B uu u |')
call append(line('.')-1,'C uuu |')
call append(line('.')-1,'+------+')
else
call append(line('.')-1,'+------+')
call append(line('.')-1,'A üuü |')
call append(line('.')-1,'B uu u |')
call append(line('.')-1,'C üuü |')
call append(line('.')-1,'+------+')
endif

" visually select inner region in block mode
call cursor(2,2)
execute "normal! \<c-v>/+.*+/s-2\<cr>\<esc>"

" replace content of selection with spaces
execute('normal gvr\ ')

" select again same (?!) content and replace content with dots: '.'
execute('normal gvr.')

" result when "bad"
" +------+
" A.......
" B.......
" C.......
" +------+

" result when "good"
" +------+
" A......|
" B......|
" C......|
" +------+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[2] vimscript vim_unicode_gv_test.vim END

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAMoRF4n7%3DdeGd0X_VtFAh43ZC%2BMFxnX0Mspgoskv3HGnPHBU4A%40mail.gmail.com.

Sunday, May 2, 2021

Re: Error starting :Termdebug

On Fr, 30 Apr 2021, Uri Moszkowicz wrote:

> Hi,
> I get this error running vim 8.2 when starting :Termdebug:
>
> Error detected while processing function <SNR>2_StartDebug[2]..<SNR>
> 2_StartDebug_internal[50]..<SNR>2_StartDebug_term:
> line 97:
> Cannot check if your gdb works, continuing anyway
> Press ENTER or type command to continue
>
> After a few seconds GDB starts anyway. Is there a way I can disable this error
> message?

Haven't you just created an issue for this behaviour?
https://github.com/vim/vim/issues/8163

Did you try changing the mentioned limit? Please test out what limit
works for you.


Best,
Christian
--
Wie man sein Kind nicht nennen sollte:
Rene Klode

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210502141418.GA95831%40256bit.org.

Re: Error starting :Termdebug

Uri Moszkowicz wrote:

> I get this error running vim 8.2 when starting :Termdebug:
>
> Error detected while processing function
> <SNR>2_StartDebug[2]..<SNR>2_StartDebug_internal[50]..<SNR>2_StartDebug_term:
> line 97:
> Cannot check if your gdb works, continuing anyway
> Press ENTER or type command to continue
>
> After a few seconds GDB starts anyway. Is there a way I can disable this
> error message?

The plugin wants to check what features your gdb has. I wonder why this
takes so long. Perhaps there is another gdb argument to do this
quickly?

Do you see the "Reading symbols from" message? You could change the
plugin runtime/pack/dist/opt/termdebug/plugin/termdebug.vim

" Reading symbols might take a while, try more times
let try_count -= 1

Change "1" to a large number, e.g. "100" or "1000".
Let us know if that helps.


--
hundred-and-one symptoms of being an internet addict:
216. Your pet rock leaves home.

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105021311.142DBOEX020833%40masaka.moolenaar.net.