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 <dic...@invisible-island.net>
> 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 (0x00007ffce821e000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f3fd2e9a000)
        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f3fd2c44000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f3fd2879000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f3fd2675000)
        /lib64/ld-linux-x86-64.so.2 (0x0000562a1824f000)
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 

  ## ---------- ##
  ## 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) CPU        G6960  @ 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 (0x00007ffe84f55000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb73e805000)
        libncursesw.so.5 => /lib64/libncursesw.so.5 (0x00007fb73e59e000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb73e1d4000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fb73dfd0000)
        /lib64/ld-linux-x86-64.so.2 (0x0000564d1b97f000)

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.


vile mailing list

Reply via email to