Re: It appears the terminal bell doesn't work with our definition of wsvt25?, is that right?

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	Hello.  Thank you for the followup.  The issue is more nuanced than I
originally proposed.  
If I log into two of my NetBSD/amd64 10.99.12 machines from an old
NetBSD-5.2 laptop I use, my terminal type is set to vt220.  In that case,
tput bl or tput bel rings the bell.  However, entering vi and hitting
escape multiple times results in no bell, even though noflash is set to
true.  Also, infocmp -1 |grep -i 'bel' shows ^G, as expected.
If I setenv TERM vt100, however, vi behaves as expected. That is, pressing
the escape key multiple times results in bell sounds.
So, there must be some interaction between the terminal handling code in
vi and the way the 
bell is  activated.  
Below are two trace snippets from vi which show the difference.
The first snippet shows what happens when the bell sounds after an escape
is pressed.  The second shows what  happens when the bell doesn't sound
after an escape is pressed. 
The only difference between the two sessions is the setting of the TERM
variable.
Thoughts?

<working bell trace>
  8650   8650 vi       CALL  read(0,0x7d5f7e5df000,0xff)
  8650   8650 vi       GIO   fd 0 read 1 bytes
       "\^["
  8650   8650 vi       RET   read 1
  8650   8650 vi       CALL  __select50(1,0x7f7fff2264e0,0,0,0x7f7fff2264d0)
  8650   8650 vi       RET   __select50 0
  8650   8650 vi       CALL  write(1,0x7d5f7e5ac000,1)
  8650   8650 vi       GIO   fd 1 wrote 1 bytes
       "\a"
  8650   8650 vi       RET   write 1


<Non-working bell trace>
  6800   6800 vi       GIO   fd 0 read 1 bytes
       "\^["
  6800   6800 vi       RET   read 1
  6800   6800 vi       CALL  __select50(1,0x7f7fff04b6e0,0,0,0x7f7fff04b6d0)
  6800   6800 vi       RET   __select50 0
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "\^["
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "["
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "?"
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "5"
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "h"
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "\0"
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes

. . . Followed by a bunch more null bytes ...



  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "\^["
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "["
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "?"
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "5"
  6800   6800 vi       RET   write 1
  6800   6800 vi       CALL  write(1,0x7c4429ec8000,1)
  6800   6800 vi       GIO   fd 1 wrote 1 bytes
       "l"
  6800   6800 vi       RET   write 1