Re: Cygwin Digest, Vol 13, Issue 22

[Thomas Dickey]

> Date: Sun, 7 Mar 2021 15:05:55 + (UTC)
> From: Mike Gran 
> To: "cygwin@cygwin.com" 
> Subject: mingw.org may be dead, but is referenced in cygwin docs
> 
> Hello Cygwin-
> I was reading the webpage "Building and Using DLLs".
> That page suggests looking at mingw.org for more information.
> mingw.org is no more. I don't know when or if it will return.
> Thanks,
> Michael

https://osdn.net/projects/mingw/

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file

[Thomas Dickey]

- Original Message -
| From: "Åke Rehnman" 
| To: "cygwin" 
| Sent: Wednesday, March 11, 2020 4:48:05 PM
| Subject: Setting termios VMIN > 0 and VTIME > 0 on non blocking file

| Hello all,
| 
| opening a file (serial port) with O_NONBLOCK and subsequently setting
| termios VMIN and VTIME > 0 makes read() never ever return any data
| (returns EAGAIN indefinitely).
| 
| Don't ask my why one would want to do something like this but apparently
| the "screen" program think this is a good way of doing things...
| 
| Nevertheless not returning any data ever seems wrong.
| 
| Any insight on how it is supposed to work is welcome.

If not "correct", it's certainly inconsistent with all other systems.
I noticed it recently:

https://invisible-island.net/ncurses/tack/CHANGES.html#t20200220

https://github.com/cygwinports/tack/issues/1

It's either recently-broken, or just coincidence :-)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: XTerm(331)?

[Thomas Dickey]

- Original Message -
| From: "Jim Reisert AD1C" 
| To: "cygwin" 
| Sent: Wednesday, September 11, 2019 10:26:56 AM
| Subject: XTerm(331)?

| Can someone please update the Cygwin XTerm?  The current version is
| (330) but I understand (331) is out there, at least in Fedora:
| 
| [JJR:~] $ xterm -version
| XTerm(330)
| 
| https://bugzilla.redhat.com/show_bug.cgi?id=1534475
| 
| "xterm-331-1.fc27 has been pushed to the Fedora 27 stable repository.
| If problems still persist, please make note of it in this bug report."
| 
| This was posted in June of 2018!

...and took 6 months (since 2017/12/30) for Redhat's packager to notice:

https://invisible-island.net/xterm/xterm.log.html#xterm_331

patch #348 is current (2019/07/22)

https://invisible-island.net/xterm/xterm.log.html#xterm_348

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: *cause of* screen writing over restored buffer on detach/exit

[Thomas Dickey]

- Original Message -
| From: "Thomas Dickey" 
| To: "Thomas Wolff" 
| Cc: "cygwin" 
| Sent: Thursday, April 11, 2019 7:06:22 PM
| Subject: Re: *cause of* screen writing over restored buffer on detach/exit

