On May 23 11:33, Charles Wilson wrote: > 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?)
Something. I don't know how mintty works, but the Cygwin console knows the "switch to/from alternate charset" command "ESC [ 11 m", "ESC [ 10 m". The alternate charset is always codepage 437 which has the line drawing chars at known single-byte positions in the >= 128 region. This is apparently used by ncurses when running in a console window, but perhaps not when running in mintty. Whatever that is, I guess it may not be overly tricky to implement in mintty as well, *if* somebody takes the time to report the problem. > 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. What is the difference to the Cygwin console exactly? I'm sure, if you look a bit below the surface, you will easily find bugs in the Cygwin console implementation as well. It's all about getting bug reports or even testcases. Just because there are bugs in mintty and the Cygwin console doesn't mean both are unusable as default terminal. > 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.) Btw., why is it so bad to have ASCII replacement chars? They just work, even if they look ugly to some people. > 2) do we need an explicit mintty terminfo entry, with a 'better' acsc > entry I don't think so. If at all, it's just some shortcoming in the current implementation, something which can be fixed or added. > 3) Maybe there is some magic combination of envvar TERM/LANG, > settings, mintty options, font choices, etc, that will make linedraw work? Windows fonts are unicode anyway, and the line drawing chars are part of the unicode codeset. I guess a translation table from CP437 to unicode line drawing chars and support of the alternate charset setting should do it. > > 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^ Huh? You can simple create a Windows shortcut to bash.exe, edit it to add a --login option, and that's all you really need. > > 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. I don't think it makes sense if the desktop shortcut and the menu entry behave differently. The desktop shortcut is the first thing new users see, and this shortcut should start mintty in the first place. Just as the menu entry since they should do the same. > > 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. I agree. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat