I found mutt and yast (ncurses) also have the same symptom with gnome-terminal in SLE15 (updated to the latest code in the build service).

A similar ill-effect is seen by alsamixer invocation on xfce4-terminal, too.

I'm also seeing this with mutt in konsole: strings of repeated characters are not displaying.  And unfortunately changing TERM to "konsole" is not an ideal workaround because then key combinations like Ctrl-End stop working.

Further I can report that forcing an install of terminfo-base-5.9-57.1.x86_64 and terminfo-5.9-57.1.x86_64 from 42.3 restores the expected behaviour.

My workaround for konsole is to change TERM to "xterm-xfree86". The only side effect I noticed is the color for some types of files, such as bz2 or xz, are gone. However, all keys are still functioning at least so I don't have to modify /etc/inputrc for the key combination...

Thanks.  "xterm-xfree86" works well for me too.  If it's not too off-topic to ask: how did you know / guess this?  (I looked at the huge number of possibilities in /usr/share/terminfo/ and didn't know what to choose, but hoped "konsole" might be a safe bet.  But it didn't handle some common key combinations.)

(In reply to Roger Whittaker from comment #6)
> Thanks.  "xterm-xfree86" works well for me too.  If it's not too off-topic
> to ask: how did you know / guess this?  (I looked at the huge number of
> possibilities in /usr/share/terminfo/ and didn't know what to choose, but
> hoped "konsole" might be a safe bet.  But it didn't handle some common key
> combinations.)

I chose the "xterm" variants randomly since the xterm keys are already defined in /etc/inputrc and found xfree86 works for me.

Please do not use TERM=xterm for ksonsole nor for gnome-terminal nor for xfce4-terminal ... the terminfo variable does not reprogram a terminal nor a terminal emulator.  Even if in past it had work out incidentally it is not guaranteed taht if upstream add a missed feature of the XTerm to the terinao entry TERM=xterm that this will also be supported by the other terminal emulators.

Therefore if the XTerm works this bug becomes INVALID ... if so then please reopen this bug only if the XTerm emulator does not work.

Hence the question for all reporters: Does this bug happen within XTerm?

(In reply to Dr. Werner Fink from comment #8)
> Please do not use TERM=xterm for ksonsole nor for gnome-terminal nor for
> xfce4-terminal ... the terminfo variable does not reprogram a terminal nor a
> terminal emulator.  Even if in past it had work out incidentally it is not
> guaranteed taht if upstream add a missed feature of the XTerm to the terinao
> entry TERM=xterm that this will also be supported by the other terminal
> emulators.
> 
> Therefore if the XTerm works this bug becomes INVALID ...

Well, people (including me) didn't change anything but update terminfo package.  The TERM=xterm-256color is set as default by distribution.

Changing to a different $TERM suggested here is merely a workaround to make the terminal still working with the updated terminfo package.  It's no solution, of course.

That said, the bug is about a regression of the latest terminfo package, and this must be fixed somehow.

>  if so then please
> reopen this bug only if the XTerm emulator does not work.
> 
> Hence the question for all reporters: Does this bug happen within XTerm?

xterm seems working fine as is through a quick test.

(In reply to Dr. Werner Fink from comment #8)
> Please do not use TERM=xterm for ksonsole nor for gnome-terminal nor for
> xfce4-terminal ... the terminfo variable does not reprogram a terminal nor a
> terminal emulator.  Even if in past it had work out incidentally it is not
> guaranteed taht if upstream add a missed feature of the XTerm to the terinao
> entry TERM=xterm that this will also be supported by the other terminal
> emulators.
> 
> Therefore if the XTerm works this bug becomes INVALID ... if so then please
> reopen this bug only if the XTerm emulator does not work.
> 
> Hence the question for all reporters: Does this bug happen within XTerm?

XTerm works for me. However, as Takashi said, xterm-256color is the default TERM of the most of common used terminals, and I never changed the variable until updating terminfo. Either we modify the default TERM for each terminal and update inputrc or make xterm-256color work again, or the new tumbleweed users will keep complaining.

Please check out the latest ncurses from project Base:System e.g.

http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/x86_64/libncurses6-6.0-416.2.x86_64.rpm
 http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/x86_64/terminfo-base-6.0-416.2.x86_64.rpm

that is the libraries as well as the terminfo base.

(In reply to Dr. Werner Fink from comment #11)
> Please check out the latest ncurses from project Base:System e.g.
> 
> http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/
> x86_64/libncurses6-6.0-416.2.x86_64.rpm
>  http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/
> x86_64/terminfo-base-6.0-416.2.x86_64.rpm
> 
> that is the libraries as well as the terminfo base.

They didn't fix the problem on xfce4-terminal, at least.

I checked the old package on my system, and terminfo-base-6.0-26.1 still worked.
The top of 6.0-26.1 changelog says:
* Mon Jul 24 2017 werner@suse.de
- Add ncurses patch 20170722

And the breakage was introduced by terminfo-base-6.0-27.2, and its changelog is:
* Mon Jul 31 2017 werner@suse.de
- Add ncurses patch 20170729
....
- Modify patch ncurses-5.7-tack.dif and ncurses-6.0.dif to get
  position independent executables as well

(In reply to Takashi Iwai from comment #12)

> They didn't fix the problem on xfce4-terminal, at least.

Does it work in XTerm?

> * Mon Jul 31 2017 werner@suse.de
> - Add ncurses patch 20170729
+20170729
+       + update interix entry using tack and SFU on Windows 7 Ultimate -TD
+       + use ^? for kdch1 in interix (reported by Jonathan de Boyne Pollard)
+       + add "rep" to xterm-new, available since 1997/01/26 -TD

Guess this one and I'll not change this for one terminal not an XTerm but claiming to be an XTerm

+       + move SGR 24 and 27 from vte-2014 to vte-2012 (request by Alain
+         Williams) -TD
+       + add a check in newline_forces_scroll() in case a program moves the
+         cursor outside scrolling margins (report by Robert King).
+       + improve _nc_tparm_analyze, using that to extend the checks made by
+         tic for reporting inconsistencies between the expected number of
+         parameters for a capability and the actual.
+       + amend handling of repeat_char capability in EmitRange (adapted from
+         report/patch by Dick Wesseling):
+         + translate the character to the alternate character set when the
+           alternate character set is enabled.
+         + do not use repeat_char for characters past 255.
+       + document "_nc_free_tinfo" in manual page, because it could be used in
+         tack for memory-leak checking.
+       + add "--without-tack" configure option to refine "--with-progs"
+         configure option.  Normally tack is no longer built in-tree, but
+         a few packagers combine it during the build.  If term_entry.h is
+         installed, there is no advantage to in-tree builds.
+       + adjust configure-script to define HAVE_CURSES_DATA_BOOLNAMES symbol
+         needed for tack 1.08 when built in-tree.  Rather than relying upon
+         internal "_nc_" functions, tack now uses the boolean, number and
+         string capability name-arrays provided by ncurses and SVr4 Unix
+         curses.  It still uses term_entry.h for the definitions of the
+         extended capability arrays.
+       + add an overlooked null-pointer check in mvcur changes from 20170722

IMHO this is fixed with at least ncurses 6.0-20170916

Beside this ... this one ie a duplicate of boo#1054448 as the reason is the repeat character feature of XTerm which now is declared in terminfo entry "xterm" with ncurses 6.0-20170729 and is also usable even for wide character environment with ncurses 6.0-20170827

For the record, there are upstream bug reports about the missing REP support for konsole and gnome-terminal:
https://bugs.kde.org/show_bug.cgi?id=384620
https://bugzilla.gnome.org/show_bug.cgi?id=787701

So it will hopefully be implemented there soon.

AFAICS, xfce4-terminal uses vte too (like gnome-terminal), so should be covered as well.

Btw, I don't think "FIXED" is the correct status here (especially considering the considered-to-be duplicate boo#1054448 has been reopened), as the reported problem is *not* fixed... Should rather be "UPSTREAM" then, I suppose.
But it probably doesn't matter much anyway.

*** Bug 1057584 has been marked as a duplicate of this bug. ***

Would it be an option to revert this change in ncurses until the other terminal emulators have an implementation for REP?

OK let's summerize the broken terminals (any forgotten emulator?)

  VTE
  xfce4-terminal
  gnome-terminal
  konsole

which do not support the repeat character support of the original XTerm.
This 'rep' freture was declared in ncurses 6.0-20170729 and works since
ncurses 6.0-20170827 perfect for the orifinal XTerm.

(In reply to Dr. Werner Fink from comment #19)
> OK let's summerize the broken terminals (any forgotten emulator?)
> 
>   VTE
>   xfce4-terminal
>   gnome-terminal
>   konsole
> 
> which do not support the repeat character support of the original XTerm.
> This 'rep' freture was declared in ncurses 6.0-20170729 and works since
> ncurses 6.0-20170827 perfect for the orifinal XTerm.

That's kinda an unfair assessment, especially considering that installing the fixed ncurses on TW makes the 'rep' feature behave correctly in vte (and hence gnome-terminal);

just: that ncurses version was merged into Factory on September 20th 2017 - and no Tumbleweed snapshot contains the fix yet (which is why users do not benefit from the fix yet) - local tests on my system with the upcoming ncurses were successful.

(In reply to Dominique Leuenberger from comment #20)
> That's kinda an unfair assessment, especially considering that installing
> the fixed ncurses on TW makes the 'rep' feature behave correctly in vte (and
> hence gnome-terminal);

Really?
The upstream GNOME bug report is still open.

I think there were several independent rendering problems, let's not mix them.

This is about missing REP support AIUI, and that should not be fixed yet in vte either AFAIK.
I have to admit that I didn't try with the latest vte yet though.

(In reply to Wolfgang Bauer from comment #21)
> (In reply to Dominique Leuenberger from comment #20)
> > That's kinda an unfair assessment, especially considering that installing
> > the fixed ncurses on TW makes the 'rep' feature behave correctly in vte (and
> > hence gnome-terminal);
> 
> Really?
> The upstream GNOME bug report is still open.
> 
> I think there were several independent rendering problems, let's not mix
> them.

I followed this very bug here and the very typical thing used to show the break was 'dialog --yesno Demo 5 20'; I could either change TERM= or upgrade to the new ncurses libs which will be in snapshot 0924 - both made the rendering of the dialog work

(In reply to Dominique Leuenberger from comment #22)
> I followed this very bug here and the very typical thing used to show the
> break was 'dialog --yesno Demo 5 20'; I could either change TERM= or upgrade
> to the new ncurses libs which will be in snapshot 0924 - both made the
> rendering of the dialog work

Ok, but what about the demo mentioned in the KDE bugreport?
I.e. http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/windows.html#LETBEWINDOW

Or the shell script in bug#1054448#c39 ?
https://bugzilla.opensuse.org/attachment.cgi?id=741205

If both work fine meanwhile in vte, that's great of course.

(from Egmont Koblinger from bug boo#1054448#c65)

> Nitpicking:
> 
> The attached "shell script rep.tst" contains commands like "rep 108 0".
> 
> REP, by its nature, contains an important off by one. E.g. to print a
> character 20 times in total, you print it first and then repeat it 19 times.
> Apparently the "tput rep" command expects to receive 20 as its argument in
> this case, and subtracts one for the generated repeater escape sequence
> "\e[19b".
> 
> As a result, "tput rep 108 0" prints the letter "l" once, followed by
> "\e[-1b" as if it was a valid escape sequence to repeat it -1 times.
> 
> xterm silently swallows this, resulting in "l" appearing once. VTE's
> (gnome-terminal's) forthcoming patch will display garbage. konsole also
> displays garbage.
> 
> I don't think "rep 108 0" or its emitted escape sequence "\e[-1b" are valid
> ones and I don't think any particular behavior is expected here from
> terminal emulators.

(In reply to Wolfgang Bauer from comment #23)

> If both work fine meanwhile in vte, that's great of course.

vte has not yet fixed the issue (unless SUSE has applied the patch from the bugtracker which I don't know). The fix will appear next week in 0.50.1.

---

Here's what I figured out so far:

- xterm does _not_ properly support the REP escape sequence. Despite the standard which says it should work on all graphic characters, it only works for Latin-1 characters which is an unacceptable limitation when UTF-8 is 25 years old and all major Linux distros have defaulted to UTF-8 for like 10-12 years. As such, it's faulty to claim in terminfo that it supports (and it's important to note that ncurses is not the only piece of software relying on terminfo).

- A terminfo change in ncurses-20170729 started to claim that TERM=xterm (and some variants, including the commonly used xterm-256color) supports REP.

- Several bugs were reported to the ncurses mailing list, so it looks that ncurses did not implement REP correctly. I have not taken a thorough look at these bugreports.

- I myself have found that non-ASCII characters are treated incorrectly. If an ncurses app prints an accented character repeatedly so that ncurses starts using REP, it's only the least significant byte of the UCS4 value that's printed. This causes either invalid UTF-8 (which is then shown as the usual inverted question mark U+FFFD by terminal emulators) or a "random" ASCII character (or I'm not sure what happens if it's a control character).

- The author has also posted (if I understood correctly) something like that he's aware that REPetition of U+2500-like line drawing characters (emitted by apps linked against ncursesw and ran with NCURSES_NO_UTF8_ACS=1) is not yet solved. However, he chose to emit these the old-fashioned stateful magic way (alternate charset or what it's called) rather than omitting the repetition escape sequence. I don't know if he realized that this caused the NCURSES_NO_UTF8_ACS=1 workaround no longer properly doing what it was meant to work around.

- ncurses author claims that these bugs were fixed in the 20170827 release. Indeed I did not find any misbehavior of ncurses in this version. Tracing, however, revealed that it did _not_ emit the REP sequence at all, it just fell back to manually repeating the given character the desired amount of times. This pretty well explains how it comes that VTE suddenly magically "got fixed" whereas technically it didn't get any fix.

- I tried to report my findings but then realized I had been banned from bug-ncurses, presumably partially due to my latest polite message asking him to make it possible to denote truecolor support in terminfo (something like 2 lines of text in a text file which he repeatedly refused to add), partially due to his apparent generic inexplicable hatred towards gnome-terminal/vte and probably towards personally me as well. At this point I could have just sent these personally to him, or register a fake email address to send to the list, but I just no longer found it worth my time and calmness.

I really have no clue what's going on. I had three guesses, only two remain now:

- I missed something with the 0827 release and didn't use it properly. Now that multiple people have hit the same "issue" of the real original issue magically vanishing, I exclude this possibility;

- The author, while intended to fix bugs, did not realize that accidentally REP is no longer emitted;

- The author, seeing the bugs in his code and the problems the change caused, silently backed off without reverting the obvious xterm description in terminfo, and without acknowledging the troubles.

There might be some other reason as well, of course.

According to https://bugs.archlinux.org/task/55322 it seems to me that REP is only used in ncurses 20170827 and newer versions if an 8-bit locale is used. (I haven't verified this.)