On Fri, Sep 16, 2016 at 05:27:21PM -0400, Thomas Dickey wrote:
> On Fri, Sep 16, 2016 at 03:48:46PM -0400, Wayne Cuddy wrote:
> > When vile is linked against ncursesw, version 5.9 64-bit in this case, it
> > chews up the CPU when highlighting is enabled.
>
> In a quick check with my Debian7, I don't see a problem.
> (I used the CHANGES file as something to highlight).
>
> > I don't need to link with ncursesw it's just something that I figured
> > should work since it's noted to be compatible.
> >
> > Let me know if there's any other information I can provide.
>
> well...
>
> a) which system are you running on (so I can check the package)?
> b) what's your .vilerc look like?
> c) can you reproduce this with a small text file?
>
> --
> Thomas E. Dickey
> http://invisible-island.net
> ftp://invisible-island.net
a) I discovered it on a Slackware 14.1 VM running a 4.6 kernel. I
built 9.8r without any custom patches. Here is the head of config.log:
~~
It was created by configure, which was
generated by GNU Autoconf 2.52.20150926. Invocation command line was
$ ./configure --with-screen=ncursesw --disable-stripping
## -- ##
## Platform. ##
## -- ##
hostname = slackjaw
uname -m = x86_64
uname -r = 4.6.5-x86_64-linode71
uname -s = Linux
uname -v = #2 SMP Fri Jul 29 16:16:25 EDT 2016
/usr/bin/uname -p = Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
/bin/uname -X = unknown
/bin/arch = x86_64
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
> ldd /usr/local/bin/vile
linux-vdso.so.1 (0x7ffce821e000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f3fd2e9a000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x7f3fd2c44000)
libc.so.6 => /lib64/libc.so.6 (0x7f3fd2879000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f3fd2675000)
/lib64/ld-linux-x86-64.so.2 (0x562a1824f000)
~~
I was also able to reproduce on bare metal Slackware 14.2 with the
same build process. The only real difference is the kernel version.
$ ./configure --with-screen=ncursesw --disable-stripping
--prefix=/home/wcuddy/vile
## -- ##
## Platform. ##
## -- ##
hostname = wcuddy
uname -m = x86_64
uname -r = 4.4.14
uname -s = Linux
uname -v = #1 SMP Fri Jun 24 13:30:15 CDT 2016
/usr/bin/uname -p = Intel(R) Pentium(R) CPUG6960 @ 2.93GHz
/bin/uname -X = unknown
/bin/arch = x86_64
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
>ldd vile
linux-vdso.so.1 (0x7ffe84f55000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7fb73e805000)
libncursesw.so.5 => /lib64/libncursesw.so.5 (0x7fb73e59e000)
libc.so.6 => /lib64/libc.so.6 (0x7fb73e1d4000)
libdl.so.2 => /lib64/libdl.so.2 (0x7fb73dfd)
/lib64/ld-linux-x86-64.so.2 (0x564d1b97f000)
~~
b) Using this minimalist vilerc file the problem occurs:
set autoindent
set backup-style=tilde
set dos
set fillcol=72
set ignorecase
set implybuffer
set linewrap
set pin-tagstack
set nobackspacelimit
set nospaces-after-sentence
set notabinsert
set modeline
set ruler
set shiftwidth=4
set showmatch
set tabstop=4
set visual-matches=reverse
set identifier-expr=\\w\\+[\\w:-]\\+
map g 1G
map #i :set ic
map #I :set noic
bind-key help #1
bind-key cntl_a-prefix ^C
bind-key undo-changes-backward u
bind-key redo-changes-forward U
bind-key historical-buffer-to-current-window -
bind-key split-current-window ^T ; split into 'T'wo windows
bind-key next-window ^N ; 'N'ext window
bind-key next-window ^I ; bind tab to next-window
bind-key previous-window ^P ; 'P'revious window
; enable buffer autocoloring
source "filters.rc"
source "palettes.rc"
setv $autocolor-hook HighlightFilterMsg
setv $read-hook HighlightFilterMsg
set autocolor=1000
~~
c) The problem occurs editing the vilerc file from answer "b". So
yes, it will happen with a very small file.
In fact my initial analysis was slightly off. I don't even need to
edit a highlighted file. If I simply start vile, enter insert mode and
then enter any key that changes the buffer content. So inserting a
space will be cycling the CPU... almost as if waiting for the next key
event is done in a tight loop. The value of autocolor doesn't matter
even if I set it to some enormous value.
~~
Wayne
___
vile mailing list
vile@nongnu.org
https://lists.nongnu.org/mailman/listinfo/vile
