wordgrind-0.8.1 doesn't properly redraw

[rogerxxxx]

When having multiple Xorg (and likely Wayland) windows/displays, moving away from the wordgrinder terminal window having open menus (eg. ESC) and then back again, the terminal window shows a corrupted curses/ncurses wordgrinder/menus.

This is likely caused by curses/ncurses not being used for properly redrawing the graphics, and/or the graphics being drawn incorrectly. Again, I've seen this similar with using kermit/minicom curses/ncurses draw method menu items (going from memory here and might be stating the wrong programs), and this seems to be due to the draw methods used. (eg. Linux terminal, console, ...) It really bugs me I cannot properly recall the program using curses/ncurses with a menu for select terminal draw properties, very prominently used terminal program too, however rarely used nowadays!

This might be something to be also associated with UTF-8 drawing, however I have none of these issues with any other programs using curses/ncurses here! I should probably check-out the source code repository and compile, as this might have been fixed since 0.8.1 release many years ago.

[davidgiven]

Are you using WordGrinder in a terminal, or are you using its X front end?

[rogerxxxx]

I'm also most certainly using the terminal method.

I just read about the X front-end method this morning, and this would likely draw an X window around the wordgrinder interface, with an additional pop-up X/Xorg window with properties veiwable by xprop. And would most defintely be noticeable as I'm using dwm desktop! I also was C programming with curses/ncurses, albeit more than a decade or two ago.

Void Linux distribution package only provides one bin file for wordgrinder (including a license file and man page), and there's no additional switch for starting the X version of wordgrinder. (eg. wordgrinder -h) On this note, my guess is wordgrinder might be built without the X front-end. Well self building wordgrinder here, but seems to be taking a very long time, just for kicks trying to look into the X interface specifics.

OK. I see a man page file named xwordgrinder, nope not present here and as expect, certainly not using xwordgrinder. Using wordgrinder within Xterm and GNU Screen, additionally tested wordgrinder without GNU Screen within XTerm, then additionally rxvt-unicode/urxvt terminal.

Sorry so long of a post, but just finally self-compiled and the terminal version the curses/ncurses graphics are even worse than the Void Linux pre-built package. No difference whether use the following:

$ export LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8"
$ export LANG="C.utf8" LC_ALL="C.utf8"

Now seeing the additional xwordgrinder, and xwordgrinder (curses/ncurses?) graphics appear fine. (eg. up/down arrows around text/document entry area, menu/sub-menu right arrows, ... etc.

file: /etc/locale.conf
LANG=en_US.UTF-8
LANG=C.UTF-8
LANG=en_US
LC_COLLATE=C
#LC_TIME=en_GB.UTF-8
LC_TIME=C

Using the Linux console, graphics are a little better. I'm seeing the up/down arrows within the text/document area, but only small boxes for the right arrows of the menus/sub-menus. $ locale LANG=en_US LC_CTYPE="en_US" LC_NUMERIC="en_US" LC_TIME=C LC_COLLATE=C LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_PAPER="en_US" LC_NAME="en_US" LC_ADDRESS="en_US" LC_TELEPHONE="en_US" LC_MEASUREMENT="en_US" LC_IDENTIFICATION="en_US" LC_ALL=

Within the Xorg Xterm GNU Screen console with same locales as above, I now get (likely funky comonly non-typed) question marks for all arrows.

Spawning an basic generic XTerm and urxvt/rxvt-unicode terminals from the same previous terminal, graphics are all screwed-up, the @ sign with accent replaces all curses/ncurses graphics. Certainly something is not correct here, as I do not see any glitches with any other recently used curses/ncurses program I use here!

[davidgiven]

If you're using the terminal version, then any corruption caused by moving windows around isn't WordGrinder's fault. Instead I'd try a different terminal emulator. The terminal remembers the state of the TTY and redraws it itself, rather than telling ncurses to do anything. If you want the X version, then Void Linux seems to have a wordgrinder-x11 package, which provides an xwordgrinder binary.

Regarding Unicode: it's all a bit hairy in terminals. You need a terminal which supports it, an ncurses which supports it (not all do), and a locale which supports it, and all the setup needed to chain things together. The current development version of wordgrinder has a -8 option which tells it to just use old-fashioned ISO-8859-1 characters, and is intended for systems where this is broken somehow. I do test with rxvt, urxvt, xterm etc and it does work on my system:

$ locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

[rogerxxxx]

SOLUTION / FIX / WORKAROUND

I've had no problems with any other curses/ncurses applications, except namely this one wordgrinder. I'm guessing, most applications/programs likely avoid using curses/ncurses characters/graphics only provided by unicode/UTF fonts/characters. As to why I rarely, if ever see any problems with any other curses/ncurses console programs. Guessing, the unicode/UTF arrow codes only are provided by unicode/UTF fonts.

1) Regenerated locales, or use locale-gen on other Linux distributions