| - Original Message -
|| From: "Thomas Wolff" 
|| To: "cygwin" 
|| Sent: Wednesday, April 10, 2019 5:51:34 PM
|| Subject: Re: *cause of* screen writing over restored buffer on detach/exit
| 
|| Hi Thomas,
|| 
|| Thomas Dickey wrote:
||> - Original Message -
||> | From: "Shaddy Baddah" 
||> | To: "cygwin" 
||> | Sent: Tuesday, April 9, 2019 11:18:19 PM
||> | Subject: Re: *cause of* screen writing over restored buffer on detach/exit
||>
||> | On 9/4/19 4:07 pm, Shaddy Baddah wrote:
||> |>
||> |> This helped with screen when using Putty to a Cygwin ssh session. For
||> |> some reason, it isn't helping for running screen locally in a mintty
||> |> session. And it's not mintty either, because I can ssh to a Debian
||> |> stretch server within mintty and I can use its screen without this
||> |> issue happening. Back to the drawing board for me.
||> |
||> | I understand the cause of the issue now, by capturing and comparing the
||> | escape characters used to control the terminal by screen on Cygwin and
||> | Debian.
||> |
||> | It is not so much the detach/exit is the issue, although the escape
||> | sequence for Cygwin includes a couple of extra xterm OSC Set Text
||> | Parameters -> Change Icon Name and Window Title outputs. I misdiagnosed
||> | this somehow. I can suppress the extra utmp error one of these OSC
||> | outputs, but it didn't/doesn't really make a difference.
||> |
||> | The issue is in the escape sequences sent to the terminal by Cygwin
||> | screen to switch to new windows buffer, as compared to Debian.
||> |
||> | Debian uses xterm sequence DECSET / ESC[?1049h in the switch to the new
||> | window. Cygwin uses the two sequences ESC7 / Save Cursor (DECSC) and
||> | ESC[?47l / DEC Private Mode Reset (DECRST) -> Use Normal Screen Buffer.
||> |
||> |
||> | The reason seems to be that the Debian screen package packages a custom
||> | /etc/screenrc that does not include this explicit term capability:
||> |
||> |
||> | #
||> | # Do not use xterms alternate window buffer.
||> | # This one would not add lines to the scrollback buffer.
||> | termcap xterm|xterms|xs ti=\E7\E[?47l
||> | terminfo xterm|xterms|xs ti=\E7\E[?47l
||> |
||> |
||> |
||> | If I comment these out, my screen issue is resolved.
||> |
||> | I'm not suggesting this is a problem with Cygwin screen... it is using
||> | the upstream settings. In fact, I am not confident to say where the
||> | fault lies. Perhaps screen is right to use these sequences, but the
||> | xterms used (putty and mintty) aren't doing the right thing?
||>
||> yes - that's one of a half-dozen cases where PuTTY has never matched xterm's
||> behavior.
|| I've tested the CSI?1049h and CSI?1049l pair on xterm, pterm, mintty and
|| see no difference. In what way would it not match? And what are the
| 
| I mentioned it here:
| 
| 
https://stackoverflow.com/questions/24613237/terminal-retains-bg-color-after-closing-vim-using-color-scheme-and-putty-256co/37869114#37869114
| 
|| cases, do you have a list?
| 
| no - I've a few notes which aren't incorporated into the terminal description
| 
| https://invisible-island.net/ncurses/terminfo.src.html#tic-putty
| 
| offhand, there's differences in wrapping, as well as how modifiers affect
| cursor-keys.

...though now that I'm reading it, that one deals with color.
(I do have a note about cursor-position problems with the interim 1047/1048,
but suppose PuttY doesn't do that).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: *cause of* screen writing over restored buffer on detach/exit

[Thomas Dickey]

- Original Message -
| From: "Thomas Wolff" 
| To: "cygwin" 
| Sent: Wednesday, April 10, 2019 5:51:34 PM
| Subject: Re: *cause of* screen writing over restored buffer on detach/exit

| Hi Thomas,
| 
| Thomas Dickey wrote:
|> - Original Message -
|> | From: "Shaddy Baddah" 
|> | To: "cygwin" 
|> | Sent: Tuesday, April 9, 2019 11:18:19 PM
|> | Subject: Re: *cause of* screen writing over restored buffer on detach/exit
|>
|> | On 9/4/19 4:07 pm, Shaddy Baddah wrote:
|> |>
|> |> This helped with screen when using Putty to a Cygwin ssh session. For
|> |> some reason, it isn't helping for running screen locally in a mintty
|> |> session. And it's not mintty either, because I can ssh to a Debian
|> |> stretch server within mintty and I can use its screen without this
|> |> issue happening. Back to the drawing board for me.
|> |
|> | I understand the cause of the issue now, by capturing and comparing the
|> | escape characters used to control the terminal by screen on Cygwin and
|> | Debian.
|> |
|> | It is not so much the detach/exit is the issue, although the escape
|> | sequence for Cygwin includes a couple of extra xterm OSC Set Text
|> | Parameters -> Change Icon Name and Window Title outputs. I misdiagnosed
|> | this somehow. I can suppress the extra utmp error one of these OSC
|> | outputs, but it didn't/doesn't really make a difference.
|> |
|> | The issue is in the escape sequences sent to the terminal by Cygwin
|> | screen to switch to new windows buffer, as compared to Debian.
|> |
|> | Debian uses xterm sequence DECSET / ESC[?1049h in the switch to the new
|> | window. Cygwin uses the two sequences ESC7 / Save Cursor (DECSC) and
|> | ESC[?47l / DEC Private Mode Reset (DECRST) -> Use Normal Screen Buffer.
|> |
|> |
|> | The reason seems to be that the Debian screen package packages a custom
|> | /etc/screenrc that does not include this explicit term capability:
|> |
|> |
|> | #
|> | # Do not use xterms alternate window buffer.
|> | # This one would not add lines to the scrollback buffer.
|> | termcap xterm|xterms|xs ti=\E7\E[?47l
|> | terminfo xterm|xterms|xs ti=\E7\E[?47l
|> |
|> |
|> |
|> | If I comment these out, my screen issue is resolved.
|> |
|> | I'm not suggesting this is a problem with Cygwin screen... it is using
|> | the upstream settings. In fact, I am not confident to say where the
|> | fault lies. Perhaps screen is right to use these sequences, but the
|> | xterms used (putty and mintty) aren't doing the right thing?
|>
|> yes - that's one of a half-dozen cases where PuTTY has never matched xterm's
|> behavior.
| I've tested the CSI?1049h and CSI?1049l pair on xterm, pterm, mintty and
| see no difference. In what way would it not match? And what are the

I mentioned it here:

https://stackoverflow.com/questions/24613237/terminal-retains-bg-color-after-closing-vim-using-color-scheme-and-putty-256co/37869114#37869114

| cases, do you have a list?

no - I've a few notes which aren't incorporated into the terminal description

https://invisible-island.net/ncurses/terminfo.src.html#tic-putty

offhand, there's differences in wrapping, as well as how modifiers affect 
cursor-keys.

| Thanks
| Thomas

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: *cause of* screen writing over restored buffer on detach/exit

[Thomas Dickey]

- Original Message -
| From: "Shaddy Baddah" 
| To: "cygwin" 
| Sent: Tuesday, April 9, 2019 11:18:19 PM
| Subject: Re: *cause of* screen writing over restored buffer on detach/exit

| On 9/4/19 4:07 pm, Shaddy Baddah wrote:
|> 
|> This helped with screen when using Putty to a Cygwin ssh session. For
|> some reason, it isn't helping for running screen locally in a mintty
|> session. And it's not mintty either, because I can ssh to a Debian
|> stretch server within mintty and I can use its screen without this
|> issue happening. Back to the drawing board for me.
| 
| I understand the cause of the issue now, by capturing and comparing the
| escape characters used to control the terminal by screen on Cygwin and
| Debian.
| 
| It is not so much the detach/exit is the issue, although the escape
| sequence for Cygwin includes a couple of extra xterm OSC Set Text
| Parameters -> Change Icon Name and Window Title outputs. I misdiagnosed
| this somehow. I can suppress the extra utmp error one of these OSC
| outputs, but it didn't/doesn't really make a difference.
| 
| The issue is in the escape sequences sent to the terminal by Cygwin
| screen to switch to new windows buffer, as compared to Debian.
| 
| Debian uses xterm sequence DECSET / ESC[?1049h in the switch to the new
| window. Cygwin uses the two sequences ESC7 / Save Cursor (DECSC) and
| ESC[?47l / DEC Private Mode Reset (DECRST) -> Use Normal Screen Buffer.
| 
| 
| The reason seems to be that the Debian screen package packages a custom
| /etc/screenrc that does not include this explicit term capability:
| 
| 
| #
| # Do not use xterms alternate window buffer.
| # This one would not add lines to the scrollback buffer.
| termcap xterm|xterms|xs ti=\E7\E[?47l
| terminfo xterm|xterms|xs ti=\E7\E[?47l
| 
| 
| 
| If I comment these out, my screen issue is resolved.
| 
| I'm not suggesting this is a problem with Cygwin screen... it is using
| the upstream settings. In fact, I am not confident to say where the
| fault lies. Perhaps screen is right to use these sequences, but the
| xterms used (putty and mintty) aren't doing the right thing?

yes - that's one of a half-dozen cases where PuTTY has never matched xterm's 
behavior.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: XWin: Tiny fonts on high resolution display

[Thomas Dickey]

- Original Message -
| From: "Ken Brown" 
| To: "Thomas Dickey" 
| Cc: "cygwin" 
| Sent: Friday, September 28, 2018 10:25:17 PM
| Subject: Re: XWin: Tiny fonts on high resolution display

| On 9/28/2018 8:06 PM, Thomas Dickey wrote:
|> - Original Message -
|> | From: "Ken Brown" 
|> | To: "cygwin" 
|> | Sent: Friday, September 28, 2018 6:32:25 PM
|> | Subject: XWin: Tiny fonts on high resolution display
|> 
|> | A Google search shows that this is a very frequently asked question (e.g.,
|> | https://sourceware.org/ml/cygwin/2016-07/msg00247.html), but I haven't 
found a
|> | good answer, except perhaps to use Gnome or some other desktop 
environment.  (I
|> | haven't tried that yet.)
|> |
|> | I just got a new laptop with a 3840x2160 display.  When I start the X 
server via
|> | startxwin, xterm and emacs open small windows with tiny fonts.  Here are 
the
|> | xterm and emacs settings in my .Xresources:
|> 
|> But none of those are for fonts.  With bitmap fonts, you generally can use 
10x20
|> (12x24 is not so good).  Otherwise, your choice would be a TrueType font 
(which
|> generally have poor coverage of Unicode -- a problem since xterm loads only 
one
|> font).
|> If you don't need to read CJKV, that's okay though...
|> 
|> With TrueType fonts, you can scale it:
|> 
|> 
https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:faceSize
| 
| Thanks.  The 10x20 font was still too small, but I was able to get a 
reasonable
| xterm by adding
| 
|   XTerm*faceName: Lucida Console
|   XTerm*faceSize: 24
| 
| to .Xresources.  The only remaining problem is that the menus are still tiny. 
 I
| saw https://invisible-island.net/xterm/xterm.faq.html#tiny_menus, so I changed
| 'XTerm*geometry:  80x45' to 'XTerm.VT100.geometry:  80x45'.  But that didn't
| help.  Do you know how I can fix the menu fonts?

well, you cannot fix those using TrueType fonts, but since those use only ASCII,
the poor coverage for 12x24 (the largest bitmap font that I recall) would not
be a problem.

(I can work out a suitable resource pattern for that, if you need it).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: XWin: Tiny fonts on high resolution display

[Thomas Dickey]

- Original Message -
| From: "Ken Brown" 
| To: "cygwin" 
| Sent: Friday, September 28, 2018 6:32:25 PM
| Subject: XWin: Tiny fonts on high resolution display

| A Google search shows that this is a very frequently asked question (e.g.,
| https://sourceware.org/ml/cygwin/2016-07/msg00247.html), but I haven't found a
| good answer, except perhaps to use Gnome or some other desktop environment.  
(I
| haven't tried that yet.)
| 
| I just got a new laptop with a 3840x2160 display.  When I start the X server 
via
| startxwin, xterm and emacs open small windows with tiny fonts.  Here are the
| xterm and emacs settings in my .Xresources:

But none of those are for fonts.  With bitmap fonts, you generally can use 10x20
(12x24 is not so good).  Otherwise, your choice would be a TrueType font (which
generally have poor coverage of Unicode -- a problem since xterm loads only one 
font).
If you don't need to read CJKV, that's okay though...

With TrueType fonts, you can scale it:

https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:faceSize

| 
| emacs.geometry: 80x34+340+40
| XTerm*geometry:  80x45
| XTerm*VT100*colorBDMode:  on
| XTerm*VT100*colorBD:  blue
| XTerm.VT100*colorULMode:  on
| XTerm.VT100*underLine:  off
| XTerm*VT100*colorUL:  magenta
| XTerm*scrollBar:  true
| XTerm*rightScrollBar:  true
| XTerm*saveLines:  1
| XTerm*metaSendsEscape: true
| 
| I'm attaching my cygcheck output and XWin log.
| 
| Thanks in advance for any suggestions.
| 
| Ken

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Re: "xterm -fn '...' automatically switches to an unavailable font

[Thomas Dickey]

- Original Message -
| From: "Siegmar Gross" 
| To: cygwin@cygwin.com
| Sent: Tuesday, September 26, 2017 6:09:23 AM
| Subject: "xterm -fn '...' automatically switches to an unavailable font
| 
| Hi,
| 
| I've updated my system to the latest package versions and I use
| Cygwin x86_64 on top of Windows 10. Unfortunately, I get some
| warnings when a start "xterm".
| 
| hermes fd1026_2 40 xlsfonts | grep --
| "-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso10646-1"
| -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso10646-1
| 
| hermes fd1026_2 41 xterm -fn
| '-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso10646-1'
| xterm: cannot load font
| "-Misc-Fixed-medium-R-*-*-15-140-75-75-C-180-ISO10646-1"
| xterm: cannot load font
| "-Misc-Fixed-bold-R-*-*-15-140-75-75-C-180-ISO10646-1"
| 
| hermes fd1026_2 42 xterm
| xterm: cannot load font
| "-Misc-Fixed-medium-R-*-*-15-140-75-75-C-180-ISO10646-1"
| xterm: cannot load font
| "-Misc-Fixed-bold-R-*-*-15-140-75-75-C-180-ISO10646-1"
| xterm: cannot load font
| "-Misc-Fixed-bold-R-*-*-13-120-75-75-C-120-ISO10646-1"
| 
| Does anybody know why the 11th field will be automatically switched from
| "90" to "180"? Is it possible to avoid the warning? Thank you very much for
| any help in advance.

It's a misleading warning (xterm was marking it internally as a problem, but
when I reorganized things the "internal" status was lost - will fix in the next
update).  You can stifle the warning by setting the fontWarnings resource to 0,
as shown in the manual:

https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:fontWarnings


-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: XTerm always gives out an error message concerning a font

[Thomas Dickey]

- Original Message -
| From: "Wouter van Doorn" 
| To: "Brian Inglis" , cygwin@cygwin.com
| Sent: Thursday, July 6, 2017 5:31:42 PM
| Subject: Re: XTerm always gives out an error message concerning a font
| 
| No luck with either of the fixed-medium suggestions. The one you
| mentioned as default first match on your system is the one I get it
| moaning about no matter what I do.
| 
| The easiest solution (of sorts) might be to go back to xterm patch
| 326, but I don't know how to do that either. The installer won't go
| back further than 329. Or is that mirror-dependent, maybe? Is there a
| mirror that goes back further than the sargasso uk one I have
| selected?
| 
| Any pointers will be appreciated. BTW: it seems rather unlikely that
| I'm the only one to have this problemette?

It depends on configuration.  Rather than being a "new bug", it seems
that fixes to make the warnings more consistent made these appear (for
you at least).  If I recompile #326 with the debugging trace, it shows
the problem.

The warnings are because the derived font-names for double-width (-fw)
fonts aren't loadable.  I wouldn't notice this with my Debian machines
for instance because the fontpath includes the ":unscaled" feature,
which allows the bitmap fonts to be scaled.

https://www.commandlinux.com/man-page/man1/Xserver.1.html

Comparing configuration, I see that cygwin has something like that,
but the feature isn't working.

You can turn the font-warnings off using a resource setting.

http://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:fontWarnings

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: xterm 327-1 to 329-1 needs font dependency

[Thomas Dickey]

On Mon, Jun 26, 2017 at 01:18:52AM -0700, Bryan Dongray wrote:
> On 06/21/2017 01:22 AM, Thomas Dickey wrote:
> > - Original Message -
> > | From: "Bryan Dongray" <cyg...@dongrays.com>
> > | To: cygwin@cygwin.com
> > | Sent: Tuesday, June 20, 2017 6:52:38 PM
> > | Subject: xterm 327-1 to 329-1 needs font dependency
> > | 
> > | On an upgrade of xterm from 327-1 to 329-1 starting an xterm now
> > | complains:
> > |   $ xterm
> > |   /usr/bin/xterm: cannot load font
> > |   "-Misc-Fixed-bold-R-*-*-10-100-75-75-C-60-ISO8859-1"
> > |   /usr/bin/xterm: cannot load font
> > |   "-Misc-Fixed-medium-R-*-*-10-100-75-75-C-120-ISO10646-1"
> > |   /usr/bin/xterm: cannot load font
> > |   "-Misc-Fixed-bold-R-*-*-10-100-75-75-C-120-ISO10646-1"
> > | 
> > | When I downgrade to 327-1 these messages do not show, so I assume the
> > | latest version requires specific fonts.

no - there's no new font requirements.  xterm has (for a long time)
provided a way to infer what bold font would correspond to the normal
fonts if there's no bold-font resource setting.  One of the changes
in #328 omitted a step in that process, making it fail to see that
a bold font was specified.  The warnings have been there for a few
years.  You simply got extra warnings due to the bug.

As far as I know, #330 fixes that issue.

> > | 
> > | I installed all the X11 fonts which were described as "core font"
> > | (surprisingly a reinstall of "xinit" did not install these),
> > | but still I get the above messages. However I assume xterm falls back
> > | on
> > | some other font, as everything displays ok (as far as I checked).
> > | 
> > | Q1. Can someone point me at which font I need to install to not get
> > | these
> > |   warnings (I tried a few, but no luck, and there are hundreds to
> > |   try)?
> > | 
> > | Q2. Shouldn't these fonts be a dependency of xterm?

Some packagers don't think so.

The ones that are used by default are the xorg "misc" fonts (though I don't
recall what the package name in cygwin is -- package names for X fonts differ
in every system that I've seen).

-- 
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: xterm 327-1 to 329-1 needs font dependency

[Thomas Dickey]

- Original Message -
| From: "Bryan Dongray" 
| To: cygwin@cygwin.com
| Sent: Tuesday, June 20, 2017 6:52:38 PM
| Subject: xterm 327-1 to 329-1 needs font dependency
| 
| On an upgrade of xterm from 327-1 to 329-1 starting an xterm now
| complains:
|   $ xterm
|   /usr/bin/xterm: cannot load font
|   "-Misc-Fixed-bold-R-*-*-10-100-75-75-C-60-ISO8859-1"
|   /usr/bin/xterm: cannot load font
|   "-Misc-Fixed-medium-R-*-*-10-100-75-75-C-120-ISO10646-1"
|   /usr/bin/xterm: cannot load font
|   "-Misc-Fixed-bold-R-*-*-10-100-75-75-C-120-ISO10646-1"
| 
| When I downgrade to 327-1 these messages do not show, so I assume the
| latest version requires specific fonts.
| 
| I installed all the X11 fonts which were described as "core font"
| (surprisingly a reinstall of "xinit" did not install these),
| but still I get the above messages. However I assume xterm falls back
| on
| some other font, as everything displays ok (as far as I checked).
| 
| Q1. Can someone point me at which font I need to install to not get
| these
|   warnings (I tried a few, but no luck, and there are hundreds to
|   try)?
| 
| Q2. Shouldn't these fonts be a dependency of xterm?

see

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219800

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: XTerm 329-1 throwing error on absent bold font

[Thomas Dickey]

- Original Message -
| From: "Greywolf" 
| To: cygwin@cygwin.com
| Sent: Tuesday, June 20, 2017 6:31:42 PM
| Subject: XTerm 329-1 throwing error on absent bold font
| 
| Greetings,
| 
| Whenever I start up an XTerm, even if I have the resources
| 
| allowBoldFonts:   false
| 
| it throws the following error:
| 
| xterm: cannot load font
| "-Sun-Serif-bold-R-*-*-14-140-72-72-M-80-ISO8859-1"
| 
| Never mind the font name, this is irrelevant.  The fact that it
| wasn't
| throwing an error until my most recent upgrade today is bothersome.
| 
| Cygwin: 64-bit, CYGWIN_NT-10.0-WOW 2.8.0(0.309/5/3) 2017-04-01 20:42
| XTerm: 329-1
| 
| Version 327-1 does not exhibit this behaviour.

see

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219800

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: /etc/X11/app-defaults/XTerm refers to font "helvetica"

[Thomas Dickey]

- Original Message -
| From: "Rainer Blome" 
| To: cygwin@cygwin.com
| Sent: Thursday, June 30, 2016 1:22:37 PM
| Subject: /etc/X11/app-defaults/XTerm refers to font "helvetica"
| 
| Since many months (and probably several Cygwin and X11 releases),
| starting `xterm` triggers the following annoying warning (xterm
| starts fine otherwise):
| 
|  xterm &
|  Warning: Cannot convert string
|  "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*" to type
|  FontStruct
| 
| I have grepped for "helvetica" through my own config files
| (`.Xdefaults` etc.) and not found such a font reference.
| 
| The mailing list archives show that at least one other Cygwin user
| has encountered the same issue,
| and got no answer regarding this specific issue (just for another
| font issue).
| https://sourceware.org/ml/cygwin/2015-09/msg00184.html
| 
https://sourceware.org/cgi-bin/search.cgi?wm=wrd=extended=all=D=%2Fml%2Fcygwin%2F%25=helvetica
| At first glance, internet search provides only less relevant hits.
| 
| It looks like the cause is in file `/etc/X11/app-defaults/XTerm`, in
| the following line:
| 
|  *SimpleMenu*menuLabel.font:
|  -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*
| 
| When I comment out that line (using "!"), xterm starts without any
| warnings.
| 
| I do not recall having added that line myself, so I assume that it is
| part of its default content.
| Are users expected to maintain that file?

If there's a better choice for Cygwin, the packager probably should apply that 
as a patch.
I see that it's been as-is in xterm sources since 1994...

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: xterm 320-1 won't start with XTerm*faceName set in .Xresources

[Thomas Dickey]

- Original Message -
| From: "Brian Neu" 
| To: cygwin@cygwin.com
| Sent: Thursday, November 5, 2015 3:57:33 PM
| Subject: Re: xterm 320-1 won't start with XTerm*faceName set in .Xresources
| 
| On 11/2/2015 4:23 PM, Yaakov Selkowitz wrote:
| > Perhaps you are missing your preferred font.  What had you
| > specified for
| > XTerm*faceName?
| 
| BitStream Vera Sans Mono
| 
| Is there something that I can do to produce more debug information out
| of xterm as it launches.

Only partly: Xft avoids giving useful error messages.

You can use the xterm -report-fonts option to show what it does, but if there
are no TrueType fonts available, I would expect no useful output.

| 
| Honestly, I'm not even sure how to get a list of available fonts.

fc-list

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem of Starting Xterm using the System Tray Icon for Xterm for Cygwin64

[Thomas Dickey]

On Wed, Mar 19, 2014 at 08:44:29PM -0400, Thomas Dickey wrote:
 On Wed, Mar 19, 2014 at 04:25:44PM -0700, Mark Hansen wrote:
  On 3/19/2014 3:21 PM, Jyhshyong wrote:
   Hi
   
   I just installed Cygwin 64 on my 64-bit Cygein 64 PC, and found that 
   the Xterm in the system tray icon is no longer working.  
   
   The Xwin server system tray icon has the following target
   
   C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
   
   It works fine as the 32-bit version, click on the icon, I can start X 
   server and open a small Xterm window.
   
   However, the Xterm system tray icon with the target defined as
   
   C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/xterm -sl 1000 -
   geometry 120x40  -fn 
   -adobe-courier-bold-r-normal-*-18-*-*-*-*-*-iso8859-*  
   -sb -rightbar -fg black -bg white -display 127.0.0.1:0.0'
 
 I don't see anything wrong with the command-line, but it's been a while
 since I updated Cygwin packages (and I'm not in the middle of a release
 cycle), so I'll do that to see if it breaks for me.

hmm:

a) I'm uncertain how to configure the system tray to match the
   reported configuration (a sample .XWinrc might help).

b) the latest xterm I find from mirrors is still #302 (should not
   be a problem with the given command-line).

c) xterm comes up on my machine (which is 64-bits).

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Problem of Starting Xterm using the System Tray Icon for Xterm for Cygwin64

[Thomas Dickey]

On Wed, Mar 19, 2014 at 04:25:44PM -0700, Mark Hansen wrote:
 On 3/19/2014 3:21 PM, Jyhshyong wrote:
  Hi
  
  I just installed Cygwin 64 on my 64-bit Cygein 64 PC, and found that 
  the Xterm in the system tray icon is no longer working.  
  
  The Xwin server system tray icon has the following target
  
  C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
  
  It works fine as the 32-bit version, click on the icon, I can start X 
  server and open a small Xterm window.
  
  However, the Xterm system tray icon with the target defined as
  
  C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/xterm -sl 1000 -
  geometry 120x40  -fn -adobe-courier-bold-r-normal-*-18-*-*-*-*-*-iso8859-*  
  -sb -rightbar -fg black -bg white -display 127.0.0.1:0.0'

I don't see anything wrong with the command-line, but it's been a while
since I updated Cygwin packages (and I'm not in the middle of a release
cycle), so I'll do that to see if it breaks for me.

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Problem launching XTerm on new Cygwin installation

[Thomas Dickey]

On Fri, Mar 07, 2014 at 11:57:20AM -0800, Mark Hansen wrote:
 I just installed the 64-bit version of Cygwin on both a desktop PC and a 
 laptop PC.
 On the desktop, everything worked as expected without problems. On the 
 laptop, I
 have the following problems:
 
 When I launch a shell window, I get the following error:
 
 Your group is currently mkgroup. This indicates that neither your gid nor 
 your pgsid is in /etc/group.

(I don't know about this one)
 
 Also, when I try to launch an XTerm, I get the following message in the XTerm 
 window for
 just a few seconds and then the window goes away:
 
 /cygdrive/c/Apps/cygwin/bin/xterm: Could not exec XTERM_SHELL=XTERM_SHELL=: 
 No such file or directory

yes, that's a bug which surfaced in #301, thought it was gone in #302, and 
_should_ be gone in #303
(from yesterday)
 
 I'm starting the XWin Server using a shortcut with the following:
 
 C:\Apps\cygwin\bin\run.exe
 /usr/bin/bash.exe -l -c
 /usr/bin/startxwin.exe -- -emulate3buttons -multiwindow -clipboard 
 -swcursor
 
 I'm starting the XTerm using a shortcut with the following:
 
 C:\Apps\cygwin\bin\run.exe
 -p /usr/X11R6/bin xterm +tb -sb -sl 5000 -display 127.0.0.1:0.0 -ls 
 /bin/zsh -l

I'd try putting -e before the /bin/zsh, which moves it away from the bug 
noted.
(actually, the trailing -l doesn't look right either)

fwiw, when I compile #301, #302 and #303 for Cygwin, I don't see the bug.
However, I was able to analyze it on Linux with valgrind...
 
-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Problem launching XTerm on new Cygwin installation

[Thomas Dickey]

On Fri, Mar 07, 2014 at 02:03:57PM -0800, Mark Hansen wrote:
 As a result, it is working so I'll leave it alone.

:-)

 fwiw, when I compile #301, #302 and #303 for Cygwin, I don't see the bug.
 However, I was able to analyze it on Linux with valgrind...
 
 Well, I downloaded the Cygwin installation for my desktop last week, and 
 downloaded
 the Cygwin for my laptop yesterday. I guess the bug could have been 
 introduced between
 those times?

yes - I finished #302 at the beginning of the week.

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Problem launching XTerm on new Cygwin installation

[Thomas Dickey]

On Fri, Mar 07, 2014 at 03:37:36PM -0800, Mark Hansen wrote:
 
 Okay, this is very strange. As I said before, I have had no problems 
 launching XTerms
 on my desktop running 64-bit Cygwin. I've launched several XTerms today with 
 no problems
 ... until a few minutes ago. I went to launch an XTerm on my desktop PC and 
 it began
 having the same problem I saw on the laptop (the error having to do with 
 XTERM_SHELL).
 
 I edited the launcher shortcut to remove the /bin/zsh -l from the end of 
 the command
 and it started working again.
 
 I didn't do anything to update the Cygwin product on my desktop during this 
 time.

xterm handles these three cases differently:

xterm
xterm /bin/zsh
xterm -e /bin/zsh

The bug that I mentioned is in the second case - not in the other two.

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Problem with xterm-301-1

[Thomas Dickey]

On Thu, Feb 27, 2014 at 06:05:48PM +, Matt Seitz (matseitz) wrote:
  From: Thomas Dickey [mailto:dic...@his.com]
  
  On Thu, Feb 20, 2014 at 06:45:00PM +, Matt Seitz (matseitz) wrote:
From: Ola Strömfors [mailto:ola.stromf...@gmail.com]
   
After updating from 291-1 to 301-1 xterm starts /bin/sh instead of
my shell specified in /etc/passwd or in the SHELL environment variable.
   
The workaround I have found is to create /etc/shells with a list of
permitted shells, e.g.
  
  
  (whether xterm should use $SHELL incoming is a different issue that I
  am reconsidering)
 
 Is there any ETA for a resolution of this issue?

I added that to my changes for #302 yesterday, and have a couple more
issues to resolve (probably #302 will be available this weekend)

 I've been holding off on upgrading to xterm-301 because of this issue.  I'm
 not sure if there is some patch coming soon (either to xterm or adding a
 default /etc/shells to Cygwin), or if I should just plan on manually creating
 my own /etc/shells.

With #302, this will work:

SHELL=whatever xterm

but this is a special case (the program will run - a fix - but
will need to be in /etc/shells to have xterm set $SHELL):

xterm whatever

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Problem with xterm-301-1

[Thomas Dickey]

On Thu, Feb 20, 2014 at 11:33:22AM -0700, Jim Reisert AD1C wrote:
 On Thu, Feb 20, 2014 at 10:47 AM, Ola Strömfors wrote:
 
  After updating from 291-1 to 301-1 xterm starts /bin/sh instead of
  my shell specified in /etc/passwd or in the SHELL environment variable.
 
 I saw the same thing, but only on my home computer running Windows 7
 Pro 64-bit, not on my work laptop running Windows 7 Enterprise 64-bit.
 
 I start Xwin this way (i.e. same as Cygwin-X group in Start menu):
 
 C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
 
 I don't know why SHELL defined as /bin/sh by default (my entry in the
 /etc/passwd file invokes bash).  I could not find a way to change

That sounds like a case reported Saturday - see

ftp://invisible-island.net/temp/xterm-301a.patch.gz

I have a few other reports on different issues to iron out, and
expect to be ok with #302 sometime next week.

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Problem with xterm-301-1

[Thomas Dickey]

On Thu, Feb 20, 2014 at 06:45:00PM +, Matt Seitz (matseitz) wrote:
  From: Ola Strömfors [mailto:ola.stromf...@gmail.com]
  
  After updating from 291-1 to 301-1 xterm starts /bin/sh instead of
  my shell specified in /etc/passwd or in the SHELL environment variable.
  
  The workaround I have found is to create /etc/shells with a list of
  permitted shells, e.g.
 
 From http://invisible-island.net/xterm/xterm.log-contents.html#xterm_301:
 
 Patch #301 - 2014/01/19
 only set SHELL environment variable to programs found in /etc/shells 
 (prompted by patch/report by Al Poole).

yes.

(whether xterm should use $SHELL incoming is a different issue that I
am reconsidering)

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: xfig: Warning: Missing charsets in String to FontSet conversion

[Thomas Dickey]

On Wed, Feb 13, 2013 at 12:17:07PM -0500, Jack wrote:
 Note these are after installing the sony font.  It looks like a
 nearly complete list of charsets.  I certainly don't need most of
 them.  I wonder if there is some Windows setting to trim down the
 list even considered on the PC?

Probably not - the problem is in the X libraries:

http://invisible-island.net/xterm/xterm.faq.html#slow_menus

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: xfig: Warning: Missing charsets in String to FontSet conversion

[Thomas Dickey]

On Wed, Feb 13, 2013 at 05:48:39PM -0500, Jack wrote:
 On 2013.02.13 16:47, Thomas Dickey wrote:
 On Wed, Feb 13, 2013 at 12:17:07PM -0500, Jack wrote:
  Note these are after installing the sony font.  It looks like a
  nearly complete list of charsets.  I certainly don't need most of
  them.  I wonder if there is some Windows setting to trim down the
  list even considered on the PC?
 
 Probably not - the problem is in the X libraries:
 
  http://invisible-island.net/xterm/xterm.faq.html#slow_menus
 
 I'll play with xterm, but I've never noticed a bad delay in startup.
 Also - this seems only partly related to the xfig startup messages.
 Does anyone know offhand if xfig also uses the Athena widgets?

yes (according to the dependencies I see in Debian, it's one of 125
packages who do this).

xterm, as noted in the faq, uses a workaround

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Strange xterm scrolling problem introduced in XTerm(289)

[Thomas Dickey]

On Tue, Feb 12, 2013 at 04:22:05PM -0700, Jim Reisert AD1C wrote:
 On Tue, Feb 12, 2013 at 4:01 PM, Thomas Dickey wrote:
 
  Did you run #288 before this update?  (288 had several fixes for
  Coverity warnings, one of the #289 changes fixed something that
  I broke in addressing those).
 
 I believe I had been running #288 at one point.  I just updated Cygwin
 and could only revert to 287 (not 288).  There is no scrollback
 problem with this version.

hmm - _looking_ for the problem, I ran uxterm with valgrind (which reported
no problem...), but I resized the window back and forth a few times and
after several tries, got some debris on the screen which corresponds
to what you're describing.  (Scrolling with the shifted pageup/pagedown
or with the scrollbar didn't produce it; it's the repainting due to
resizes dragging text out of the scrollback which gives the result).

thanks for the report (I'll work on this now)

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Strange xterm scrolling problem introduced in XTerm(289)

[Thomas Dickey]

On Tue, Feb 12, 2013 at 06:50:48PM -0500, Thomas Dickey wrote:
 On Tue, Feb 12, 2013 at 04:22:05PM -0700, Jim Reisert AD1C wrote:
  On Tue, Feb 12, 2013 at 4:01 PM, Thomas Dickey wrote:
  
   Did you run #288 before this update?  (288 had several fixes for
   Coverity warnings, one of the #289 changes fixed something that
   I broke in addressing those).
  
  I believe I had been running #288 at one point.  I just updated Cygwin
  and could only revert to 287 (not 288).  There is no scrollback
  problem with this version.
 
 hmm - _looking_ for the problem, I ran uxterm with valgrind (which reported
 no problem...), but I resized the window back and forth a few times and
 after several tries, got some debris on the screen which corresponds
 to what you're describing.  (Scrolling with the shifted pageup/pagedown
 or with the scrollbar didn't produce it; it's the repainting due to
 resizes dragging text out of the scrollback which gives the result).
 
 thanks for the report (I'll work on this now)

The problem is that in reverting the change from #282, I missed
a piece - will followup with a _short_ patch for #290...

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: xterm and font problems after last update

[Thomas Dickey]

On Mon, Feb 11, 2013 at 12:23:43PM +0100, marco atzeri wrote:
 after last package update I noticed two issues:
 
 on .XWinrc I was forced to change

The first one was reported a week ago as FreeBSD #175782,
and is fixed in #289 (last Friday).
 
 $ xfontsel.exe 
 Warning: Missing charsets in String to FontSet conversion

The second one was (I think) reported/fixed on this list.

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: XTerm icon updated? Re: Updated: xterm-283-1

[Thomas Dickey]

On Thu, Oct 18, 2012 at 04:35:24PM +, Matt Seitz (matseitz) wrote:
  From: Thomas Dickey
  
  I did consider providing a special resource value that would suppress the
  xterm-specific icon (such as none or default), but decided to see what
  type of feedback I'd get first.
 
 I like having a specific xterm icon in the taskbar to make it clear which X 
 application is actually running.  I was just surprised to see a different 
 icon, and I was curious what had changed to make it appear.  Thanks for the 
 explanation!

no problem (thanks for the feedback)

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: XTerm icon updated? Re: Updated: xterm-283-1

[Thomas Dickey]

On Mon, Oct 15, 2012 at 05:58:10PM +, Matt Seitz (matseitz) wrote:
 Did this update change the XTerm icon that is displayed in the Windows task
 bar?
 
 Previously, when I launched the XWin Server, I would see the x.org logo (a
 black X with an orange ring) in the task bar as the icon for the XTerm
 window.  Today, I see the XTerm icon for the XTerm window:  a red X with a
 blue T superimposed over it.

yes - from xterm's standpoint it's moderately complicated.

For Xwin Server, I assume that the icon is shown because that's the
window which keeps the server from exiting.

Though I investigated several cases, I didn't consider this particular
one.  xterm now specifies an icon because several of the cases I found
didn't provide any icon at all - a favor from the desktop packagers, it
seems. I did consider providing a special resource value that would
suppress the xterm-specific icon (such as none or default), but
decided to see what type of feedback I'd get first.

HTH
 
 Yaakov (Cygwin/X) wrote:
  The following package has been updated for the Cygwin distribution:
  
  *** xterm-283-1
  
  The xterm program is a terminal emulator for the X Window System. It
  provides DEC VT102 and Tektronix 4014 compatible terminals for programs
  that can't use the window system directly.
  
  This is an update to the latest upstream release.
  
  -- 
  
  Yaakov
  Cygwin/X
 
 --
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
 Problem reports:   http://cygwin.com/problems.html
 Documentation: http://x.cygwin.com/docs/
 FAQ:   http://x.cygwin.com/docs/faq/

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: XTerm icon updated? Re: Updated: xterm-283-1

[Thomas Dickey]

On Mon, Oct 15, 2012 at 03:42:02PM -0600, Jim Reisert AD1C wrote:
 On Mon, Oct 15, 2012 at 11:58 AM, Matt Seitz wrote:
 
  Did this update change the XTerm icon that is displayed in the Windows task 
  bar?
 
 Yes, it reminds me of the Texas Rangers logo (American baseball team).

Looking at that, I'd say not more than 10% (and wasn't inspired by it -
I don't pay much attention to organized sports).

See
http://invisible-island.net/xterm/xterm.icon.html

(I'll add more to the page, when I'm not working on more urgent things)

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: typo in man xterm

[Thomas Dickey]

On Sat, Jul 28, 2012 at 02:24:52PM +0200, Paul Maier wrote:
 Hi,
 
 the word not should be added to this description:
 
 
 man xterm
[...]
+maximized
This option indicates that xterm should ask the window manager 
 to maximize its layout on startup.
 
 
 It should read:
 ... should *not* ask the window manager ...

The immediate call is made via the X server, but the window manager
is in control of the subsequent reconfiguration requests, and as
a result can keep xterm's window from changing size.  To simplify
the manpage, xterm does ask.

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: AW: typo in man xterm

[Thomas Dickey]

On Sat, Jul 28, 2012 at 02:57:35PM +0200, Paul Maier wrote:
 
   Hi,
  
   the word not should be added to this description:
  
  
   man xterm
  [...]
  +maximized
  This option indicates that xterm should ask the window 
   manager to
  maximize its layout on startup.
  
  
   It should read:
   ... should *not* ask the window manager ...
  
  The immediate call is made via the X server, but the window manager
  is in control of the subsequent reconfiguration requests, and as
  a result can keep xterm's window from changing size.  To simplify
  the manpage, xterm does ask.
  
 
 
 Hi Thomas,
 
 so what is the difference between options +maximized and -maximized?

sorry - I misread the question :-)

 The behaviour is different: one maximizes, the other not,
 but the descriptions in the man page are exactly the same.
 
 I still think the word not should be added to the description of 
 +maximized
 to match the behaviour of this option.

you're correct (thanks)

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: xterm -si doesn't hold the line

[Thomas Dickey]

On Sat, Jul 28, 2012 at 02:49:22PM +0200, Paul Maier wrote:
 Hi,
 
 xterm -si doesn't work as expected.

The short answer is that it's always been that way :-)

This refers to the scrollTtyOutput, which in xterm is described:

   scrollTtyOutput (class ScrollCond)
   Specifies whether or not output to the terminal should automat-
   ically cause the scrollbar to go to the bottom of the scrolling
   region.  The default is ``true.''

and in rxvt (in the mid-1990s):

   scrollTtyOutput: boolean
   True: scroll to bottom when tty receives output; option -si.
   False: do not scroll to bottom when tty receives output; option
   +si.

However, rxvt (also long ago) implemented a different flavor:

   scrollWithBuffer: boolean
   True: scroll with scrollback buffer when tty receives new lines
   (and scrollTtyOutput is False); option -sw. False: do not scroll
   with scrollback buffer when tty receives new lines; option +sw.
 
and (relatively recently - two years ago) I implemented a different choice:

   allowScrollLock (class AllowScrollLock)
   Specifies  whether  control sequences that set/query the Scroll
   Lock key should be allowed, as well as whether the Scroll  Lock
   key responds to user's keypress.  The default is false.

   When this feature is enabled, xterm will sense the state of the
   Scroll Lock key each time  it  acquires  focus.   Pressing  the
   Scroll Lock key toggles xterm's internal state, as well as tog-
   gling the associated LED.  While the  Scroll  Lock  is  active,
   xterm attempts to keep a viewport on the same set of lines.  If
   the current viewport is scrolled past  the  limit  set  by  the
   saveLines resource, then Scroll Lock has no further effect.

   The  reason for setting the default to false is to avoid user
   surprise.  This key is generally unused in keyboard  configura-
   tions,  and has not acquired a standard meaning even when it is
   used in that manner.  Consequently, users have assigned it  for
   ad hoc purposes.

That has the same general effect if Scroll Lock is set - I might still
add a -sw option like rxvt.

 To reproduce (think of a tail -f instead of xev):
 
 1. xterm -si -e /bin/xev
 2. move the mouse in the xev window to produce some lines
 3. scroll the xterm up half way and remember the visible lines
 4. while looking at the xterm, again move the mouse in the xev window
 
 You see: xterm scrolls slowly down.
 
 I would expect xterm to hold the current view while xev produces more lines 
 at the end.
 
 
 Suppose you have a tail -f running and scroll the xterm up to view a 
 specific line.
 I would expect that line to stay visible until I scroll somewhere else.
 But it's not: as the tail -f produces output, the xterm scrolls slowly down.
 To clarify: xterm does not scroll down to the very end but it scrolls down 
 line by line,
 as if xterm would try to keep the same distance between the current scrolling 
 position and the most recent line.
 
 I would expect xterm to keep the same distance between the current scrolling 
 position and the *FIRST* line.
 
 
 In case above behaviour is the desired behaviour, I wanted to suggest another 
 command line option like -si-top
 for my use case.
 
 Regards,
   Paul
 

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: AW: AW: AW: AW: AW: Can't paste text or type dead keys when mouse is out of the window

[Thomas Dickey]

On Sun, Jul 22, 2012 at 02:26:06AM +0200, Paul Maier wrote:
 
 
   The problem here is, when running vi in an xterm and the mouse slowly 
   (unnoticed)
   moves over the scrollbar or out of the xterm, and you want to jump to 
   mark a,
   you need to enter `a, that is in keystrokes
  
  
   I'll experiment to see if I can reproduce this effect with my 
   environment.
   thanks for the detailed explanation.
  
  
   Hi Thomas,
  
   yes, I'm talking about dead keys = compose sequences.
  
   Was it possible to you to reproduce it in your environment? Typing dead 
   key ` apostrophe
   then press letter a while the mouse pointer is over the scrollbar area 
   of an xterm?
  
  yes - I can reproduce it.  Actually once I was made aware of the issue,
  I could see in my mind where the problem might lie.  But I just verified
  it since you reminded me (on one of my Linux machines).
  
  My idea about the problem is that since xterm has setup translations
  (which capture the input) on more than one widget (without appearing to
  address this special case), that it might be that there's a better point
  in the widget to attach the translations to.
  
  This was discussed a little late in the #277 cycle to want to hold that
  up, so I had in mind to spend some time investigating a solution for it
  during #278.
  
 
 
 Hi Thomas,
 
 I would like to report, that above problem still exists.
 I tested against xterm-281.

yes (I spent some time investigating this, but did not yet find a solution)

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: original cygwin console?

[Thomas Dickey]

On Sat, Dec 03, 2011 at 01:44:59AM -0500, Christopher Faylor wrote:
 On Fri, Dec 02, 2011 at 09:30:06PM -0500, wxie wrote:
 The new cygwin console use mintty. Is it still possible to change back 
 to the orignal console?
 
 Wrong mailing list but, there was no cygwin console.  That's just a
 standard Windows console running bash.

agree wrong mailing list

disagree on the followup comment: a standard Windows console provides
a way to implement a simple terminal emulator, but the functionality which
wxie appears to refer to was the implementation provided by Cygwin.

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: original cygwin console?

[Thomas Dickey]

On Sat, Dec 03, 2011 at 01:30:23PM -0500, Christopher Faylor wrote:
 On Sat, Dec 03, 2011 at 09:23:38AM -0500, Thomas Dickey wrote:
 On Sat, Dec 03, 2011 at 01:44:59AM -0500, Christopher Faylor wrote:
  On Fri, Dec 02, 2011 at 09:30:06PM -0500, wxie wrote:
  The new cygwin console use mintty. Is it still possible to change back 
  to the orignal console?
  
  Wrong mailing list but, there was no cygwin console.  That's just a
  standard Windows console running bash.
 
 agree wrong mailing list
 
 disagree on the followup comment: a standard Windows console provides a
 way to implement a simple terminal emulator, but the functionality
 which wxie appears to refer to was the implementation provided by
 Cygwin.
 
 There is no implementation beyond running bash, i.e.:

...and the cygwin dll.  Taking a quick look at the source, it seems
that one of the places of interest is fhandler_console.cc

there's no disagreement that it's running in a Windows console window,
but the point that cygwin provides the terminal emulation behavior
seems to be dismissed - awai

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: XTerm metaSendsEscape not working

[Thomas Dickey]

On Wed, 9 Nov 2011, Jesse Ziser wrote:


Hello,

I find that adding the following:

XTerm*vt100.metaSendsEscape: true
XTerm*vt100.altSendsEscape: true
XTerm*vt100.eightBitInput: false

to my .Xdefaults does not seem to change the way XTerm behaves WRT meta-key 
handling.  It still sends 0xF7 for meta-W, for example (or the UTF-8 
equivalent, depending on how I set LANG in the environment).


I've also tried this:

XTerm*metaSendsEscape: true
XTerm*altSendsEscape: true
XTerm*eightBitInput: false

to no avail.  However, adding lines like the following:

Meta KeyW: string(0x1b) string(w) \n


well, there's more than one aspect to the problem.  xterm is looking for 
whatever is used for the modifier which corresponds to the meta key. But X 
doesn't have that as a standard modifier.  So xterm looks at the modifiers 
and determines which one it is.  It might be the same as an Alt-key, and 
it might not.  So there's altSendsEscape as a workaround for that case.


On the other hand, if there are translations using the key that xterm 
finds to be the meta key, then xterm refrains from using it as a 
modifier, unless (for example) the alwaysUseMods resource is set to true.


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Default settings for XTerm

[Thomas Dickey]

On Mon, 31 Oct 2011, Edvardsen Kåre wrote:


On Mon, 31 Oct 2011, Edvardsen Kåre wrote:


Where do I change the default settings (globally) for the XTerm so I
don't have to set it every time from the VT Options and VT Fonts
menus?
I tried to change stuff in /etc/X11/app-defaults/XTerm-color, but

didn't

affect anything.


XTerm-color includes XTerm.  I'd modify the latter.
(there's also the possibility that neither is used - appres XTerm
would show whatever resource values are found, though not where).


The XTerm is used, but XTerm-color is not. Copying the color stuff
into the XTerm file works, but I can't figure out how to set default
font to TrueType, and default font size.


Those are all in the manpage - look for (1) *customization: color,
(2) faceName, and (3) faceSize

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Default settings for XTerm

[Thomas Dickey]

On Mon, 31 Oct 2011, Eliot Moss wrote:


On 10/31/2011 3:45 PM, Eliot Moss wrote:

I think that's customization: -color (note the
dash), but yes :-) ... Eliot Moss


Sheesh, I also typed it wrong, corrected above!  EM


:-)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Updated: xterm-275-1

[Thomas Dickey]

On Tue, 4 Oct 2011, Yaakov (Cygwin/X) wrote:


The following package has been updated for the Cygwin distribution:

*** xterm-275-1

xterm is a terminal emulator for the X Window System. It provides DEC
VT102 and Tektronix 4014 compatible terminals for programs that can't
use the window system directly.

This is an update to the latest upstream version.  Any one who has
reported xterm bugs recently is asked to test this release and report
back on the results.


I had one bug report against #275, last week (abbreviation for -geometry 
command-line option) does not work.  Fix is in 
ftp://invisible-island.net/temp


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm update

[Thomas Dickey]

On Thu, 19 May 2011, webmaster wrote:


I'm eagerly expecting an update to xterm 270 which I hope includes the
fix for the scrollbar drawing issue

You can get 269 from git:
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/xterm;a=summary

To build 270 just modify the 269 .cygport.

When I build 269 or 270 the scrollbar issue is fixed, but this line in
my ~/.Xdefaults stops having an effect:


perhaps your development environment lacks the FreeType library
(that would show up in the configure step)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm access violations (again)

[Thomas Dickey]

On Wed, 23 Mar 2011, Yaakov (Cygwin/X) wrote:


On Wed, 2011-03-23 at 19:16 -0600, Jim Reisert AD1C wrote:

Thomas, that may well be true, but the latest one in the Cygwin
repository reports (261).  It shows up as 261-1 in setup.exe


I just built 269 and will uploaded it with the rest of the X11 updates.


thanks

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm access violations (again)

[Thomas Dickey]

On Wed, 23 Mar 2011, webmaster wrote:


what is xterm -v?

$ xterm -v
XTerm(261)


That's from last June.  #263 makes a fix for a problem which might be 
relevant (and #265 fixes a regression from #263).



Note I built myself using cygport so that I could add
--disable-narrowproto (See thread with subject Bug: XTerm scrollbar
issue last updated 7/13/2010)


#269 is current.  At the moment, the only fixes I've made against that
are minor things (an incomplete change for the fullscreen feature, and
an obscure case of a control sequence from #251 changes).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm access violations (again)

[Thomas Dickey]

On Tue, 22 Mar 2011, webmaster wrote:


On my Win7 system, [xterm] crashes about 1/2 the time.

Right. Same, here. It used to crash a lot less frequently.


what is xterm -v?

(the last crash-related bug I recall was fixed last spring).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Clear Screen

[Thomas Dickey]

On Wed, 1 Dec 2010, Ajay Jain wrote:


Hi,

I use bash on Xterm.
While working you press Ctrl-L, so that the screen gets cleared and
you see the currently line only. But you may want to see the last
outputs/prints. However, if you do a Ctrl-L/clear command, these
prints go away. In that case, what can you use so that you clear the
screen of the prints/outputs from last command. But in case you want
to see the last output, you can just go scroll up/pageup.

I looked at the bash  Xterm manpage but this info is not available.


The closest I recall offhand is the xterm tiXtraScroll resource (which 
would be useful if you were asking about running vi, etc).  But a 
screen-clear is done without causing any scrolling action.


By the way, the clearing of the screen on ctrl/L is not done by xterm.
(PuTTY does this, in case you're mistaking it for xterm, otherwise
I'd assume bash is doing it).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Clear Screen

[Thomas Dickey]

On Wed, 1 Dec 2010, Andy Koppe wrote:


On 1 December 2010 21:24, Thomas Dickey wrote:

By the way, the clearing of the screen on ctrl/L is not done by xterm.
(PuTTY does this, in case you're mistaking it for xterm, otherwise
I'd assume bash is doing it).


Yep, bash sends '\e[2J' when ^L is pressed. PuTTY's behaviour of
interpreting ^L as formfeed is due to its SCOANSI mode being enabled
by default. (Strange that the VT100 interpreted ^L, which of course is
ASCII formfeed, as linefeed instead.)


yes - it used to be that only printers did form-feeds, and terminals did 
not.  See my comment about a repaginator here:


http://invisible-island.net/personal/oldprogs.html

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: changing font

[Thomas Dickey]

On Tue, 31 Aug 2010, matias kaukonen wrote:


Yes, it displays the font but it does not set the font.  Only the
'quit' button works.


I was asking about the result with xfd to be sure that the font itself is 
recognized.  I don't see anything wrong with the description of your 
changes to the X resources.


Another place to check is whether there are conflicting font resources 
shown, e.g., using appres XTerm.


Beyond that, I generally just compile xterm with its debugging trace
enabled and see what resource value is actually used.  It's also possible
to get the nominal value of the font using an escape sequence in a script
or program such as xtermset.



On Mon, Aug 30, 2010 at 4:22 PM, Thomas Dickey dic...@his.com wrote:

On Mon, 30 Aug 2010, matias kaukonen wrote:


The above worked on my previous computer, but now it does not work with my
current computer.  This is what I tried:
1. a)  Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xdefaults
  b) typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources

next,
2. a) Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xresources
  b)  typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources

But neither one affected the xterm font.


does
       xfd -fn lucidasanstypewriter-10

display the font you asked for?


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: changing font

[Thomas Dickey]

On Mon, 30 Aug 2010, matias kaukonen wrote:


The above worked on my previous computer, but now it does not work with my
current computer.  This is what I tried:
1. a)  Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xdefaults
   b) typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources

next,
2. a) Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xresources
   b)  typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources

But neither one affected the xterm font.


does
xfd -fn lucidasanstypewriter-10

display the font you asked for?

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Re: xterm and 7-bit control codes

[Thomas Dickey]

On Sat, 14 Aug 2010, Ryan Johnson wrote:


On 8:59 PM, Thomas Dickey wrote:

As far as I know, xterm's never sent more than one byte for either x/y in
a button event.  Ditto for rxvt.  It sounds like a useful idea, except that 
it would of course be incompatible with the existing applications.

So it would have to be enabled by a new control sequence.
Hehe... very true about breaking existing apps. All those years ago the extra 
octet kick-started everything by confusing emacs (well, xterm-mouse-mode, 
really). I started looking at the character stream and reverse-engineered the 
above formula while trying to get rid of all the ascii garbage that polluted 
my buffers after stray mouse clicks. Only then did I realize I could exploit 
(rather than suppress) the extra octets to make large terminals behave 
better...




(On the other hand, whatever application you were using at the time may
have translated the characters in that manner).
I dug up an old .emacs, and it actually mentions gnu screen. If so, that's 
definitely been fixed because I specifically tested screen on several 
machines (cygwin, solaris, linux), plus rxvt and the gnome terminal***) 
before posting here. Any ideas what other terminal emulators I might test?


Not offhand.  The only prior discussion I recall in that area was the
1-byte limit.  It might have been someone's more/less private patch to
screen - to be usable with screen in the first place, it has to be aware
of the control sequence (otherwise it tends to filter things out).  The
mouse control sequences are a special case, since they don't have a final
character.

Side note: how much pain would it be asking for if I tried to add the 
double-octet behavior to xterm as a feature? Would it be better to tackle 
rxvt? Or would it be man-weeks of work no matter what and I should just drop 
it?


It didn't sound like a lot of work: a case-statement entry in dpmodes 
(charproc.c) to enable/disable it, and a few lines of code in EditorButton 
(button.c) plus updating ctlseqs.ms).




Thanks,
Ryan

*** testing gnome terminal was hilarious: enabling mouse support and clicking 
on the wrong position sends a control sequence containing ^Z, which duly 
backgrounds the app!


;-)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm and 7-bit control codes

