On 5/23/2011 7:50 AM, Corinna Vinschen wrote: > On May 20 17:09, Yaakov (Cygwin/X) wrote: >> The setup.exe download is still 2.738. Could it be updated to 2.749 >> to include jturney's recent bug fixes? > > I'd like to fix the mintty issue first. > > So, do we swtch to mintty as default terminal, yes or no?
Uhm, maybe? :-) Here's the deal: run the following program from the ncurses-demo package: /usr/lib/ncurses/test/lrtest.exe in a mintty terminal and bash-in-cmdbox, with the same UTF-8 $LANG settings (I've tried C.UTF-8 and en_US.UTF-8). FWIW, TERM=xterm-256color in mintty, and TERM=cygwin in bash-in-cmdbox. In the former, I see pseudo-line drawing characters (e.g hyphens and plus signs, etc), but in the latter I see real line draw characters. Why? I suspect the reason is the terminfo settings for mintty (e.g. for xterm-256color) specifies acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, (inherited via terminfo 'use' statements from xterm-basic), while the terminfo settings for cygwin specify acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376, e.g. the cygwin entry explicitly uses high codepoints for various line draw stuff, (and cgywin's own terminal handling code does the magic to replace them with unicode linedraw? or something?) Now, according to a post from 2004 by T.E. Dickey (ncurses/terminfo maintainer): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256446 non-wide ncurses relies on the acsc, wide-curses has a kludge to recognize UTF-8 locales and an internal table for line-drawing characters. ...which also has a suggested patch for putty, but it's not clear it was ever adopted. So...trying the wide variant /usr/lib/ncursesw/test/lrtest.exe I get the same behavior as before in mintty (e.g. no linedraw chars)...so there goes that idea (maybe the 'kludge' has been removed from libncursesw between 2004 and now). My point: there are some things that don't yet seem to work "right" in mintty, and I'm not really sure where the problem is. 1) does mintty need to do magic linedraw character rewriting, replacing what APPEAR to be attempts to print line draw chars with unicode linedraw glyphs? (ugh. heuristics. I hate heuristics. They always guess wrong sometimes.) 2) do we need an explicit mintty terminfo entry, with a 'better' acsc entry -- OTOH, it is *NOT* possible to put unicode values in the terminfo src string, so that's probably a nonstarter, unless combined with (1). (also: ugh. must propagate the entry to all server OSs to which you want to ssh...push upstream to ncurses...wait years for RHEL7.0 to adopt it...) 3) Maybe there is some magic combination of envvar TERM/LANG, settings, mintty options, font choices, etc, that will make linedraw work? 4) bug (or misconfiguration) in cygwin ncurses- or ncursesw- ? 5) or punt. Who needs linedraw anyway. I'm ok with #5...but just wanted to bring up the issue so the decision is an informed one. > If we switch to mintty we don't need the Cygwin.bat file anymore. But, > shouldn't we keep it anyway for people who maintain some handmade symlink > to it? yes. > If so, should we stick to the content of Cygwin.bat as is, or should > we change it to call mintty, too? as-is. What if you really WANT to use cmdbox? How else can a cygwin-shell-in-cmdbox be started, other than a .bat file of some kind? And since that's the only real way to do so, we ought to provide the file. > And who's going to create the patches? Well, my proposal is a one-liner in setup.exe: just change the target of the shortcut created in the Start Menu. > Last but not least, shouldn't we add mintty to the Base package > anyway, independently of what we do to setup? I think so. However, if we do change setup.exe, then mintty should later be updated to eliminate its postinstall/preremove scripts. We don't need TWO shortcuts to the same proggie. -- Chuck