Re: Following update to XWin or xorg-server: changed syntax to get a xterm terminal window
Michael DePaulo gmail.com> writes: |On Wed, Jun 10, 2015 at 7:28 AM, Fergus Daly | frontier-science.co.uk> wrote: |> For ages I used |> XWin -nolock -nolisten local -multiwindow & |> xterm -display localhost:0.0 |> to get a xterm terminal. |> Following recent updates I get a fatal error: "Cannot establish any |> listening sockets." In the past, updates to XWin have sometimes led |> to similar difficulties, but I have always managed to iterate to a |> new successful joint syntax |> XWin |> xterm | By default, XWin 1.17 no longer listens on TCP sockets, only on unix | domain sockets. | https://www.cygwin.com/ml/cygwin-announce/2015-06/msg3.html | However, "-nolisten local" disables unix domain sockets., | So to use unix domain sockets: | XWin -nolock -multiwindow & | xterm -display :0.0 | Or to keep using TCP sockets: | XWin -nolock -nolisten local -listen tcp -multiwindow & | xterm -display localhost:0.0 I found that I also had to rejig my ~/.startxwinrc. ~/.startxwinrc: --- xrdb -load $HOME/.Xresources xterm -display :0.0 # xterm & exec sleep infinity -- 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/
Following update to XWin or xorg-server: changed syntax to get a xterm terminal window
For ages I used XWin -nolock -nolisten local -multiwindow xterm -display localhost:0.0 to get a xterm terminal. Following recent updates I get a fatal error: Cannot establish any listening sockets. In the past, updates to XWin have sometimes led to similar difficulties, but I have always managed to iterate to a new successful joint syntax XWin arguments xterm arguments but this time I am totally stymied. Can anybody offer me a working syntax please? Thank you. Fergus -- 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: Following update to XWin or xorg-server: changed syntax to get a xterm terminal window
On Wed, Jun 10, 2015 at 7:28 AM, Fergus Daly ferg...@frontier-science.co.uk wrote: For ages I used XWin -nolock -nolisten local -multiwindow xterm -display localhost:0.0 to get a xterm terminal. Following recent updates I get a fatal error: Cannot establish any listening sockets. In the past, updates to XWin have sometimes led to similar difficulties, but I have always managed to iterate to a new successful joint syntax XWin arguments xterm arguments but this time I am totally stymied. Can anybody offer me a working syntax please? Thank you. Fergus By default, XWin 1.17 no longer listens on TCP sockets, only on unix domain sockets. https://www.cygwin.com/ml/cygwin-announce/2015-06/msg3.html However, -nolisten local disables unix domain sockets., So to use unix domain sockets: XWin -nolock -multiwindow xterm -display :0.0 Or to keep using TCP sockets: XWin -nolock -nolisten local -listen tcp -multiwindow xterm -display localhost:0.0 -Mike -- 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: Disable xterm auto-wrap: Mess up vi-like command line
Paul wrote: If I disable auto-wrap, the vi editing at the comand line misbehaves when the line being edited is long, especially when yanking a lot of text and pasting it. I suppose that this might be technically correct behaviour, since an extra long command line needs to wrap in order to see it properly. But I use the vi command line exclusively, and almost always, I don't want autowrap in the results from commands being sent to the screen. Is there a way to get both at the same time, without having to always toggle the xterm autowrap? --- What do you mean by mess up? It shouldn't. I just cut and pasted some text from an xterm into an editor, and the lines weren't split... they got copied as one line. However, if I was to cut from a Windows Console window (cmd.exe for example), it DOES, physically, split long lines. It's a property of the console. The main problem I've seen in bash is when you paste content that has tabs in it. Then bash tries to auto complete in the middle of your typing... often asking a question or pausing -- which means it *swallows* up the tab and 1-2 keys after the tab. It didn't use to do this back in the 3.x series, but was added as a new feature in the 4.x series. I ended up changing my completion character to BACKQUOTE to try to get around this. Maybe tabs are causing your problem? Example. At a prompt, I typed: cat CR completion char (I hit enter after that first quote and went to the next line and hit my completion char (BACKQUOTE `), Then I got: cat Display all 186 possibilities? (y or n) --- At this point, whatever character is next in my paste buffer will be swallowed up (in addition to the completion character). --- Since the long line cut/paste worked for me in 'xterm', that's why I thought maybe you were hitting bash'es input mangling-feature!... -- 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/
Disable xterm auto-wrap: Mess up vi-like command line
If I disable auto-wrap, the vi editing at the comand line misbehaves when the line being edited is long, especially when yanking a lot of text and pasting it. I suppose that this might be technically correct behaviour, since an extra long command line needs to wrap in order to see it properly. But I use the vi command line exclusively, and almost always, I don't want autowrap in the results from commands being sent to the screen. Is there a way to get both at the same time, without having to always toggle the xterm autowrap? -- 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/
[ANNOUNCEMENT] Updated: xterm-313-1
The following package has been updated in the Cygwin distribution: *** xterm-313-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 -- 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: Resize a Cygwin64 xterm on Windows 7 64-bit jumps in increments of two or three columns
On Thu, 2014-07-31 at 10:33 -0400, C Linus Hicks wrote: On Thu, 2014-07-31 at 12:45 +0100, Jon TURNEY wrote: On 30/07/2014 19:04, C Linus Hicks wrote: I have run Cygwin on multiple versions of Windows including recently on Windows XP and don't think I ever had this problem. Resizing or specifying a geometry always resulted in the exact number of columns requested, with increments of 1 column being available when dragging the borders of a window to resize. Now, after upgrading to Windows 7 64-bit, I cannot get the window to have 80 columns on resize. It jumps in increments of two or three, depending on the number of columns prior to resizing. For example: Thanks for reporting this problem. I think this may be resolved by a fix Correctly interpret WM_HINTS, WM_NORMAL_HINTS properties on x86_64 I made in 1.15.1-3 [1]. Can you please test with the latest version? Should I be able to resize by increments of one column? Yes Yes, I will try that within the next day or so. Thanks. Updated to latest as of 30 minutes ago and it allows me to resize at any column width. Thanks for your help. -- 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: Resize a Cygwin64 xterm on Windows 7 64-bit jumps in increments of two or three columns
On 30/07/2014 19:04, C Linus Hicks wrote: I have run Cygwin on multiple versions of Windows including recently on Windows XP and don't think I ever had this problem. Resizing or specifying a geometry always resulted in the exact number of columns requested, with increments of 1 column being available when dragging the borders of a window to resize. Now, after upgrading to Windows 7 64-bit, I cannot get the window to have 80 columns on resize. It jumps in increments of two or three, depending on the number of columns prior to resizing. For example: Thanks for reporting this problem. I think this may be resolved by a fix Correctly interpret WM_HINTS, WM_NORMAL_HINTS properties on x86_64 I made in 1.15.1-3 [1]. Can you please test with the latest version? Should I be able to resize by increments of one column? Yes [1] https://cygwin.com/ml/cygwin-xfree/2014-06/msg00017.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: Resize a Cygwin64 xterm on Windows 7 64-bit jumps in increments of two or three columns
On Thu, 2014-07-31 at 12:45 +0100, Jon TURNEY wrote: On 30/07/2014 19:04, C Linus Hicks wrote: I have run Cygwin on multiple versions of Windows including recently on Windows XP and don't think I ever had this problem. Resizing or specifying a geometry always resulted in the exact number of columns requested, with increments of 1 column being available when dragging the borders of a window to resize. Now, after upgrading to Windows 7 64-bit, I cannot get the window to have 80 columns on resize. It jumps in increments of two or three, depending on the number of columns prior to resizing. For example: Thanks for reporting this problem. I think this may be resolved by a fix Correctly interpret WM_HINTS, WM_NORMAL_HINTS properties on x86_64 I made in 1.15.1-3 [1]. Can you please test with the latest version? Should I be able to resize by increments of one column? Yes Yes, I will try that within the next day or so. Thanks. -- 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/
Resize a Cygwin64 xterm on Windows 7 64-bit jumps in increments of two or three columns
I have run Cygwin on multiple versions of Windows including recently on Windows XP and don't think I ever had this problem. Resizing or specifying a geometry always resulted in the exact number of columns requested, with increments of 1 column being available when dragging the borders of a window to resize. Now, after upgrading to Windows 7 64-bit, I cannot get the window to have 80 columns on resize. It jumps in increments of two or three, depending on the number of columns prior to resizing. For example: $ tput cols 66 xx50283@PP75W9D0R1 ~ $ tput cols 69 xx50283@PP75W9D0R1 ~ $ tput cols 71 xx50283@PP75W9D0R1 ~ $ tput cols 73 xx50283@PP75W9D0R1 ~ $ tput cols 75 xx50283@PP75W9D0R1 ~ $ tput cols 77 xx50283@PP75W9D0R1 ~ $ tput cols 79 xx50283@PP75W9D0R1 ~ $ tput cols 82 xx50283@PP75W9D0R1 ~ $ tput cols 84 Each one of those was queried after dragging the right-hand edge of the window by the smallest it would change. I don't know if it is related, but there is also several pixels (I would say around 20) gap between the window manager border decoration and the parts of the display presented by xterm. I did alter from the default Windows config for the desktop, because I don't want the large default borders. I set Border Padding to have a value of zero. Should I be able to resize by increments of one column? I have attached cygcheck output as requested in problem reporting guidelines, and also /var/log/xwin/XWin.0.log files. Thanks for any help. Linus Cygwin Configuration Diagnostics Current System Time: Wed Jul 30 17:33:27 2014 Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1 Running in Terminal Service session Path: C:\Users\xx50283\cygwin64\usr\local\bin C:\Users\xx50283\cygwin64\bin C:\Oracle\product\11.2.0\client_1\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\1E\NomadBranch C:\Program Files (x86)\BlueZone\6.1 C:\Users\xx50283\cygwin64\home\xx50283\bin Output from C:\Users\xx50283\cygwin64\bin\id.exe UID: 2123645(xx50283) GID: 10513(Domain Users) 10513(Domain Users) 555(Remote Desktop Users) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'xx50283' PWD = '/home/xx50283' HOME = '/home/xx50283' USERDOMAIN_ROAMINGPROFILE = 'PNCNT' HOMEPATH = '\' MANPATH = ':/usr/ssl/man' APPDATA = 'C:\Users\xx50283\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'PP75W9D0R1' SHELL = '/bin/bash' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 42 Stepping 7, GenuineIntel' PROFILEREAD = 'true' WINDIR = 'C:\WINDOWS' WINDOWID = '37748766' PUBLIC = 'C:\Users\Public' ORIGINAL_PATH = '/cygdrive/c/Oracle/product/11.2.0/client_1/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files (x86)/1E/NomadBranch:/cygdrive/c/Program Files (x86)/BlueZone/6.1' USERDOMAIN = 'PNCNT' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' UATDATA = 'C:\WINDOWS\SysWOW64\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' windows_tracing_flags = '3' windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log' !:: = '::\' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'xx50283' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files\Microsoft Application Virtualization\Client\' XWINLOGFILE = '/var/log/xwin/XWin.0.log' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'en_US.UTF-8' USERPROFILE = 'C:\Users\xx50283' CLIENTNAME = 'WIN7-PNC' TZ = 'America/New_York' LOGONSERVER = '\\WSWDS325C' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'AMD64' LOCALAPPDATA = 'C:\Users\xx50283\AppData\Local' HISTCONTROL = 'ignoredups' XTERM_LOCALE = 'en_US.UTF-8' XTERM_VERSION = 'XTerm(302)' ProgramData = 'C:\ProgramData' EXECIGNORE = '*.dll' SHLVL = '3' USERDNSDOMAIN = 'PNCBANK.COM' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'L:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' LOGNAME = 'xx50283' TMP = '/tmp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'Microsoft XPS Document Writer (redirected 2)' PROCESSOR_REVISION = '2a07' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info' PROGRAMFILES = 'C:\Program Files' HOMESHARE = '\\pncbank.com\corp\Pittsburgh\Users\XX50283' DISPLAY = ':0.0' NUMBER_OF_PROCESSORS = '4' SESSIONNAME = 'RDP-Tcp#0' COMPUTERNAME = 'PP75W9D0R1' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\C:\Users\xx50283\cygwin64' HKEY_CURRENT_USER\Software\Cygwin\Program
Re: emacs holding focus, not granting it to xterm
On 6/27/2014 11:22 PM, alflanagan wrote: The problem occurs when I run emacsclient to connect to an existing instance of emacs; the file shows up in emacs and emacsclient exits as expected, but focus remains stuck in emacs for some time. I tried the following to reproduce the problem: Under Cygwin X Server Version 1.15.1-3: 1.) Start an xterm under cygwin with xserver in multiwindow mode. 2.) From this cygwin xterm log into remote linux (debian 3.2.0-4-486) machine with ssh -X. 3.) After logged in to the remote linux machine: start emacs with emacs . This opens a new X11 window under cygwin X server which is on top and has keyboard focus. 4.) In Emacs Window type the key combination Alt+X and then server-start 5.) Go back to xterm window and type: emacsclient filename to edit the file filename in the emacs-server. 6.) Now: all typing goes inte the emacs X11 window, although this window is in the background (it might even be not visible if it is behind other windows). It turns out that the above behaviour is the known problem that windows are not raised from the Cygwin X Server in multiwindow mode, if a program wants to programmatically activate a window as reported in http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html . If I start a modified xserver with my patch applied from https://cygwin.com/ml/cygwin-xfree/2011-08/msg00034.html the following happens in step 6: 6'.) the emacs window is raised to the top over all windows and gets the keyboard focus. I think that 6'.) is the expected behaviour because this also happens if running under a x server on a linux machine instead of cygwin. Best regards, Oliver -- 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 holding focus, not granting it to xterm
Brief note to demonstrate that Scherneck is not alone: I'm running cygwin x on my laptop [version 1.7.29(0.272/5/3), Windows 7 prof], start windows on remote machines (cygwin and linux mint), that are exported to my laptop. I've noted the problem for more than a year now and it's irritating still, new versions of cygwin and applications notwithstanding. I'm seeing an identical phenomenon on a Dell laptop* running Win 7 Professional, SP 1; X Server is 1.15.1 (i686-pc-cygwin). Remote system is a CentOS 5.6 box, and I'm connecting with ssh -XY user@hostname. I'm running gnome-terminal and launching emacs 24.3 from there. I'll see if I can find somewhere to post the log file. The problem occurs when I run emacsclient to connect to an existing instance of emacs; the file shows up in emacs and emacsclient exits as expected, but focus remains stuck in emacs for some time. *laptop is running BIOS A13, with HD Graphics 4000, in case it matters. -- View this message in context: http://cygwin.1069669.n5.nabble.com/emacs-holding-focus-not-granting-it-to-xterm-tp108889p109599.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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/
[ANNOUNCEMENT] Updated: xterm-308-1
The following package has been updated in the Cygwin distribution: *** xterm-308-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] Updated: xterm-305-1
The following package has been updated in the Cygwin distribution: *** xterm-305-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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 holding focus, not granting it to xterm
On 27/05/2014 12:45, Hans-Georg Scherneck wrote: I'm running cygwin x on my laptop [version 1.7.29(0.272/5/3), Windows 7 prof], start windows on remote machines (cygwin and linux mint), that are exported to my laptop. I've noted the problem for more than a year now and it's irritating still, new versions of cygwin and applications notwithstanding. Here's what happens: I enter text into emacs, move mouse to an xterm, click and enter text there, but text is going into emacs. I can only move keyboard flow away from emacs after having done some nuisance operations in the emacs window, like moving around the pointer; it mostly helps with one such instance, sometimes I have to repeat. It's rather unpredictable. The raised status of the xterm window, however, is deceiving me. So text goes even into hidden emacs windows. I can't reproduce this. Can you be a bit more specific about how you are running the X server (/var/log/xwin/XWin.0.log would be nice) and which window manager you are using? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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 holding focus, not granting it to xterm
Jon TURNEY wrote: On 27/05/2014 12:45, Hans-Georg Scherneck wrote: I'm running cygwin x on my laptop [version 1.7.29(0.272/5/3), Windows 7 prof], start windows on remote machines (cygwin and linux mint), that are exported to my laptop. I've noted the problem for more than a year now and it's irritating still, new versions of cygwin and applications notwithstanding. Here's what happens: I enter text into emacs, move mouse to an xterm, click and enter text there, but text is going into emacs. I can only move keyboard flow away from emacs after having done some nuisance operations in the emacs window, like moving around the pointer; it mostly helps with one such instance, sometimes I have to repeat. It's rather unpredictable. The raised status of the xterm window, however, is deceiving me. So text goes even into hidden emacs windows. I can't reproduce this. Can you be a bit more specific about how you are running the X server (/var/log/xwin/XWin.0.log would be nice) and which window manager you are using? Dear Jon, you can find the log at http://holt.oso.chalmers.se/hgs/4CYG/XWin.0.log The X-window manager on the linux machine ? - not sure how to answer. I log in using ssh -Y and start jobs from an xterm using command lines. I never use any GUI. uname -a says Linux holt 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux It greets me (ssh, xterm): Warning: No xauth data; using fake authentication data for X11 forwarding. Welcome to Linux Mint 13 Maya (GNU/Linux 3.2.0-23-generic x86_64) The problem only occurs with emacs (/usr/bin/emacs23-x --version says: GNU Emacs 23.3.1 ) Could it be that emacs creates a server / uses a port of its own? Do you need more information? Thanks for caring about my problem. /HGS -- Med vänliga hälsningar / With best regards yours - Hans-Georg Scherneck / A \ -+--- | / \ | . Telephone -fax | Chalmers University of Technology \ / . +46 31 772 5556| Earth and Space Sciences - . +46 31 772 5590 fx | Onsala Space Observatory | | . E-Mail:| SE-439 92 Onsala, Sweden / \ . h...@chalmers.se| http://www.chalmers.se/rss . Ocean Loading Serv.| holt.oso.chalmers.se/loading /===\ ,===//===\ . Gravimeter | holt.oso.chalmers.se/hgs/SCG//`===,// -+-\===//===' \===/ -- 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/
emacs holding focus, not granting it to xterm
I'm running cygwin x on my laptop [version 1.7.29(0.272/5/3), Windows 7 prof], start windows on remote machines (cygwin and linux mint), that are exported to my laptop. I've noted the problem for more than a year now and it's irritating still, new versions of cygwin and applications notwithstanding. Here's what happens: I enter text into emacs, move mouse to an xterm, click and enter text there, but text is going into emacs. I can only move keyboard flow away from emacs after having done some nuisance operations in the emacs window, like moving around the pointer; it mostly helps with one such instance, sometimes I have to repeat. It's rather unpredictable. The raised status of the xterm window, however, is deceiving me. So text goes even into hidden emacs windows. Vague guess: Something's waiting in emacs to get satisfied so it would release the keyboard association. I don't want focus-follows-mouse without a click for focus shift. So I haven't tried this option. Would expect it wouldn't help. Is there an environment setting that would help? Anything else to get rid of the glue? -- Med vänliga hälsningar / With best regards yours - Hans-Georg Scherneck / A \ -+--- | / \ | . Telephone -fax | Chalmers University of Technology \ / . +46 31 772 5556| Earth and Space Sciences - . +46 31 772 5590 fx | Onsala Space Observatory | | . E-Mail:| SE-439 92 Onsala, Sweden / \ . h...@chalmers.se| http://www.chalmers.se/rss . Ocean Loading Serv.| holt.oso.chalmers.se/loading /===\ ,===//===\ . Gravimeter | holt.oso.chalmers.se/hgs/SCG//`===,// -+-\===//===' \===/ -- 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 crashing when trying to access Ctrl-mouse click menu items
On 05/05/2014 19:39, Nem W Schlecht wrote: For over a month now I've been having issues with my xterms in Cygwin. If I try to access *any* menu item under the Ctrl-mouse button menu items (change font, turn on/off scrollbar, redraw window, etc.), my xterm crashes the moment I un-press my mouse button. I don't access them all that often, so I don't know how long the issue has been around, but it's been a couple of months now. I've tried launching it with an empty .Xdefaults file (home dir) and by moving my .bashrc/.bash_profile files out of the way - still the same result. I've also gone out and downloaded the latest XTerm code and have a version compiled with debugging, but my C skills are really rusty and I'm not seeing anything terribly useful in gdb (I set my CYGWIN env var to error_start=dumper -d %1 %2 so I would get core dumps). I compiled a version with a different DEFCLASS set so that I *know* it's not a bad resource or resource file. I'm running 64 bit on Windows 7. More details in the attached cygcheck.out. Anybody else on 64bit Cygwin / Win 7 having the same issues? Thanks for reporting this issue. I can reproduce it. This appears to be an issue with Xt, as a Cygwin-specific patch does not work correctly on x86_64 when another DLL which is using Xt is loaded 2GB away from it. Until we have a fix, you *might* be able to work around this by rebasing the DLLs, e.g. in the specific case of xterm, which uses Xaw: cd /usr/bin rebase -v -b 0x4 cygXt-6.dll rebase -v -b 0x41000 cygXaw-7.dll -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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 crashing when trying to access Ctrl-mouse click menu items
Thanks for the reply, Jon! I'm happy you were able to reproduce the issue - I assumed I had screwed something up in my environment. :) Your attempted fix with rebase worked perfectly - all of my menus are now working correctly. If you'd like me to do any additional testing in the future, don't hesitate to ask. On Mon, May 12, 2014 at 5:34 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 05/05/2014 19:39, Nem W Schlecht wrote: For over a month now I've been having issues with my xterms in Cygwin. If I try to access *any* menu item under the Ctrl-mouse button menu items (change font, turn on/off scrollbar, redraw window, etc.), my xterm crashes the moment I un-press my mouse button. I don't access them all that often, so I don't know how long the issue has been around, but it's been a couple of months now. I've tried launching it with an empty .Xdefaults file (home dir) and by moving my .bashrc/.bash_profile files out of the way - still the same result. I've also gone out and downloaded the latest XTerm code and have a version compiled with debugging, but my C skills are really rusty and I'm not seeing anything terribly useful in gdb (I set my CYGWIN env var to error_start=dumper -d %1 %2 so I would get core dumps). I compiled a version with a different DEFCLASS set so that I *know* it's not a bad resource or resource file. I'm running 64 bit on Windows 7. More details in the attached cygcheck.out. Anybody else on 64bit Cygwin / Win 7 having the same issues? Thanks for reporting this issue. I can reproduce it. This appears to be an issue with Xt, as a Cygwin-specific patch does not work correctly on x86_64 when another DLL which is using Xt is loaded 2GB away from it. Until we have a fix, you *might* be able to work around this by rebasing the DLLs, e.g. in the specific case of xterm, which uses Xaw: cd /usr/bin rebase -v -b 0x4 cygXt-6.dll rebase -v -b 0x41000 cygXaw-7.dll -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Nem W Schlecht n...@emptec.com Empyreal Technologieshttp://www.emptec.com/ Perl did the magic. I just waved the wand. -- 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 of Starting Xterm using the System Tray Icon for Xterm for Cygwin64
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
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' failed to open an xterm window. The 32 bit version of the Xterm short icon with the target defined as C:\cygwin\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' is still working, but only open to the 32-bit Cygwin environment. Any idea on solving this problem? Thanks for any suggestion. Jyhshyong I would start by removing arguments and trying to determine which are causing the problem. Note that (I believe) what shows up in the system try is not the XTerm, but the XServer (XWin). While the XServer is running, you can run a client, like XTerm and it will display on the XServer display. Here is the shortcut I'm using to launch an XTerm under 64-bit cygwin: C:\Apps\cygwin\bin\run.exe -p /usr/X11R6/bin xterm +tb -sb -sl 5000 -display 127.0.0.1:0.0 -ls This is working fine for me. You can also check the /var/log/xwin/XWinwhatever.log file to see if there are any errors being written there when you try to launch the XTerm. Good luck. -- 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 of Starting Xterm using the System Tray Icon for Xterm for Cygwin64
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
On 3/7/2014 11:57 AM, 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 just installed the 64-bit version of Cygwin to another 64-bit Windows 7 PC, and it did not have this problem. After the installation was finished, my user was configured in the /etc/passwd file and did not have the mkgroup group. Instead, it was set to 513 (None), which I guess is okay - at least I don't get the error when launching a shell. I don't think I did anything different during the installation other than just getting a later version (I downloaded the software on 3/15/2014). FYI -- 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 launching XTerm on new Cygwin installation
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
On 3/7/2014 11:57 AM, 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. 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 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've searched for this XTERM_SHELL error, but can't find anything. Can anybody help me? Thanks, Well, I did the following two things: 1. I changed the group id for my entry in the /etc/passwd file from 10530 (or whatever that value was) to 545 (Users) and the first error went away. 2. I changed the shortcut I use to launch the XTerms and removed the shell name at the end, so it now looks like this: C:\Apps\cygwin\bin\run.exe -p /usr/X11R6/bin xterm +tb -sb -sl 5000 -display 127.0.0.1:0.0 -ls and now the XTerm is started without any errors. I guess it's working now, but I'm curious why these problems happened on the laptop installation and not on the desktop installation. Especially why the XTerm launch command had to change. The one I showed first I've been using for years without problems. I don't remember how I came up with it now, but I remember spending a lot of time putting that together. Also, that original launch command is working on my other PC (the desktop) as well as my other machines running the 32-bit version of Cygwin. Thanks for any feedback/clarification. -- 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 launching XTerm on new Cygwin installation
On 3/7/2014 1:49 PM, Thomas Dickey wrote: 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) Thanks. I think the -l was to cause a login shell, but I see now that is what the -ls argument does. Since I removed the shell argument (/bin/zsh -l) it is now working. I'm getting the shell I want, I suspect, because that is the shell mentioned in the /etc/passwd file for my user. 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? Thanks for your help! -- 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 launching XTerm on new Cygwin installation
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
On 3/7/2014 2:12 PM, Thomas Dickey wrote: 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. 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. I'm confused... FYI. -- 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 launching XTerm on new Cygwin installation
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 launching XTerm on new Cygwin installation
On 3/7/2014 4:36 PM, Thomas Dickey wrote: 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. Thanks. That was the bug I hit on my laptop. However, my desktop PC was working fine with xterm ... /bin/zsh -l and then suddenly, it started getting the same error. I made the same change to it as I did on my laptop PC and it worked, so I'm not stopped - I'm just wondering how my desktop PC was working then suddenly stopped working without altering any of the Cygwin software or settings. -- 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/
[ANNOUNCEMENT] Updated: xterm-302-1
The following package has been updated in the Cygwin distribution: *** xterm-302-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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 xterm-301-1
On Feb 27 17:00, Thomas Dickey wrote: 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 May I politely ask why xterm cares at all? What is the reasoning behind this? Heere's why I'm asking: Xterm is not a login process, like login(1) or sshd(8). If somebody starts xterm, the login process itself has long exec'ed the login shell, and the permission problem what shell is allowed to be started as login shell is done. Afterwards, the user is usually allowed to start whatever process he or she has a right to. It looks really weird to me that a terminal emulator would decide that certain processes are not allowed to a user which otherwise work fine. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHL4xGcjK9K.pgp Description: PGP signature
RE: Problem with xterm-301-1
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'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. -- 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 xterm-301-1
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
Problem with xterm-301-1
Hi, 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. /bin/ash /bin/bash /bin/dash /bin/sh /bin/tcsh /bin/zsh Regards, Ola Strömfors -- 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 xterm-301-1
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 SHELL before XWin starts. One way I fixed it was to launch xterm from .XWinrc like this: xterm EXEC xterm -e /bin/bash instead of this: xterm EXEC xterm -ls -- 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/
RE: Problem with xterm-301-1
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). -- 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 xterm-301-1
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
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
[ANNOUNCEMENT] Updated: xterm-301-1
The following package has been updated in the Cygwin distribution: *** xterm-301-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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 title setting breaks when upgrading from 32-bit to 64-bit cygwin
On 01/08/2013 01:55, Jeremy Elson wrote: I recently upgraded from the 32-bit to the 64-bit build of Cygwin 1.7.22 on Windows 8 x64. For the most part, everything works identically (except faster!). But I have noticed one problem: xterm no longer seems to respond to the magic escape codes that change its title. My shell uses this to update the title to reflect the current hostname and working directory, but after the upgrade all my xterms just have the same title: tcsh. I haven't seen any mention of this bug on the mailing lists. Is anyone else experiencing this problem? Thanks for pointing out this problem. It seems that x86_64 X server has a bug that meant that no window could change it's title after it started. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it improves things for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.x86_64.20130801-git-beadc5a3202e096a.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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 title setting breaks when upgrading from 32-bit to 64-bit cygwin
On Thu, Aug 1, 2013 at 10:28 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 01/08/2013 01:55, Jeremy Elson wrote: I recently upgraded from the 32-bit to the 64-bit build of Cygwin 1.7.22 on Windows 8 x64. For the most part, everything works identically (except faster!). But I have noticed one problem: xterm no longer seems to respond to the magic escape codes that change its title. My shell uses this to update the title to reflect the current hostname and working directory, but after the upgrade all my xterms just have the same title: tcsh. I haven't seen any mention of this bug on the mailing lists. Is anyone else experiencing this problem? Thanks for pointing out this problem. It seems that x86_64 X server has a bug that meant that no window could change it's title after it started. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it improves things for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.x86_64.20130801-git-beadc5a3202e096a.exe.bz2 Thanks for the very fast followup - yes, using the XWin binary below, my xterm can now set its title correctly! Thanks again, and regards, Jeremy -- 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/
Cygwin X Windows (xterm) and VirtuaWin: How to fix the refresh problem when switching virtual desktops
Hi all in short: To make VirtuaWin refresh windows correctly when switching desktops, generate a window rule that uses Hide by move for the X windows. in more detail: Several people like virtual desktops. On Windows, they can be provided by a tool called VirtuaWin. However, together with Cygwin XServer there are issues with refreshing the X windows when switching desktops. I was annoyed for this known issue since years and every now and then I looked to the internet checking if a solution appeared. Interestingly such a solution exists [1] since years (2009) but I did not find it before - now I am so happy! As this had be questioned on this list but as far as I see without presenting the solution, I decided to write this mail. To make VirtuaWin refresh windows correctly when switching desktops, generate a window rule that uses Hide by move for X windows. This can be done by clicking with the middle mouse button on the title bar of an Cygwin X Windows window, such as an xterm, and select Add Window Rule. In the dialog near bottom there is Method for hiding the window, change it to Hide by move window. Do not forget to press Add and Apply buttons afterwards. With middle-click titlebar and selecting Info it can be verified that instead of Handling: Standard,Standard now there should be Handling Move,. Please note that this might not instantly work for currently opened windows or windows on another desktop. Re-apply the rule on other desktops might help, a forum post [2] suggests rebooting (well, it's Windows). So just in case someone else lives with the same issue, I hope it helped that I repeated (copied) the solution [1] here. Regards, Steffen [1] http://sourceforge.net/projects/virtuawin/forums/forum/257054/topic/3413433 [2] http://sourceforge.net/projects/virtuawin/forums/forum/257054/topic/4089538 -- 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: Paste from xterm to Emacs no longer works
Ken Brown kbr...@cornell.edu writes: While waiting for this, I'll make a wild guess that his problem is related to the selection changes that started with emacs-24.1. Browse the NEWS file (`C-h n') and search for Selection changes. Thank you for trying to help. I found that when I googled, but I did not find it helpful at first. I think the following is incomplete. *** `x-select-enable-primary' now defaults to nil. Thus, commands that kill text or copy it to the kill-ring (such as M-w, C-w, and C-k) also use the clipboard---not the primary selection. I think that x-select-enable-primary also affects C-y. I tried to paste with the scroll wheel, but apparently that generated mouse-4, not mouse-2. But I really want to paste with the right mouse button. In .emacs: (global-set-key [mouse-3] 'mouse-yank-primary) In .Xdefaults: XTerm*VT100.Translations: #override \ KeyBackSpace: string(0x7f) \n\ ~Shift ~Ctrl ~Meta Btn1Up: select-end(PRIMARY, CLIPBOARD) \n\ ~Shift ~Ctrl ~Meta Btn3Down:ignore() \n\ ~Shift ~Ctrl ~Meta Btn3Up: insert-selection(PRIMARY, CLIPBOARD) (When I first tried to post this, I got the backspace invokes help problem. I put in the fix for that also) -- Fredrik Stax\ang | rot13: s...@hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET -- 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/
Paste from xterm to Emacs no longer works
How do I get it to work again? -- Fredrik Stax\ang | rot13: s...@hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET -- 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: Paste from xterm to Emacs no longer works
Hi Fredrik, You need to give a bit more detail than It doesn't work. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect Start here: Problem reports: http://cygwin.com/problems.html Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: Paste from xterm to Emacs no longer works
On 4/3/2013 7:54 AM, Csaba Raduly wrote: Hi Fredrik, You need to give a bit more detail than It doesn't work. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect Start here: Problem reports: http://cygwin.com/problems.html Right. In addition, the OP should give a recipe for reproducing the problem starting with `emacs -Q'. While waiting for this, I'll make a wild guess that his problem is related to the selection changes that started with emacs-24.1. Browse the NEWS file (`C-h n') and search for Selection changes. Ken -- 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: Paste from xterm to Emacs no longer works
This works for me: (global-set-key [mouse-3] 'mouse-yank-primary) -- Fredrik Stax\ang | rot13: s...@hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET -- 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/
[ANNOUNCEMENT] Updated: xterm-291-1
The following package has been updated for the Cygwin distribution: *** xterm-291-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] Updated: xterm-290-1
The following package has been updated for the Cygwin distribution: *** xterm-290-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
Strange xterm scrolling problem introduced in XTerm(289)
A strange scrolling problem seems to have been introduced in XTerm(289) I have a large scrollback buffer. Now when I scroll back my xterm, anything that was previously above the top of the current screen appears indented about 20 spaces: - r w x - - - - - - + 1 r e i s e r t D o m a i n U s e rs 424739 Feb 12 - r w x - - - - - - + 1 r e i s e r t D o m a i n U s e rs 424740 Feb 12 -rwx--+ 1 reisert Domain Users 424749 Feb 12 14:43 callsigns.csv.~29~ -rwx--+ 1 reisert Domain Users 424749 Feb 12 14:44 callsigns.csv Can anyone duplicate this? Note that when I copied/pasted the above lines into gmail, the first two lines (in the scrollback buffer) appeared in a different font than the two lines that were not in the buffer. -- 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/
Re: Strange xterm scrolling problem introduced in XTerm(289)
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. - Jim -- 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/
Re: Strange xterm scrolling problem introduced in XTerm(289)
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)
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
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 and font problems after last update
On 2/11/2013 12:42 PM, Thomas Dickey wrote: 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). nice to know, reverting to #287 solves the issue. $ xfontsel.exe Warning: Missing charsets in String to FontSet conversion The second one was (I think) reported/fixed on this list. reported yes, I see it in some variants, solved not. But reverting xterm, solves also the xfontsel.exe warning. Regards Marco -- 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: FW: xorg-server 1.13.1-1: problems with xterm
On 06/02/2013 17:18, PRIKHODKO, GEORGE wrote: After upgrading xorg-server and xorg-server-common packages from 1.13.0-1 to 1.13.1-1 version, xterm stopped responding to mouse events. I can select a text in a xterm window, but I cannot paste in it using middle button; holding Ctrl button and pressing one of mouse buttons doesn't bring 'Main Options' or 'VT Fonts' menus. After rolling back to 1.13.0-1 version everything works as I expect. I have four computers WIndows XP, Vista, 7 and 8, and run XWin in multi-window mode: XWin -ac -clipboard -emulate3buttons -lesspointer -multiwindow All four computers show the same symptoms. It's really not necessary write 3 emails about this, and certainly doesn't get you a reply any faster. I can't reproduce this problem. Are you using a 3-button mouse? Does removing -emulate3buttons help? It is a trackball: Logitech Marble Mouse T-BC21. After removing -emulate3buttons Ctrl+Left/Right button produces a menu. Is this a local xterm process, or one on a remote computer you are connecting to? Both, local and remote. Is it only xterm which doesn't respond to mouse buttons or are other programs affected? I didn't go further. A couple of days ago a new version of xorg-server, 1.13.2-1, came out. It still has same problem and it is impossible to return to 1.13.0-1 from setup.exe after installing 1.13.2-1 version. Yes, it is an unfortunate deficiency of setup that only 1 previous version is allowed. If you still have the downloaded package, you should be able to downgrade to 1.13.0-1 using the Install from local directory option in setup. Could you tell me whether I am doing something wrong or it is a bug? Is there a workaround? Where can I find sources of the packages? This sounds like a bug, although I hope someone else would have mentioned it if it was widespread. Detailed and possibly accurate instructions for obtaining the source code can be found in the Contributor's Guide at [1] [1] http://x.cygwin.com/docs/cg/ Thank you, George. -- 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/
[ANNOUNCEMENT] Updated: xterm-289-1
The following package has been updated for the Cygwin distribution: *** xterm-289-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: FW: xorg-server 1.13.1-1: problems with xterm
On 2/8/2013 1:15 PM, Jon TURNEY wrote: On 06/02/2013 17:18, PRIKHODKO, GEORGE wrote: After upgrading xorg-server and xorg-server-common packages from 1.13.0-1 to 1.13.1-1 version, xterm stopped responding to mouse events. I can select a text in a xterm window, but I cannot paste in it using middle button; holding Ctrl button and pressing one of mouse buttons doesn't bring 'Main Options' or 'VT Fonts' menus. After rolling back to 1.13.0-1 version everything works as I expect. I have four computers WIndows XP, Vista, 7 and 8, and run XWin in multi-window mode: XWin -ac -clipboard -emulate3buttons -lesspointer -multiwindow All four computers show the same symptoms. It's really not necessary write 3 emails about this, and certainly doesn't get you a reply any faster. I can't reproduce this problem. Are you using a 3-button mouse? Does removing -emulate3buttons help? I'm also seeing a mouse problem. It involves the combination shift-leftbutton-rightbutton (intended to emulate shift-middlebutton) after I've started XWin with -emulate3buttons. I use a 2-button mouse with a scroll wheel that can be pressed to serve as a third button. But I find it hard to press the scroll wheel without turning it, so I prefer to use -emulate3buttons. The shift-left-right combination used to be seen by emacs as shift-middle, but now emacs doesn't seem to see it at all. Moreover, after I press it once, either in emacs or elsewhere, both emacs and xterm stop responding to some other mouse events. To reproduce (without emacs): 1. Start the X server with startxwin -- -emulate3buttons 2. Press shift-left-right in an xterm window, using a mouse of the type I described. 3. Move the mouse over the titlebar of the xterm window. The menu items don't get highlighted, and left-clicking on them has no effect. The problem disappears if I remove the -emulate3buttons option; but that's not a good solution for me since I actually want to emulate 3 buttons. Ken -- 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: FW: xorg-server 1.13.1-1: problems with xterm
On 10/02/2013 12:45, Ken Brown wrote: On 2/8/2013 1:15 PM, Jon TURNEY wrote: On 06/02/2013 17:18, PRIKHODKO, GEORGE wrote: After upgrading xorg-server and xorg-server-common packages from 1.13.0-1 to 1.13.1-1 version, xterm stopped responding to mouse events. I can select a text in a xterm window, but I cannot paste in it using middle button; holding Ctrl button and pressing one of mouse buttons doesn't bring 'Main Options' or 'VT Fonts' menus. After rolling back to 1.13.0-1 version everything works as I expect. I have four computers WIndows XP, Vista, 7 and 8, and run XWin in multi-window mode: XWin -ac -clipboard -emulate3buttons -lesspointer -multiwindow All four computers show the same symptoms. It's really not necessary write 3 emails about this, and certainly doesn't get you a reply any faster. I can't reproduce this problem. Are you using a 3-button mouse? Does removing -emulate3buttons help? I'm also seeing a mouse problem. It involves the combination shift-leftbutton-rightbutton (intended to emulate shift-middlebutton) after I've started XWin with -emulate3buttons. I use a 2-button mouse with a scroll wheel that can be pressed to serve as a third button. But I find it hard to press the scroll wheel without turning it, so I prefer to use -emulate3buttons. The shift-left-right combination used to be seen by emacs as shift-middle, but now emacs doesn't seem to see it at all. Moreover, after I press it once, either in emacs or elsewhere, both emacs and xterm stop responding to some other mouse events. To reproduce (without emacs): 1. Start the X server with startxwin -- -emulate3buttons 2. Press shift-left-right in an xterm window, using a mouse of the type I described. 3. Move the mouse over the titlebar of the xterm window. The menu items don't get highlighted, and left-clicking on them has no effect. The problem disappears if I remove the -emulate3buttons option; but that's not a good solution for me since I actually want to emulate 3 buttons. Thanks for the reproduction steps. It seems I introduced a bug in the -emulate3buttons code with some changes in 1.13.1-1, which could cause the emulated middle mouse button click to not be released. I've applied fix to address this, so hopefully this works better now. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it fixes the issue for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20130210-git-02d68fce528227a5.exe.bz2 -- 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: FW: xorg-server 1.13.1-1: problems with xterm
On 2/10/2013 1:37 PM, Jon TURNEY wrote: On 10/02/2013 12:45, Ken Brown wrote: I'm also seeing a mouse problem. It involves the combination shift-leftbutton-rightbutton (intended to emulate shift-middlebutton) after I've started XWin with -emulate3buttons. I use a 2-button mouse with a scroll wheel that can be pressed to serve as a third button. But I find it hard to press the scroll wheel without turning it, so I prefer to use -emulate3buttons. The shift-left-right combination used to be seen by emacs as shift-middle, but now emacs doesn't seem to see it at all. Moreover, after I press it once, either in emacs or elsewhere, both emacs and xterm stop responding to some other mouse events. To reproduce (without emacs): 1. Start the X server with startxwin -- -emulate3buttons 2. Press shift-left-right in an xterm window, using a mouse of the type I described. 3. Move the mouse over the titlebar of the xterm window. The menu items don't get highlighted, and left-clicking on them has no effect. The problem disappears if I remove the -emulate3buttons option; but that's not a good solution for me since I actually want to emulate 3 buttons. Thanks for the reproduction steps. It seems I introduced a bug in the -emulate3buttons code with some changes in 1.13.1-1, which could cause the emulated middle mouse button click to not be released. I've applied fix to address this, so hopefully this works better now. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it fixes the issue for you? That fixes it. Thanks. Ken -- 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/
[ANNOUNCEMENT] Updated: xterm-288-1
The following package has been updated for the Cygwin distribution: *** xterm-288-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: FW: xorg-server 1.13.1-1: problems with xterm
On 06/02/2013 17:18, PRIKHODKO, GEORGE wrote: After upgrading xorg-server and xorg-server-common packages from 1.13.0-1 to 1.13.1-1 version, xterm stopped responding to mouse events. I can select a text in a xterm window, but I cannot paste in it using middle button; holding Ctrl button and pressing one of mouse buttons doesn't bring 'Main Options' or 'VT Fonts' menus. After rolling back to 1.13.0-1 version everything works as I expect. I have four computers WIndows XP, Vista, 7 and 8, and run XWin in multi-window mode: XWin -ac -clipboard -emulate3buttons -lesspointer -multiwindow All four computers show the same symptoms. It's really not necessary write 3 emails about this, and certainly doesn't get you a reply any faster. I can't reproduce this problem. Are you using a 3-button mouse? Does removing -emulate3buttons help? Is this a local xterm process, or one on a remote computer you are connecting to? Is it only xterm which doesn't respond to mouse buttons or are other programs affected? A couple of days ago a new version of xorg-server, 1.13.2-1, came out. It still has same problem and it is impossible to return to 1.13.0-1 from setup.exe after installing 1.13.2-1 version. Yes, it is an unfortunate deficiency of setup that only 1 previous version is allowed. If you still have the downloaded package, you should be able to downgrade to 1.13.0-1 using the Install from local directory option in setup. Could you tell me whether I am doing something wrong or it is a bug? Is there a workaround? Where can I find sources of the packages? This sounds like a bug, although I hope someone else would have mentioned it if it was widespread. Detailed and possibly accurate instructions for obtaining the source code can be found in the Contributor's Guide at [1] [1] http://x.cygwin.com/docs/cg/ -- 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/
[ANNOUNCEMENT] Updated: xterm-287-1
The following package has been updated for the Cygwin distribution: *** xterm-287-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] Updated: xterm-286-1
The following package has been updated for the Cygwin distribution: *** xterm-286-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] Updated: xterm-285-1
The following package has been updated for the Cygwin distribution: *** xterm-285-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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 icon updated? Re: Updated: xterm-283-1
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! -- 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 icon updated? Re: Updated: xterm-283-1
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
XTerm icon updated? Re: Updated: xterm-283-1
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. 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/
Re: XTerm icon updated? Re: Updated: xterm-283-1
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
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). -- 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/
Re: XTerm icon updated? Re: Updated: xterm-283-1
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
typo in man xterm
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 ... Regards, Paul -- 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: typo in man xterm
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
xterm -si doesn't hold the line
Hi, xterm -si doesn't work as expected. 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 -- 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/
AW: typo in man xterm
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? 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. Regards, Paul -- 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: AW: typo in man xterm
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
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: startx - no keyboard or mouse focus with single xterm, repeatable error
I upgraded yesterday, and am similarly afflicted Thanks Patrick for a workaround, +200+200 works for me. Mario's suggestion of startxwin doesn't solve the problem because startxwin doesn't allow single root window mode. Another minimal way to demonstrate the problem: DISPLAY=:0; export DISPLAY XWin twm notice that twm doesn't have focus, and pressing button1 on the root window doesn't show a menu. Howewver if you then force twm to ask where to place a window by doing: xclock then once the window has been placed I can see the button1 menu, and subsequent xterms etc work properly. When I tried fvwm as an alternative window manager, it worked ok. -- Scott Merrilees -- 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/
startx - no keyboard or mouse focus with single xterm, repeatable error - WORKAROUND
I've found a better workaround for this problem which works without needing to calculate the correct placement of a remedial xterm. Install the xsetroot package and run the following once the X server has started up: # Traditional X11 X-shaped cursor xsetroot -cursor_name X_cursor or # Normal left-pointing arrow cursor xsetroot -cursor_name left_ptr Setting the cursor in this way fixes both the keyboard focus and missing pointer problems. Also - can anyone tell me how to respond correctly to messages in a digest or from the mailing list archive? I've just pasted in the subject heading for this email and Scott's original email below (minus the email addresses), but I'm guessing this email won't show up in the right thread location in the overal email structure of the archive. Regards, Patrick From: Scott Merrilees To: Cc: Date: Thu, 14 Jun 2012 16:05:22 +1000 Subject: Re: startx - no keyboard or mouse focus with single xterm, repeatable error I upgraded yesterday, and am similarly afflicted Thanks Patrick for a workaround, +200+200 works for me. Mario's suggestion of startxwin doesn't solve the problem because startxwin doesn't allow single root window mode. Another minimal way to demonstrate the problem: DISPLAY=:0; export DISPLAY XWin twm notice that twm doesn't have focus, and pressing button1 on the root window doesn't show a menu. Howewver if you then force twm to ask where to place a window by doing: xclock then once the window has been placed I can see the button1 menu, and subsequent xterms etc work properly. When I tried fvwm as an alternative window manager, it worked ok. -- Scott Merrilees -- 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 basic startx and xterm - no cursor or focus
On 5/29/2012 7:18 PM, Patrick Hogan wrote: Hi list, A slightly more pared-down version of a question I've posed previously. From a new Cygwin install on Windows 7 running 1024x768 resolution, compare the result of the following two commands run from a Cygwin terminal: startx /usr/bin/xterm -- -logfile broken.log startx /usr/bin/xterm -geometry 80x50+494+51 -- -logfile works.log The first command produces a single unmanaged xterm. No X11 cursor is visible and the xterm is unable to receive input focus. It is not possible to anticipate where the cursor ought to be and give the xterm focus. Unusable. The second command produces a single unmanaged xterm. The X11 cursor is visible and the xterm is able to receive input focus. Works as expected. This seems to be a fairly fundamental problem, and the placement of the xterm determines whether the entire X.org session is usable or not. Does anyone know anything about this problem? Regards, Patrick try using startxwin instead of startx in addition xterm -ls /bin/bash should be better for the shell enviroment in the xterm Regards Marco -- 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/
Problem with basic startx and xterm - no cursor or focus
Hi list, A slightly more pared-down version of a question I've posed previously. From a new Cygwin install on Windows 7 running 1024x768 resolution, compare the result of the following two commands run from a Cygwin terminal: startx /usr/bin/xterm -- -logfile broken.log startx /usr/bin/xterm -geometry 80x50+494+51 -- -logfile works.log The first command produces a single unmanaged xterm. No X11 cursor is visible and the xterm is unable to receive input focus. It is not possible to anticipate where the cursor ought to be and give the xterm focus. Unusable. The second command produces a single unmanaged xterm. The X11 cursor is visible and the xterm is able to receive input focus. Works as expected. This seems to be a fairly fundamental problem, and the placement of the xterm determines whether the entire X.org session is usable or not. Does anyone know anything about this problem? Regards, Patrick broken.log Description: Binary data works.log Description: Binary data cygcheck.out Description: Binary data -- 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 basic startx and xterm - no cursor or focus
This seems to be a fairly fundamental problem, and the placement of the xterm determines whether the entire X.org session is usable or not. Does anyone know anything about this problem? I will only mention that while I am unable to recover from this same problem (rebase/reinstalling/different versions has no effect), installing cygwin and the latest stable packages does not reproduce this problem on other machines. -Justin -- 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/
[ANNOUNCEMENT] Updated: xterm-279-1
The following package has been updated for the Cygwin distribution: *** xterm-279-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
startx - no keyboard or mouse focus with single xterm, repeatable error
I've observed a problem whereby a single-screen X11 session started with startx or Xwin prevents a single xterm from being started in a usable state (no keyboard or mouse focus), but the problem goes away if the xterm is placed in a *particular area on the screen*. It's a new fresh Cygwin install. Here's the command I'm using: startx /usr/bin/xterm This opens a single-window X11 server populated with one xterm. Within the X11 server window, the cursor is not visible and neither mouse focus or keyboard focus is available. Even with twm running, the situation is the same: startx /usr/bin/xterm -e twm Tested on: Windows XP SP3 32-bit (running under VirtualBox on a Linux host, 1024x768 resolution, 32bpp and 16bpp) Windows Server 2008 R2 64-bit (running under VMware ESX 3.x via an RDP remote desktop session, 1132x778 resolution, 16bpp). Here is the strange thing. On both installations I can get everything working fine by running the xterm like this: startx /usr/bin/xterm -g 40x40-xxx+51 with xxx set to 257 or more, up to an upper bound of 508, after which it stops working again. This range seems to depend on the horizontal resolution of the X11 server window, the example above using 1024x768 32bpp, and basic testing seems to suggest that xxx needs to be just over 25% of the horizontal resolution. The vertical resolution of the X11 server window doesn't seem to have a bearing on the issue. So - it seems that the problem can be side-stepped by popping up an xterm in the area of the screen just beyond the 25% mark on the horizontal access, and then immediately closing it again, after which everything is fine. The fact that it's such a repeatable error is interesting! Any insights appreciated. Regards, Patrick XWin.0.log Description: Binary data cygcheck.out Description: Binary data -- 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/
Updated: startx - no keyboard or mouse focus with single xterm, repeatable error
In my previous email, I mis-typed the xterm geometry which might have caused confusion. There was a minus where there should have been a plus. Corrected version below. I've observed a problem whereby a single-screen X11 session started with startx or Xwin prevents a single xterm from being started in a usable state (no keyboard or mouse focus), but the problem goes away if the xterm is placed in a *particular area on the screen*. It's a new fresh Cygwin install. Here's the command I'm using: startx /usr/bin/xterm This opens a single-window X11 server populated with one xterm. Within the X11 server window, the cursor is not visible and neither mouse focus or keyboard focus is available. Even with twm running, the situation is the same: startx /usr/bin/xterm -e twm Tested on: Windows XP SP3 32-bit (running under VirtualBox on a Linux host, 1024x768 resolution, 32bpp and 16bpp) Windows Server 2008 R2 64-bit (running under VMware ESX 3.x via an RDP remote desktop session, 1132x778 resolution, 16bpp). Here is the strange thing. On both installations I can get everything working fine by running the xterm like this: startx /usr/bin/xterm -g 40x40+xxx+51 with xxx set to 257 or more, up to an upper bound of 508, after which it stops working again. This range seems to depend on the horizontal resolution of the X11 server window, the example above using 1024x768 32bpp, and basic testing seems to suggest that xxx needs to be just over 25% of the horizontal resolution. The vertical resolution of the X11 server window doesn't seem to have a bearing on the issue. So - it seems that the problem can be side-stepped by popping up an xterm in the area of the screen just beyond the 25% mark on the horizontal access, and then immediately closing it again, after which everything is fine. The fact that it's such a repeatable error is interesting! Any insights appreciated. Regards, Patrick XWin.0.log Description: Binary data cygcheck.out Description: Binary data -- 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/
xterm does't handle LINES and COLS correctly anymore
Since one of the last updates this year, the output in an xterm is sometimes wrapped after a few columns. They same applies to the number of lines. Sometimes it works, i.e. xterm wraps the line when the content really doesn't fit into the line anymore, but sometimes the lines are wrapped after 4 or 30 characters. The effect sometimes appears locally (i.e. in xcygwin), but happens more often when logging into a remote server via SSH. In such a case, the terminal is unusable. I noticed that LINES and COLS is not set on the cygwin side, and remotely (2 SLES servers) I get something like this: $ echo LINES:$LINES COLS:$COLS LINES:2 COLS: Setting the LINES before and/or after ssh'ing into the server sometimes helps, but not very often. Any ideas? Thank you have a nice day, Berny P.S. It's Win7, and I start openbox from ~/.xinitrc via the .bat lines chdir /d d:\cygwin\bin .\run bash -l -c /bin/startx -- 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/
[ANNOUNCEMENT] Updated: xterm-278-1
The following package has been updated for the Cygwin distribution: *** xterm-278-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] Updated: xterm-277-1
The following package has been updated for the Cygwin distribution: *** xterm-277-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 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
AW: scrolling xterm with Levovo trackpoint
when I reboot my PC, scrolling an xterm with a Levovo trackpoint works (mostly) fine, very smooth and good speed. Then I work for a while and some condition, that I couldn't find out yet, corrupts it. It then doesn't scroll WHILE you hold that Trackpoint middle button down, but after you RELEASED it; on release it catches up for all the scrolling that should have appeared before. It's then not really scrolling but guesswork, how much of pressure might be the right, then you release and you see where you got scrolled by that. Does anybody have the same experience or an idea what could be the cause of that switching from working to not working? not exactly - if it's using wheel mouse (buttons 4/5) those should be sent continuously. xterm isn't necessarily going to keep up with a continuous stream of events, so there could be a buildup of events making xterm not seem to do much for a while. I made some improvements to filter out duplicate window movement/resizing, but that shouldn't be related. Hi Thomas! thank you for your response. I experience a difference between the Trackpoint and the mouse wheel: the mouse wheel always works fine. Even an xterm that lived for quite a while and that shows this deferred scrolling on using the trackpoint, I can without problem scroll using the wheel or using xterm's scrollbar. I think we agree, that the trackpoint events ARE generated (because otherwise there would not be deferred scrolling but no scrolling). So the question is, where these events get buffered. If xterm treats wheel and trackpoint the same, the trackpoint events get buffered in a component between XWin and xterm? In case you want me to run a beta test, also for the blind key (dead key) issue, pls let me know. Regards, Paul -- 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/
scrolling xterm with Levovo trackpoint
Hi there, when I reboot my PC, scrolling an xterm with a Levovo trackpoint works (mostly) fine, very smooth and good speed. Then I work for a while and some condition, that I couldn't find out yet, corrupts it. It then doesn't scroll WHILE you hold that Trackpoint middle button down, but after you RELEASED it; on release it catches up for all the scrolling that should have appeared before. It's then not really scrolling but guesswork, how much of pressure might be the right, then you release and you see where you got scrolled by that. Does anybody have the same experience or an idea what could be the cause of that switching from working to not working? With trackpoint I mean that red button in the middle of a Lenovo laptop. Thanks regards, Paul -- 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 metaSendsEscape not working
On 11/9/2011 8:09 PM, Thomas Dickey wrote: 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. OK, removing all translations involving Meta did indeed fix it, and so did setting alwaysUseMods to true. So I guess it wasn't a Cygwin-specific issue then after all, just a manpage comprehension issue. Thanks! -- 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/
XTerm metaSendsEscape not working
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 to my XTerm*translations does the trick (though I would have to add a line like this for every key on the keyboard). The fact that this fixes it seems to be evidence that my problem really is at the XTerm level and not bash or readline or the X server or Windows key mappings or something like that. I'm using Windows 7 64-bit. Any ideas appreciated. Thank you. -- 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 metaSendsEscape not working
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
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
I think that's cutomization: -color (note the dash), but yes :-) ... Eliot Moss -- 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
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 -- 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
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: exim-4.76-1 fails to remove lock ... and Cygwin xterm and emacs-X11 broken...
Thank you so much for your help. I'm doing this right now... Perhaps this will fix my X11 problems (with xterm and emacs-X11) as well... Let's see... bunzipped... moved... stopped Cygwin servers... renamed /bin/cygwin1.dll... restarted servers... (they work)... Cygwin shell ... works... sent mail to myself from another machine and... it WORKS! The lock file has been removed from /var/spool/mail and the mail has been delivered. Wonderful. How about... xterm... yepp this works too, with readline and command completion, emacs-X11, yepp, shell process forked nicely, works. So many problems fixed with just this one little change! Thanks again, Gustav From: Pierre A. Humblet Subject: RE: exim-4.76-1 fails to remove lock from spooler on delivery Hi Gustav, [...] 1)Go to http://cygwin.com/snapshots/ 2)Download the latest cygwin1-XXX.dll.bz2 (perhaps ask Corinna for one that is known to work. In my experience most do.) 3)Bunzip it, chmod it to executable by all and place it in /bin. 4)Kill all Cygwin processes 5)From Windows (cmd or explorer) rename the existing cygwin1.dll to something else, and conversely rename the new cygwin1-XXX.dll to cygwin1.dll 6)Restart Cygwin In case of trouble reverse step 5. There is no downside risk. Pierre -- 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/
Cygwin xterm and emacs-X11 broken in Windows 7
Windows 7 (Enterprise): On X11 startup with startxwin I am getting a message: startxwin: XFree86_VT property unexpectedly has 0 items instead of 1 The xterm window that pops up knows that it's xterm (the value of TERM variable), but it's not configured properly. Curses don't work. Command completion (in bash) doesn't work. Less, more, vi and view work like on an undefined terminal (vi and view don't even want to come up). This may be a non-X11 issue (a curses/term problem), so I'm cross-posting to cygwin at cygwin dot com as well. Perhaps related: in emacs-X11 entering the shell mode (M-x shell) kills the shell. I just get a prompt, then exit and a message Process shell finished This does *not* happen in emacs-nox, neither does this happen in xemacs. I attach the output of cygcheck -s -r -v. Zdzislaw Meglicki Indiana University cygcheck.log.gz Description: GNU Zip compressed data -- 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/