[Thomas Dickey]

On Thu, 12 Aug 2010, Ryan Johnson wrote:


Hi all,

I'm running into a strange one...

At some point in the past (on linux because I didn't know about cygwin yet), 
xterm used to send the following control sequence for a mouse click at row 1, 
col 250


ESC [ M SPC \303\206 ! ESC [ M # \303\206 !

From what I could piece together, the formula for the x position was:

\40+x (x  96)
\300+X/64 \200+X%64 (otherwise)

In other words, the first 96 characters were encoded as single octets, with 
all later ones encoded as an octet pair.


As far as I know, xterm's never sent more than one byte for either x/y in
a button event.  Ditto for rxvt.  It sounds like a useful idea, except 
that it would of course be incompatible with the existing applications.

So it would have to be enabled by a new control sequence.

(On the other hand, whatever application you were using at the time may
have translated the characters in that manner).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Unable to install X on 64-bit Windows 7 Premium

[Thomas Dickey]

On Wed, 11 Aug 2010, Bob Kline wrote:


On 8/10/2010 8:12 AM, Jon TURNEY wrote:

I'm a bit surprised that gcc4 is a dependency of X.


It's a dependency of imake, which is a member of the XWin set.


imake uses the C preprocessor...

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Using konsole in Cygwin

[Thomas Dickey]

On Fri, 6 Aug 2010, JOHNER Jean 066030 wrote:


On Thu, 5 Aug 2010, Thomas Dickey wrote:

iirc, cygwin has xterm, rxvt and rxvt-unicode


which are very nice tools. And also Mintty which is great.
But console has also interesting features (multiple shells in the same
window in different tabs for example).

From your answer, I conclude that konsole is not available in Cygwin.
I guess the answer is the same for GNOME-termimal.
Do you confirm?


that's my understanding - there was just this week a thread on this
list which stated that.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: How to launch an xterm using Monospace font

[Thomas Dickey]

On Fri, 6 Aug 2010, JOHNER Jean 066030 wrote:


On Thu, 5 Aug 2010, Thomas Dickey wrote:

I would like to launch an xterm terminal using Monospace font.
Monospace is the font used by default by gvim.
I tried:
xterm -fn Monospace



xterm -fa Monospace



is perhaps what you meant.


Thank you for your quick answer.
xterm -fa Monospace
gives no error message but open xterm with the same font (which is not
Monospace) as:
xterm


yes (one of the features of Xft is that it provides no error messages,
but simply uses the default font if there's any problem...)


If you try
xterm -fa foobar
you also get the same result, for any foobar string.


That sounds as if the strings you're giving don't match the available
font family names.  If you have fc-list, it can give a list of names.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Using konsole in Cygwin

[Thomas Dickey]

On Thu, 5 Aug 2010, JOHNER Jean 066030 wrote:


Hello,
I often connect to a KDE Linux server so that I am familiar with
konsole.
I tried the konsole command on Cygwin, which is unknown.
Is there a way to use KDE console on Cygwin.

Sorry if my questions look too much elementary. I am new to Cygwin. Do
not hesitate to redirect me towards FAQs or user guides.


iirc, cygwin has xterm, rxvt and rxvt-unicode

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: How to launch an xterm using Monospace font

[Thomas Dickey]

On Thu, 5 Aug 2010, JOHNER Jean 066030 wrote:


Hello,

I would like to launch an xterm terminal using Monospace font.
Monospace is the font used by default by gvim.
I tried:
xterm -fn Monospace

  xterm -fa Monospace

is perhaps what you meant.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Missing charsets in String to FontSet conversion

[Thomas Dickey]

On Tue, 3 Aug 2010, Ryan Johnson wrote:


Hi all,

At some point an annoyance appeared with my xterm windows: The first time I 
use [ctrl]+mouse click in any window, that xterm becomes unresponsive for 
about 5 seconds with the CPU pegged to 100%. After the five seconds is up, 
whatever shell spawned the xterm receives the following message:

Warning: Missing charsets in String to FontSet conversion


After that all works normally (until I open the next xterm window).

Is there a way to diagnose what the problem is? I don't know what FontSet 
string the error even refers to, let alone which parts of that string were 
invalid. In any case, it really shouldn't take five seconds of hard CPU 
crunching to detect and report an invalid input string.


This topic came up last year, iirc the issue was this:

http://invisible-island.net/xterm/xterm.faq.html#slow_menus

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Missing charsets in String to FontSet conversion

[Thomas Dickey]

On Tue, 3 Aug 2010, Andy Koppe wrote:


On 3 August 2010 14:35, Jon TURNEY wrote:

On 03/08/2010 10:00, Thomas Dickey wrote:

This topic came up last year, iirc the issue was this:

http://invisible-island.net/xterm/xterm.faq.html#slow_menus


Could the menuLocale resource setting mentioned there be added to
Cygwin xterm's default config at /etc/X11/app-defaults/XTerm?


fwiw, I made it default in #257 (current is #261)

http://invisible-island.net/xterm/xterm.log.html#xterm_257

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: changing font

[Thomas Dickey]

On Tue, 20 Jul 2010, matias kaukonen wrote:


-
Then I changed .Xdefaults to
-
aterm*font:-adobe-courier-bold-r-normal--17-120-100-100-m-100-iso10646-1
XTerm.font:-adobe-courier-bold-r-normal--17-120-100-100-m-100-iso10646-1
urxvt*font:-adobe-courier-bold-r-normal--17-120-100-100-m-100-iso10646-1


Only the second has the potential for affecting xterm.
But there's no match for XTerm.font.
Depending on how it is compiled, these can match:

XTerm.vt100.font
XTerm*vt100.font

(the latter can match an intermediate level, which is used in the 
configuration that provides the toolbar/menubar).


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: changing font

[Thomas Dickey]

On Tue, 13 Jul 2010, matias kaukonen wrote:


Based on a previous suggestion:

fc-list | less
-
Luxi Serif:style=Regular
LucidaBright:style=Italic
Utopia:style=Bold Italic
Bitstream Vera Sans Mono:style=Bold
Luxi Serif:style=Bold
LucidaTypewriter:style=Sans Bold
Fixed:style=Bold
.. . .
-
So I setup my .Xdefaults to:
-
   XTerm.VT100.scrollBar:  True
   XTerm.VT100.visualBell: True
   XTerm.VT100.loginShell: True
XTerm*scrollbar:True
XTerm*background:   Wheat
XTerm*foreground:   Black
XTerm*font: Luxi Serif:style=Bold


This might work:

  XTerm*font: Luxi Serif


*renderFont:true
---
The result, when I started up an xterm, was:
---
Warning: Color name Wheat  is not defined
Warning: Color name Black  is not defined
xterm:  unable to open font Luxi Serif , trying fixed


xterm is only looking for the face-name (making it handle the modifiers
in the pattern is something that's been recently suggested).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Bug: XTerm scrollbar issue

[Thomas Dickey]

On Tue, 13 Jul 2010, Jon TURNEY wrote:

I note that the list of platforms for which --enable-narrowproto is the 
default in xterm's aclocal.m4 CF_ENABLE_NARROWPROTO macro (which includes 
cygwin) doesn't match the list of platforms which default to narrow 
prototypes in xproto (which doesn't include cygwin).  This makes me wonder if 
the cygwin platform default managed to get changed during modularization...


modularization broke portabililty some time ago, by discarding the
customizations embedded in the imake configurations.  xterm's configure
script only has what was in the imake configuration, so presumably when
cygwin stopped relying on that, it broke here.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: changing font

[Thomas Dickey]

On Mon, 12 Jul 2010, matias kaukonen wrote:


1. Could someone pls post instructions about how to reply to an existing post.
2. I have a font I'd like to use and its located at
/usr/X11R6/lib/X11/fonts/TTF with
administrator permissions.
3. How can I make this font the default for an xterm?  Do I have to
set the path in
some manner?


You have to tell xterm to use the font by setting some resource values.
One is the name of the font, which you may be able to find using fc-list
(that would be the faceName resource), and the other is the renderFont
resource, set that to true to tell xterm to use TTF's rather than bitmap
fonts by default.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: XTerm scrollbar issue

[Thomas Dickey]

On Wed, 30 Jun 2010, Thomas Dickey wrote:


On Wed, 30 Jun 2010, webmaster wrote:


All releases of xterm newer that 229 (i.e. since June '08) have a
broken scrollbar.  It never bothered me enough to post a message, but
I've been setting up some new systems and have found it annoying to
dig up xterm-229 and manually install it.

These images show what the scrollbar used to look like (and what it
still looks like in all recent Linux distributions, even with latest
xterm builds):


Problems like that shown with the scrollbar are usually a compile-time
mismatch on floating-point.  There's a configure option for xterm to
address this (--enable-narrowproto or --disable-narrowproto), since
the mismatch is not detectable via automatic checks.


The issue is documented in xterm's INSTALL file.  Packagers have to 
essentially ensure that the prototype for XawScrollbarSetThumb is compiled 
properly.  For instance, the package for xterm in Debian uses 
--enable-narrowproto


That turns on a #define for NARROWPROTO which may be missing (or not not 
coordinated with Xfuncproto.h, which in turn sets #defines used in Xaw, to 
choose between a float and a double for the type of one of its 
parameters).


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: XTerm scrollbar issue

[Thomas Dickey]

On Wed, 30 Jun 2010, webmaster wrote:


All releases of xterm newer that 229 (i.e. since June '08) have a
broken scrollbar.  It never bothered me enough to post a message, but
I've been setting up some new systems and have found it annoying to
dig up xterm-229 and manually install it.

These images show what the scrollbar used to look like (and what it
still looks like in all recent Linux distributions, even with latest
xterm builds):


Problems like that shown with the scrollbar are usually a compile-time
mismatch on floating-point.  There's a configure option for xterm to
address this (--enable-narrowproto or --disable-narrowproto), since
the mismatch is not detectable via automatic checks.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm faceSize and -fs in version 260

[Thomas Dickey]

On Sun, 27 Jun 2010, Joseph Quinsey wrote:


The xterm faceSize resource and the -fs command line option do not seem to
work with xterm version 260.  Installing the previous Cygwin version, 255,
fixes this.


hmm - I changed the handling of the renderFont resource, but didn't
notice breakage of the other resources (perhaps the output of appres 
XTerm would show me the problem)


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

RE: xterm faceSize and -fs in version 260

[Thomas Dickey]

On Sun, 27 Jun 2010, Joseph Quinsey wrote:


Thomas Dickey replied:


And I realize -fa also doesn't seem to work for me for 260.


thanks - it's some error in the way I added the logic for the renderFont
resource.  You should be able to work around by adding

*renderFont:true

to your X resource settings.


Thank you.  This works for 260.


no problem (will fix soon)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7

[Thomas Dickey]

On Wed, 14 Apr 2010, Markus Hoenicka wrote:

This is where I have seen xterm to spend most of its time. In your log, this 
block of statements appears to be repeated several times for each font it 
checks in /etc/fonts. This would explain why it is related somehow to fonts 
in your case.


It's a known issue with the Athena widget set (technically in a 
lower-level library).


man xterm:

   menuLocale (class MenuLocale)
Specify  the  locale  used for character-set computations when
loading the popup menus.  Use this to  improve  initialization
performance of the Athena popup menus, which may load unneces-
sary (and very large) fonts, e.g., in a  locale  having  UTF-8
encoding.  The default is an empty string, which uses the cur-
rent locale setting.

Set it to C  to  achieve  the  best  performance  using  the
default  menu  resource  settings.   If you happen to be using
localized menu resources, set the resource accordingly.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Can't use Alt- Commands in xterm

[Thomas Dickey]

On Thu, 18 Feb 2010, Craig Moore wrote:


Hi,

I cannot execute commands using the Alt key. For example, whenever I
press, Alt -. I get a zero instead of the previous command. This is
also a problem whenever I run emacs inside xterm. Alt-w produces a ÷
(division symbol) instead of executing a copy region command. Also
Alt-x doesn't give the extended command mini-buffer, but instead
produces a ø (strike through o).

I do not expreience this problem whenever I run the Cygwin Bash Shell,
which I suppose makes sense.

I have read TFM, and it says I need to include the following information:


In man xterm, see eightBitInput and metaSendsEscape.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Can't use Alt- Commands in xterm

[Thomas Dickey]

On Thu, 18 Feb 2010, Craig Moore wrote:


In man xterm, see eightBitInput and metaSendsEscape.


Thanks, that lead me to this solution:


xterm-Main Menu-Meta Sends Escape


and now alt behaves as it should (Why isn't this the default
setting?!?) Is there someway to set xterm to always have 'Meta Sends
Escape' enabled?

Also, I would prefer if the 'Reverse Video' option is enabled (i.e.
xterm with a black background). This can be set from:


xterm-VT Options-Enable Reverse Video


I have to enable this each time I start xterm, and I would prefer it
if xterm would start with this enabled.


Those can be done via resource-settings, e.g. in your $HOME/.Xdefaults,
or in /etc/X11/app-defaults

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Cygwin 1.7 xterm

[Thomas Dickey]

On Fri, 15 Jan 2010, Jerry Lowry wrote:

After my last install of 1.7 software the X server does start and the blank X 
windows do go away.  But when I start an Xterm the blank X windows stay 
around.  Anyway to start Xterm with them going away once started.  Also, the 
Xterm that starts looks like a version from back in the 80's.  Has Main 
Options, VT Options, VT Fonts accross the top.  Any way to change this 
back to what I was running under 1.5?


man xterm

(command-line options)
   +tb This option indicates that xterm should not set up a toolbar.


(resources)
   toolBar (class ToolBar)
   Specifies  whether or not the toolbar should be displayed.  The
   default is true.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Cygwin 1.7 xterm

[Thomas Dickey]

On Fri, 15 Jan 2010, Jerry Lowry wrote:

Okay, I understand that, but I did not have to do this under 1.5.  Did they 
change the default in 1.7?


I've been seeing comments about this for a while - perhaps a year or so.
It might be a change in 1.7.

I use the toolbar configuration most of the time, but see my comment here

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406169

Any ideas as to why the blank X windows still continue to stick around after 
the Xterm windows opens?


no - one of the comments said that might be DOS windows (but I don't have
1.7 to see).



thanks




Thomas Dickey wrote:

On Fri, 15 Jan 2010, Jerry Lowry wrote:

After my last install of 1.7 software the X server does start and the 
blank X windows do go away.  But when I start an Xterm the blank X windows 
stay around.  Anyway to start Xterm with them going away once started. 
Also, the Xterm that starts looks like a version from back in the 80's. 
Has Main Options, VT Options, VT Fonts accross the top.  Any way to 
change this back to what I was running under 1.5?


man xterm

(command-line options)
   +tb This option indicates that xterm should not set up a 
toolbar.



(resources)
   toolBar (class ToolBar)
   Specifies  whether or not the toolbar should be displayed. 
The

   default is true.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/




--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Alt key not recognized as Meta in xterm

[Thomas Dickey]

On Fri, 1 Jan 2010, Andy Koppe wrote:


   XTerm*vt100.metaSendsEscape: true


Actually that's not a hack, but the correct solution. I think this
needs to be part of the default config in /etc/X11/app-defaults/XTerm.


However, the reason that it's not is because there's no standard for
the meta key assignment.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Alt key not recognized as Meta in xterm

[Thomas Dickey]

On Fri, 1 Jan 2010, Andy Koppe wrote:


2010/1/1 Thomas Dickey:

On Fri, 1 Jan 2010, Andy Koppe wrote:


   XTerm*vt100.metaSendsEscape: true


Actually that's not a hack, but the correct solution. I think this
needs to be part of the default config in /etc/X11/app-defaults/XTerm.


However, the reason that it's not is because there's no standard for
the meta key assignment.


Understood. I didn't mean it should be the default for Xterm in
general, but it should be for Cygwin's version, due to UTF-8 being the
default charset.


Is Cygwin also specifying a meta key?

(some people equate meta==alt, though they're not necessarily the same)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Alt key not recognized as Meta in xterm

[Thomas Dickey]

On Fri, 1 Jan 2010, Andy Koppe wrote:


2010/1/1 Thomas Dickey:

Is Cygwin also specifying a meta key?

(some people equate meta==alt, though they're not necessarily the same)


I don't know whether there's ever been an official policy decision on
that, but I think the general assumption among Cygwin users is that
Alt==Meta, since of course PC keyboards don't have a Meta key yet lots
of programs expect one.

I realise that in X it is possible to map a different key to Meta, but
the altIsNotMeta setting is off by default in Cygwin's xterm. Also,
the Cygwin console, rxvt, and mintty (via PuTTY) assume that Alt is
Meta (and they all encode it as Escape by default).


iirc, Cygwin console (unless something's changed in 1.7) and rxvt don't 
actually do the meta function as described in the terminfo manpage, e.g.,


   If  the  terminal has a ``meta key'' which acts as a shift key, setting
   the 8th bit of any character transmitted, this fact  can  be  indicated
   with  km.   Otherwise,  software will assume that the 8th bit is parity
   and it will usually be cleared.  If strings exist to turn  this  ``meta
   mode'' on and off, they can be given as smm and rmm.

Rather, they're assuming that meta is a way to put an escape character in 
front of other keys.  That's reflected in readline's manpage:


   An emacs-style notation is used to denote keystrokes.  Control keys are
   denoted  by C-key, e.g., C-n means Control-N.  Similarly, meta keys are
   denoted by M-key, so M-x means Meta-X.  (On keyboards  without  a  meta
   key,  M-x means ESC x, i.e., press the Escape key then the x key.  This
   makes ESC the meta prefix.  The combination M-C-x means  ESC-Control-x,
   or  press the Escape key then hold the Control key while pressing the x
   key.)

however (same manpage)

   convert-meta (On)
  If  set  to On, readline will convert characters with the eighth
  bit set to an ASCII key sequence by stripping the eighth bit and
  prefixing  it  with an escape character (in effect, using escape
  as the meta prefix).

...

   input-meta (Off)
  If set to On, readline will enable eight-bit input (that is,  it
  will  not  clear  the  eighth  bit  in the characters it reads),
  regardless of what the terminal claims it can support.  The name
  meta-flag is a synonym for this variable.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Alt key not recognized as Meta in xterm

[Thomas Dickey]

On Fri, 1 Jan 2010, Andy Koppe wrote:


   XTerm*vt100.metaSendsEscape: true


Actually that's not a hack, but the correct solution. I think this
needs to be part of the default config in /etc/X11/app-defaults/XTerm.


However, the reason that it's not is because there's no standard for
the meta key assignment.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: X11R7.5 and C.UTF-8

[Thomas Dickey]

On Thu, 3 Dec 2009, Eric Blake wrote:


Thomas Dickey dickey at his.com writes:


This means that characters 0..127 have to be treated as ASCII, but


No, it means that portable characters and control characters must be  128.
ASCII meets this characteristic, but so does EBCDIC, as well as UTF-8.  The C
locale also implies that you can manipulate bytes = 128 in the naive manner,
so long as you don't care about characters embedded in those bytes.  And what
do you know - ASCII, EBCDIC, and UTF-8 all meet this property, too.


beyond that an implementation can do what it wants. And on Cygwin 1.7,
plain C actually does imply UTF-8, which happily is
backward-compatible with ASCII.


That's an interpretation that so far hasn't been blessed by the standards
people.  Any discussion of this topic should mention that, as a caveat.


Actually, the standards people HAVE spoken - and they agreed with our
interpretation.  POSIX was INTENTIONALLY written with the intent that a UTF-8
encoding is valid for the C locale, for the same reason that it was written
that an EBCDIC encoding is valid for the C locale.  These emails from the
Austin Group (the folks that write POSIX) are telling:

https://www.opengroup.org/sophocles/show_mail.tpl?
CALLER=show_archive.tplsource=Llistname=austin-group-lid=12982


This is basically your email on the matter.


https://www.opengroup.org/sophocles/show_mail.tpl?
CALLER=show_archive.tplsource=Llistname=austin-group-lid=13012

But they also admitted that there is still more work needed in POSIX to make
this intent clearly codified (for example, that control characters must be
single bytes  128).


But they have not actually agreed with you yet.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: X11R7.5 and C.UTF-8

[Thomas Dickey]

On Thu, 3 Dec 2009, Andy Koppe wrote:


2009/12/3 Linda Walsh:

C.UTF_8 doesn't exist.

...

You can't have C and UTF-8, because C means no encoding (default).
UTF-8 IS an encoding, so they are mutually exclusive.


From http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html,
§7.2:

The tables in Locale Definition describe the characteristics and
behavior of the POSIX locale for data consisting entirely of
characters from the portable character set and the control character
set. For other characters, the behavior is unspecified.

This means that characters 0..127 have to be treated as ASCII, but
beyond that an implementation can do what it wants. And on Cygwin 1.7,
plain C actually does imply UTF-8, which happily is
backward-compatible with ASCII.


That's an interpretation that so far hasn't been blessed by the standards
people.  Any discussion of this topic should mention that, as a caveat.

ymmv

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm not working

[Thomas Dickey]

On Mon, 30 Nov 2009, Andy Koppe wrote:


2009/11/30 Thomas Dickey:

  Gone for Thanksgiving break, return and update cygwin, and now xterm
does not show anymore.  I have not upgraded to the latest 1.7 (I am waiting
for the official release).  I read the other messages and nothing seems to
work.

  Does anyone have a SIMPLE solution to this problem.


Downgrade the termcap package until there is another update thereto.


I didn't see that one (what was the issue?)


The latest termcap, which was automatically generated from terminfo,
has entries longer than 1K in it.


ok... (I thought cygwin was using GNU termcap, which supposedly works
with longer entries - though I recall _that_ being fixed more than once).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm not working

[Thomas Dickey]

On Mon, 30 Nov 2009, Andy Koppe wrote:


2009/11/30 Thomas Dickey:

  Gone for Thanksgiving break, return and update cygwin, and now xterm
does not show anymore.  I have not upgraded to the latest 1.7 (I am waiting
for the official release).  I read the other messages and nothing seems to
work.

  Does anyone have a SIMPLE solution to this problem.


Downgrade the termcap package until there is another update thereto.


I didn't see that one (what was the issue?)


The latest termcap, which was automatically generated from terminfo,
has entries longer than 1K in it.


btw, infocmp -Cr should limit that by default, unless -T option is added

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: checkX problems

[Thomas Dickey]

On Fri, 27 Nov 2009, Lothar Brendel wrote:


Thomas Dickey wrote:

On Thu, 26 Nov 2009, Lothar Brendel wrote:


[...]


Hence, to make Cygwin/X+xterm run out of the box (using
the start menu shortcut), you have to install the CJK fonts. One
more noob-question,


otoh, (discarding run-out-of-the-box, since that doesn't give a good
solution),


What's wrong with it running out-of-the-box? For somebody new to Cygwin it's 
a positive experience when the XWin Server shortcut actually opens an 
xterm.


out-of-the-box apparently doesn't include the small fix to make it work
with Cygwin's configuration.  (It wouldn't be in upstream since that would
potentially break other packages which can add localized menus, and 
there doesn't appear to be a programmatic way for xterm to decide if it 
should apply the workaround).


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: checkX problems

[Thomas Dickey]

On Thu, 26 Nov 2009, Lothar Brendel wrote:


Charles Wilson wrote:

Lothar Brendel wrote:

Unfortunately the situatiuon with ``startxwin.bat'' is worse now:

* ``checkX -t 12'' still doesn't wait (?!?)


I can't reproduce this.


Stupid me, sorry. When updating to pull in libustr1, run2 was accidently 
reverted to 0.3.0-1.




* After again inserting a sleep between checkXing and starting the
xterm, the latter is marginally successful: The process is shown as
running but no xterm is showing up :-(


That's an xterm/XWin issue.


Errh, yes. Hence, to make Cygwin/X+xterm run out of the box (using the start 
menu shortcut), you have to install the CJK fonts. One more noob-question,


otoh, (discarding run-out-of-the-box, since that doesn't give a good 
solution), see the comment here about menuLocale:


http://invisible-island.net/xterm/xterm.log.html#xterm_224

sorry: Which font-package does provide the CJK fonts? I tried several ones 
but up to now in vain.


Ciao
  Lothar


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/




--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Problem with new xinit - console window doesn't open (but bash starts)

[Thomas Dickey]

On Sun, 22 Nov 2009, Jon TURNEY wrote:


On 20/11/2009 04:07, Jim Reisert AD1C wrote:

More info:

If I run startxwin.bat from a CMD.exe command line, the bash console
xterm opens just fine. I only have problems starting it from the shortcut.


This is typical of the current issue we have where 'run xterm' blocks when 
xterm tries to output 'Warning: Missing charsets in String to FontSet 
conversion'


Any one of:
- installing the CJK fonts
- having 'tty' in the CYGWIN environment variable
- having the LANG environment set to a non-UTF-8 locale
should work around this problem


...or perhaps setting xterm's menuLocale resource to C


Warning: Missing charsets in String to FontSet conversion


This is xterm warning that the fontset has no fonts for CJK locales (as no 
CJK fonts are installed)


iirc, that's from the Xaw initialization, which asks X11 (library),
and _that_ falls into a hole where someone decided to load a fontset.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: X11R7.5 and C.UTF-8

[Thomas Dickey]

On Wed, 28 Oct 2009, Ken Brown wrote:


X11R7.5 doesn't like the (default) locale C.UTF-8.  If I start the server


technically speaking, there's no such locale as C.UTF-8,
so I'd not expect portable code to accept it (C and UTF-8 are
mutually exclusive).

with 'LANG=C.UTF-8 /usr/bin/startxwin.bat', the server exits immediately, and 
the log has complaints about the locale.  If I instead use 
'LANG=en_US.UTF-8', there's no problem.  I've attached both logs and cygcheck 
output.


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Scripting xterm and binding menu items

[Thomas Dickey]

On Tue, 13 Oct 2009, phi...@free.fr wrote:


Hi,

can xterm be scripted, in particular the menus?

I would like to associate a key bind to the Clear Saved Lines menu item. How 
can I do that?


That would be done via resource settings (not exactly a script),
using the translations resource.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm utf8 cyrillic

[Thomas Dickey]

On Sat, 1 Aug 2009, KMiller wrote:



I'm trying to set up xterm to handle output from mysql queries that contains
cyrillic.  I had success when I 1) did not specify a font in .Xdefaults
2) selected UTF-8 under VT FONTS

Under those conditions, the cyrillic characters print and all is good.

But, no matter what I do in .xDefaults, I can not enable xterm to duplicate
that behaviour by default.  I always have to manually do the above steps.

Any ideas/advice on making this the default?


well... (not having that particular configuration at hand, but able
to explain): selecting UTF-8 under the VT Fonts tells xterm to do
two things:

a) switch the character-encoding from ISO-8859-1 (or whatever)
   to UTF-8, which corresponds to the utf8 resource setting.

b) select the font from (unless overridden) the utf8Fonts
   resources.  Having a resource like *font:fixed would
   override that, due to the wildcard.

So it might be as simple as setting the utf8 resource in .Xdefaults:

*utf8: 2

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Audible bell broken in bash/xterm

[Thomas Dickey]

On Thu, 16 Jul 2009, j...@asyn.org wrote:



I've installed Cygwin/X on both XP Pro and laVista Home Basic systems and
the bell doesn't work. The bell does work in a console window but not in
an xterm. Am I missing something or is this a bug? How is the BEL char
[supposed to be] routed through bash/xterm/XWin to create the audible
response? Both systems are fresh installs (as of last week) with no config
changes or errors during the installs.


What's xterm -v say?

Audible bell was broken in #242, and fixed in #243.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Audible bell broken in bash/xterm

[Thomas Dickey]

On Thu, 16 Jul 2009, Jim Reisert AD1C wrote:


Mine says (242).  There is no more recent (non-experimental) version
available from Cygwin 1.7 setup.


I don't have any influence on Cygwin's setup.  (You may be able to select
an older version - I'd just compile my own copy of xterm though).



On Thu, Jul 16, 2009 at 3:42 PM, Thomas Dickeydic...@his.com wrote:

On Thu, 16 Jul 2009, j...@asyn.org wrote:



I've installed Cygwin/X on both XP Pro and laVista Home Basic systems and
the bell doesn't work. The bell does work in a console window but not in
an xterm. Am I missing something or is this a bug? How is the BEL char
[supposed to be] routed through bash/xterm/XWin to create the audible
response? Both systems are fresh installs (as of last week) with no config
changes or errors during the installs.


What's xterm -v say?

Audible bell was broken in #242, and fixed in #243.



--
Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/




--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Audible bell broken in bash/xterm

[Thomas Dickey]

On Thu, 16 Jul 2009, Yaakov (Cygwin/X) wrote:


On 16/07/2009 16:42, Thomas Dickey wrote:

What's xterm -v say?

Audible bell was broken in #242, and fixed in #243.


Looks like I missed that.  I'll upload 243-1 soon.


thanks.

The only other regression that I know of is a repainting bug (fixed
after I'd started a large rewrite...).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Cannot convert string nil2 to type FontStruct, was: post-upgrade problems

[Thomas Dickey]

On Sun, 28 Jun 2009, Tom Roche wrote:


Despite installing package=font-misc-misc (recommended by

http://cygwin.com/cgi-bin2/package-grep.cgi?grep=nil2

) via setup.exe, everytime I start an xterm I get


Warning: Cannot convert string nil2 to type FontStruct


nil2 is used for the pointerMode feature - I'd try setting the pointerMode
resource to zero, e.g.,

*pointerMode: 0

in your resource settings.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm Home/End keycodes

[Thomas Dickey]

On Sat, 14 Mar 2009, Andy Koppe wrote:


I'm a bit confused about those. They didn't change during the xorg
transition, did they? I could have sworn they sent VT220-style ^[[1;
and ^[[4; but actually they send PC-style ^[[H and ^[[F. Of course I
should have realised this when I changed F1 to F4 to PC-style codes in
MinTTY ...


PC-style is the upstream default (I don't recall whether cygwin's
older package modified the app-defaults files).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm Home/End keycodes

[Thomas Dickey]

On Sun, 15 Mar 2009, Andy Koppe wrote:


2009/3/15 Thomas Dickey dic...@his.com:

I'm a bit confused about those. They didn't change during the xorg
transition, did they? I could have sworn they sent VT220-style ^[[1;
and ^[[4; but actually they send PC-style ^[[H and ^[[F. Of course I
should have realised this when I changed F1 to F4 to PC-style codes in
MinTTY ...


PC-style is the upstream default (I don't recall whether cygwin's
older package modified the app-defaults files).


Thanks, I think my confusion actually stemmed from starting with PuTTY
code, which sends VT220-style keys when set to Xterm mode.


I tend to ignore PuTTY's keyboard options, since they don't really
match xterm's options.


I note that Debian uses PC-style too. Is this issue fairly settled
then, i.e. do most systems use the PC-style keycodes for their xterm
terminfo entries?


PC-style's the default since a long time ago when the keyboard tables were 
constructed for the PC keyboards.


I implemented the VT220-style editing-keypad as something that could 
change from that default, but (aside from one of the terminfo's several 
years ago using VT220), xterm's used the PC-style since I've been working 
on it in 1996.


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Saving all xterm output to a file

[Thomas Dickey]

On Sat, 7 Feb 2009, Gary Johnson wrote:


../run 1 Joiner default 21  results.dat


I think that has to be written this way:

   ../run 1 Joiner default  results.dat 21

But if you (the OP) wants to see what's going into that file, you
should tee, like this:

   ../run 1 Joiner default 21 | tee results.dat


hmm - yes (I had at hand a script which does the latter, and couldn't
recall the detail needed for the former, which seemed to be what OP 
requested).


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Saving all xterm output to a file

[Thomas Dickey]

On Sat, 7 Feb 2009, teddybouch wrote:


I am trying to automate a simulation process, and part of this involves
capturing the output that is written to an xterm window when a particular
process is run. I thought that I had this figured out using the following
command:

../run 1 Joiner default  results.dat


fwiw, this isn't specific to X...


run is the program that I am running and want to catch the output of. 1,
Joiner, and default are parameters needed by that program. results.dat
is the file that I want the output written to. It was working alright, but
then I realized that it wasn't getting all the output that ought to be
there. Now, it has progressed to the point that I'm not getting any of the
printout statements at all - they don't appear in the xterm window or in the
file.


Perhaps you're looking for the messages written to stderr.
For that you need to redirect stderr as well, e.g.,

../run 1 Joiner default 21  results.dat

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xterm line wrapping

[Thomas Dickey]

On Tue, Dec 09, 2008 at 10:57:53AM -0500, Gustavo Seabra wrote:
 Hi All,
 
 I wonder if anyone else sees this. When I open an xterm, it all works
 fine with the default dimensions. But if I resize the terminal, line
 wrapping stops working until I return to the initial size. This was
 present in the old xterm, and persists after upgrading to the new one.

that sounds like the feature in bash which makes it not pass on the
SIGWINCH signal, depending on bash's settings.  (I should add it to
my ncurses faq, since the bash maintainer doesn't answer this question)
 
 Interestingly, if I have a file opened in vi when resizing, vi works
 quite well and wraps the lines correctly according to the terminal
 size. But when I get out of vi I get the same problems back :-(

vi is probably doing the ioctl to check on the screensize...

-- 
Thomas E. Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: Bad XTerm Vim coloring

[Thomas Dickey]

On Tue, 25 Nov 2008, Nick Deubert wrote:


On Mon, Nov 24, 2008 at 6:44 PM, Thomas Dickey [EMAIL PROTECTED] wrote:

Rereading your email, I also tried with .vimrc having
just

set syntax=on
set background=dark

but aside from seeing that the syntax coloring went away, didn't see
any change in the result - no +r in the script output.


set syntax=on should be syntax on which is probably why you saw no
syntax highlighting. The set syntax= just sets the file type. Is
there anything else you want me to try? Build xterm from source maybe
with different configure options? Thanks for your help Thomas.


well, building xterm without the tcap-query option should immediately
solve the problem...

I don't know if vim has been using this feature of xterm with cygwin -
it may be that there's some unexpected time-delay or buffer-problem.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Bad XTerm Vim coloring

[Thomas Dickey]

On Mon, 24 Nov 2008, Nick Deubert wrote:


Hey everyone,
First off thanks for your hard work on cygwin/X it is very
appreciated. I upgraded to the new Xorg last week and I have had one
really annoying issue ever since. Something about the new XTerm is
messing up vim syntax coloring. With vim I have syntax on and
background=dark and usually the coloring look like this:
http://nd.dyndns.org:443/downloads/correct_coloring.PNG but now when I
open a file in vim it looks like that for a split second then a ton of
gibberish quickly scrolls in the right side of the vim ruler and when
it stops my syntax is colors are all messed up and are colored like
this: http://nd.dyndns.org:443/downloads/bad_coloring.PNG

Now I think this is a problem with XTerm not vim because when I ssh


I can't tell - but you can capture the output of vim using 'script' and
we can inspect the output of vim, to see if it is well-formed.

(While it's possible that cygwin's xterm is configured with different
options than on some other system, xterm should ignore - not echo -
well-formed control sequences that it doesn't understand).


into other machines and run vim there, with different configuration
files, the same thing happens. Also if I remove my .vimrc and start
vim, and manually do :syntax on and :set background=dark it seems
fine. It seems like there could be something going on with the inital
opening of vim and it talking to the xterm that is going weird. Also


vim may talk to xterm to find what the function-keys send (I added a few
new keys in the last version or so, but vim shouldn't be confused by
that...).  Seeing exactly what was written to the xterm would give some
clues - along with finding what configure options were used to build
the cygwin package for xterm.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Bad XTerm Vim coloring

[Thomas Dickey]

On Mon, 24 Nov 2008, Nick Deubert wrote:


On Mon, Nov 24, 2008 at 2:58 PM, Thomas Dickey [EMAIL PROTECTED] wrote:

On Mon, 24 Nov 2008, Nick Deubert wrote:


Hey everyone,
First off thanks for your hard work on cygwin/X it is very
appreciated. I upgraded to the new Xorg last week and I have had one
really annoying issue ever since. Something about the new XTerm is
messing up vim syntax coloring. With vim I have syntax on and
background=dark and usually the coloring look like this:
http://nd.dyndns.org:443/downloads/correct_coloring.PNG but now when I
open a file in vim it looks like that for a split second then a ton of
gibberish quickly scrolls in the right side of the vim ruler and when
it stops my syntax is colors are all messed up and are colored like
this: http://nd.dyndns.org:443/downloads/bad_coloring.PNG

Now I think this is a problem with XTerm not vim because when I ssh


I can't tell - but you can capture the output of vim using 'script' and
we can inspect the output of vim, to see if it is well-formed.


I attached a vim.out(or you can get it here if you don't like


short: I don't know...
long: continue reading...

I made that readable with the 'unmap' program in my ncurses ftp-directory.
The problem is visible in the trace (though where the ultimate cause is,
is not yet clear).  Looking for the +r, I see that is part of a control
sequence without the leading escape-character, e.g.,

\E[80;226H6
\E[1;5H
\E[80;227Hf
\E[1;5H
\E[80;218H[P1+r436f=
\E[1;5H

where \E's are escapes as in terminfo.  The \E's ending with H are 
cursor movement, so this fragment is sending something like


6f[P1+r436f=

I'd expect that vim is asking xterm for the strings that correspond to
different function-keys.  In ctlseqs.txt this text covers the response:

  xterm responds with DCS 1 + r Pt ST for valid requests, adding
  to Pt an = , and the value of the corresponding string that
  xterm would send, or DCS 0 + r Pt ST for invalid requests.
  The strings are encoded in hexadecimal (2 digits per charac-
  ter).

But DCS is missing (that would be \EP rather than [P).  And the text
in vim.out is the text that xterm would be replying with.  The 436f
is hex-encoded for Co (termcap number of colors).  Earlier in the
trace, vim has sent the control sequence asking for this information, e.g.

\EP+q436f
\E\\

On my Debian/testing, I've got vim 7.1.314, which is sending the same 
control sequence (and running xterm's test-script, I know that it's 
responding as I'd expect). There's no +r in a script running vim in 
xterm _here_.  Rereading your email, I also tried with .vimrc having

just

set syntax=on
set background=dark

but aside from seeing that the syntax coloring went away, didn't see
any change in the result - no +r in the script output.


attachments: http://nd.dyndns.org:443/downloads/vim.out) which is what
script outputted for this small test.c file:
int main() {
  char* blah = blah\n;
  return 0;
}



(While it's possible that cygwin's xterm is configured with different
options than on some other system, xterm should ignore - not echo -
well-formed control sequences that it doesn't understand).

vim may talk to xterm to find what the function-keys send (I added a few
new keys in the last version or so, but vim shouldn't be confused by
that...).  Seeing exactly what was written to the xterm would give some
clues - along with finding what configure options were used to build
the cygwin package for xterm.


I'm not sure how to see the configure options for xterm. It is the
binary package 237-2 installed from mirrors.kernel.org.

Just in case it means anything here is the vim configure options:
:version
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Oct  9 2008 15:23:22)
Compiled by [EMAIL PROTECTED]
Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset
+cindent -clientserver
-clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +cursorshape
+dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra
+extra_search +farsi
+file_in_path +find_in_path +float +folding -footer +fork() +gettext
-hangul_input +iconv
+insert_expand +jumplist +keymap +langmap +libcall +linebreak
+lispindent +listcmds +localmap +menu
+mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm
-mouse_jsbterm +mouse_netterm
-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme
-netbeans_intg -osfiletype
+path_extra -perl +postscript +printer +profile -python +quickfix
+reltime +rightleft -ruby
+scrollbind +signs +smartindent -sniff +statusline -sun_workshop
+syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse
+textobjects +title -toolbar
+user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore
+wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
-xterm_clipboard -xterm_save
  system vimrc file: $VIM/vimrc

Re: Bad XTerm Vim coloring

[Thomas Dickey]

On Mon, 24 Nov 2008, Thomas Dickey wrote:


I'd expect that vim is asking xterm for the strings that correspond to
different function-keys.  In ctlseqs.txt this text covers the response:


...reading vim's source code (7.1 at hand...), there doesn't seem to be an 
obvious way to turn off the feature (the +termresponse).


However, it seems that vim is only asking for this information when it is 
not finding the details it wants in the _termcap_ (and since vim is 
apparently using terminfo, which gives an empty buffer, it'll always ask 
for the information).


Cygwin's xterm package (doing a strings on the binary) appears to be 
linked with termcap - but if it cannot find a termcap, it'll fallback to 
something possibly incomplete or inaccurate.  (I'm not sure what that

would be, but was interested to note that the strings on xterm showed
there's a termcap for cygwin;-).


Just in case it means anything here is the vim configure options:
:version
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Oct  9 2008 15:23:22)

...

+tag_old_static -tag_any_white -tcl +terminfo +termresponse

   ^^^

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: libXaw8 replacement

[Thomas Dickey]

On Sat, 22 Nov 2008, Ken Brown wrote:


On 11/14/2008 1:20 PM, Yaakov (Cygwin Ports) wrote:


BTW, this looks like the package is using a VERY old version of libtool.
 I strongly recommend using the current version, which generally can be
pulled in with autoreconf.


I tried autoreconf --force in the top-level source directory of texlive and 
got several warnings and one error:


configure:5043: error: possibly undefined macro: AC_DIVERT_HELP
 If this token and others are legitimate, please use m4_pattern_allow.

I assume I have to say 'm4_pattern_allow AC_DIVERT_HELP' somewhere, but 
where?


How important is it to run autoreconf?  Could the fact that the package uses 
an old version of libtool explain the segfault that I reported in 
http://cygwin.com/ml/cygwin-xfree/2008-11/msg00214.html ?


no - it's one of the changes made to autoconf, rather than libtool

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: Fixing problems with new X11

[Thomas Dickey]

On Thu, 13 Nov 2008, Chuck wrote:


Second, I want to get rid of the toolbar/menu at the top of every xterm.
What config file change to I need to make to get rid of it permanently.
I don't want to have to specify +tb every time I run an xterm. I tried
adding xterm*toolbar: false to my ~/.XDefaults files but that didn't work.


I'd use the classname (XTerm) rather than the application name (xterm).

Also, it's possible that the packager set a corresponding resource
someplace (or there's some session resources interfering with the 
.XDefaults).  appres XTerm would show some of that...


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/