# xbps-reconfigure -f glibc-locales
glibc-locales: configuring ...                                                                                                                                           
Generating GNU libc locales...                                                                                                                                           
  C.UTF-8... done.                                                                                                                                                       
  en_US.UTF-8... done.                                                                                                                                                   
  en_US.ISO-8859-1... done.                                                                                                                                              
glibc-locales: configured successfully.                                                                                                                                  

0 ;-)

2) Ensure /etc/locales.conf contains correct values, and LC_CTYPE is set to a capable unicode/UTF character set! For this display anomaly, I see an accented @ character instead of the arrow unicode/UTF character. Use "en_US.UTF-8", and not just "en_US"

$ export LC_CTYPE="en_US.UTF-8"

3) Start xterm or urxvt without Bash aliases:

$ /usr/bin/xterm

Or

$ /usr/bin/urxvt

4) Also make sure xterm/urxvt are not using a Bitmap/PCF font. (eg. -fn -adobe-courier-medium-r-normal--24-240-75-75-m-150-iso10646-1) For this display anomaly, I see a dotted box character instead of the arrow unicode/UTF character.

5) The final solution, when using Bitmap/PCF fonts or working within a non-UTF/unicode environment, use "-8" option for ASCII or bitmap fonts. (eg. wordgrinder -8)

All of a sudden, things changed. I'm more so looking at one of the locale variables causing havoc. Prior to this, /usr/bin/xterm or /usr/bin/urxvt curses/ncurses graphics were still mangled, so likely not the Bash aliases.

One thing I now notice, within my /etc/locale.conf on this system, looks like something is mangling my /etc/locale.conf file and adding extra LANG variable definitions. I doubt that's the problem, more so looking at one of the other variable locale definitions just using C or en_US. This is certainly weird. I'll likely figure it out by the end of the day, or so!

[rogerxxxx]

My operating system's available locales.

$ locale -a
C
C.utf8
POSIX
en_US
en_US.iso88591
en_US.utf8

Which locales work and don't work with wordgrinder.

Locale LC_ALL="C" fails
Locale LC_ALL="C.utf8" works
Locale LC_ALL="POSIX" fails
Locale LC_ALL="en_US" fails
Locale LC_ALL="en_US.iso88591" fails
Locale LC_ALL="en_US.UTF-8" works

Looks like C, en_US, POSIX are symbolic links to en_US.iso88591 or reference ASCII. From a user perspective, this seems very elusive. If C, en_US, and POSIX are aliases of iso88591, should be C.iso88591, POSIX.iso88591, ... I'm probably describing this all screwed-up as some of this tends to get to be like spaghetti without further understanding or being a locale expert.

I also cannot isolate the specific LC variable causing the display corruption (due to LC only being writable by LC_ALL, unless using /etc/locale.conf), could be just one or could be all of them. (eg. LC_ALL)

Personally, my bias here, I've always disliked UTF due to non-commonly or not-easily typed characters being used as filenames, along with UTF's horrid sorting. So sorting (LCCOLLATE) would resort to C/POSIX, as well as a few other custom LC variables for preventing unusual not readily usable filenames via command line console. One of the easiest methods for averting the UTF/unicode mess, was setting /etc/rc.conf to ascii rather than unicode and was likely stripped/removed a few years ago on Void Linux.

So the description I posted within my last post, is likely the method users' should use for tracking down console curses/ncurses anomalies; with the problem being either with a forgotten Bash alias for their terminal, or more specifically, locales needing regenerating and/or locale LC_ variables needing UTF-8 for wordgrinder's usage of UTF/unicode characters.

Now, to try to figure-out why I cannot for the life of me, why I cannot change any specific LC variable without having to reboot! I export a specific LC variable (eg. LCCOLLATE="POSIX") and the variable does not get written even as root! Almost as if LC variables can nolonger be changed unless using LC_ALL or rebooting, allowing the main init system, runit in my case, sysvinit/openrc/systemd for others.

After much research, can only guess one (or maybe all) of the following require UTF for wordgrinder when expecting UTF environment:

LC_CTYPE
LC_MESSAGES
LC_IDENTIFICATION

[rogerxxxx]

Think I also may have figured-out why I cannot set a specific LC_ variable, once LCALL is used, makes LC* individiaul variables possibly not settable by either root or user. Weird.

I've updated my fix/workaround/solution post to also include using xterm/urxvt with a bitmap/pcf font will inhibit a non-UTF/unicode capable font, noting wordgrinder -8 option clears this hurdle with bitmap/pcf fonts.

Verified, Just the or only the LCCTYPE needs unicode/UTF character set. All other locale LANG or LC variables can be non-unicode/UTF. Will add to the previous fix/workaround/solution post.