Easy to see problem symptom: When running xinit, the full-screen window
has a white border.
I have an older machine with an "ASUS NVIDIA GeForce GTX 770" graphics card.
The problem was either with the NVIDIA Windows display driver or some
underlying Windows update. Fixing it was
When I ran xinit, I got the following events in the Windows event log:
Display driver nvlddmkm stopped responding and has successfully
recovered.
Kernel diagnostic event:
=
Fault bucket LKD_0x141_Tdr:6_IMAGE_nvlddmkm.sys_Kepler_3D, type 0
screen 4.9.1-1 is now available in Cygwin. This release includes bug fixes
and documentation updates. See the release announcement[1] and upstream
changelog[2] for more details.
Screen is a full-screen window manager that multiplexes a physical terminal
between several processes, typically
On Aug 7 12:43, Cedric Blancher via Cygwin wrote:
> On Mon, 7 Aug 2023 at 11:55, Corinna Vinschen
> wrote:
> >
> > On Aug 7 11:29, Cedric Blancher via Cygwin wrote:
> > > Forwarding to cygwin@cygwin.com
> > >
> > > Honestly I find it deeply concerning that a plain, unprivileged user
> > > can B
On Mon, 7 Aug 2023 at 11:55, Corinna Vinschen wrote:
>
> On Aug 7 11:29, Cedric Blancher via Cygwin wrote:
> > Forwarding to cygwin@cygwin.com
> >
> > Honestly I find it deeply concerning that a plain, unprivileged user
> > can Bluescreen a machine, and more so that it happens during normal
> > C
message -
> From: Cedric Blancher
> Date: Sun, 6 Aug 2023 at 23:56
> Subject: Kernel stack trace for Winows 10 blue screen when running Cygwin?
> To:
>
>
> Good evening!
>
> How can we get a Windows kernel stack trace for a blue screen - aka
> Windows kernel c
stack trace for Winows 10 blue screen when running Cygwin?
To:
Good evening!
How can we get a Windows kernel stack trace for a blue screen - aka
Windows kernel crash?
We're experiencing regular blue screens when we run Cygwin git
operations for a large repository (~6GB of text files, so
hello,
I did a cygwin installation on my employers laptop and have issues
with cygwin/X
Xwin with xfce starts and opens a window, but without any content. It
is only light grey and does not react on any mouse clicks.
The windows task manager however shows that Xwin/xfce is running and
that al
screen 4.9.0-1 is now available in Cygwin. This release includes several
bug fixes, including for a possible denial of service by a crafted UTF-8
character sequence. Everyone is urged to upgrade to this release.
See the release announcement[1] and upstream changelog[2] for more details.
Screen
On Thu, 6 May 2021 18:12:38 +0900
Takashi Yano via Cygwin> wrote:
> On Wed, 5 May 2021 15:07:04 +0200 (CEST)
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Fri, 30 Apr 2021, Kevin Locke wrote:
> >
> > > On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> > > > On Fri, 30 Apr 2021 08:25:12 -
On Wed, 5 May 2021 15:07:04 +0200 (CEST)
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 30 Apr 2021, Kevin Locke wrote:
>
> > On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> > > On Fri, 30 Apr 2021 08:25:12 -0600 Kevin Locke wrote:
> > >> I'm investigating an issue in Git for Windows[^1],
Hi,
On Fri, 30 Apr 2021, Kevin Locke wrote:
> On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> > On Fri, 30 Apr 2021 08:25:12 -0600 Kevin Locke wrote:
> >> I'm investigating an issue in Git for Windows[^1], which also affects
> >> Cygwin. The issue is that, when using CMD (i.e. Command P
On Fri, Apr 30, 2021 at 1:31 PM Takashi Yano via Cygwin
wrote:
> Why on earth do you want to set TERM=cygwin?
> If you don't set TERM=cygwin, TERM is automatically set to
> xterm-256color, in which the issue does not occur.
>
Might be because for the longest time, if you didn't set it to cygwin,
; >> SetConsoleMode(ENABLE_VIRTUAL_TERMINAL_INPUT)[^3] to behave like
> >> xterm-256color when supported[^4] (they are not supported in "Legacy
> >> Console Mode").
> >>
> >> I'm not too familiar with TTY/PTY handling, much less Cygwin on top of
ehave like
xterm-256color when supported[^4] (they are not supported in "Legacy
Console Mode").
I'm not too familiar with TTY/PTY handling, much less Cygwin on top of
CMD. It's not clear to me if the alternate screen buffer behaves
differently in CMD than xterm, whether Cygwin has
On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> On Fri, 30 Apr 2021 08:25:12 -0600 Kevin Locke wrote:
>> I'm investigating an issue in Git for Windows[^1], which also affects
>> Cygwin. The issue is that, when using CMD (i.e. Command Prompt) on
>> Windows 10 1703 or above with "Legacy Con
leMode(ENABLE_VIRTUAL_TERMINAL_INPUT)[^3] to behave like
> xterm-256color when supported[^4] (they are not supported in "Legacy
> Console Mode").
>
> I'm not too familiar with TTY/PTY handling, much less Cygwin on top of
> CMD. It's not clear to me if the alte
I'm not too familiar with TTY/PTY handling, much less Cygwin on top of
CMD. It's not clear to me if the alternate screen buffer behaves
differently in CMD than xterm, whether Cygwin has any responsibility, or
if the issue is in how CMD handles ANSI escape sequences. Johannes
Schindelin sugg
> On Thu, 12 Mar 2020 19:01:41 -0700
> Wayne Davison wrote:
> > In recent Cygwin versions I've had gnu screen crash if the parent ssh
> > connection closes before an explicit disconnect is performed.
Thanks for reporting. I don't have any Cygwin hosts set up as ssh
On Thu, 12 Mar 2020 19:01:41 -0700
Wayne Davison wrote:
> In recent Cygwin versions I've had gnu screen crash if the parent ssh
> connection closes before an explicit disconnect is performed. If an
> orderly screen disconnect happens first, future closed connections
> (after re
In recent Cygwin versions I've had gnu screen crash if the parent ssh
connection closes before an explicit disconnect is performed. If an
orderly screen disconnect happens first, future closed connections
(after reconnecting to the screen session) no longer crash screen.
To reproduce:
I ssh
screen 4.8.0-1 is now available in Cygwin. This release includes several
bug fixes, including a fix for a memory overwrite that could be a security
vulnerability. Everyone is urged to upgrade to this release.
See the release announcement[1] and upstream changelog[2] for more details.
Screen is a
screen-4.7.0-1 is now available in Cygwin. This release includes lots of
small fixes and documentation improvements. See the upstream changelog[1]
for details.
This release also includes a small change to the default /etc/screenrc,
reported to fix a screen corruption problem for some users, that
Hi,
On 16/4/19 11:40 pm, Andrew Schulman wrote:
screen-4.6.2-3 is now available as a test release in Cygwin. This release
includes a small change to the default /etc/screenrc, that has been
reported to fix a screen corruption problem that some users - okay, Shaddy
:) - have reported after
screen-4.6.2-3 is now available as a test release in Cygwin. This release
includes a small change to the default /etc/screenrc, that has been
reported to fix a screen corruption problem that some users - okay, Shaddy
:) - have reported after detaching from screen[1,2].
If you're a screen
- Original Message -
| From: "Thomas Dickey"
| To: "Thomas Wolff"
| Cc: "cygwin"
| Sent: Thursday, April 11, 2019 7:06:22 PM
| Subject: Re: *cause of* screen writing over restored buffer on detach/exit
| - Original Message -
|| From: "Thom
- Original Message -
| From: "Thomas Wolff"
| To: "cygwin"
| Sent: Wednesday, April 10, 2019 5:51:34 PM
| Subject: Re: *cause of* screen writing over restored buffer on detach/exit
| Hi Thomas,
|
| Thomas Dickey wrote:
|> - Original Message -
|> | From
Am 11.04.2019 um 14:12 schrieb Andrew Schulman:
Am 10.04.2019 um 17:04 schrieb Andrew Schulman:
Hi Shaddy. There you go again.
The reason seems to be that the Debian screen package packages a custom
/etc/screenrc that does not include this explicit term capability:
#
# Do not use xterms
> Am 10.04.2019 um 17:04 schrieb Andrew Schulman:
> > Hi Shaddy. There you go again.
> >
> >> The reason seems to be that the Debian screen package packages a custom
> >> /etc/screenrc that does not include this explicit term capability:
> >>
> >&g
Hi Thomas,
Thomas Dickey wrote:
- Original Message -
| From: "Shaddy Baddah"
| To: "cygwin"
| Sent: Tuesday, April 9, 2019 11:18:19 PM
| Subject: Re: *cause of* screen writing over restored buffer on detach/exit
| On 9/4/19 4:07 pm, Shaddy Baddah wrote:
|>
|&g
- Original Message -
| From: "Shaddy Baddah"
| To: "cygwin"
| Sent: Tuesday, April 9, 2019 11:18:19 PM
| Subject: Re: *cause of* screen writing over restored buffer on detach/exit
| On 9/4/19 4:07 pm, Shaddy Baddah wrote:
|>
|> This helped with screen wh
Am 10.04.2019 um 17:04 schrieb Andrew Schulman:
Hi Shaddy. There you go again.
The reason seems to be that the Debian screen package packages a custom
/etc/screenrc that does not include this explicit term capability:
#
# Do not use xterms alternate window buffer.
# This one would not add
Hi Shaddy. There you go again.
> The reason seems to be that the Debian screen package packages a custom
> /etc/screenrc that does not include this explicit term capability:
>
>
> #
> # Do not use xterms alternate window buffer.
> # This one would not add lines to
On 9/4/19 4:07 pm, Shaddy Baddah wrote:
This helped with screen when using Putty to a Cygwin ssh session. For
some reason, it isn't helping for running screen locally in a mintty
session. And it's not mintty either, because I can ssh to a Debian
stretch server within mintty and I c
Hi,
On 9/4/19 3:37 pm, Shaddy Baddah wrote:
I confirmed this by turning off the default "login" mode for a new
session, which averted attempts to manage utmp entries, and therefore
avoided the "utmp slot not found" message. I did this by launching a
session via:
screen -
Hi,
So I've had an issue with screen for some years now. I do remember
noticing its introduction, but I no longer can remember when that
actually happened.
As per the subject, I find that when I detach or exit a screen session
the cursor ends up part way up the restored buffer, intermi
Hi Corinna,
On Sat, 16 Mar 2019 16:34:41 +0100 Corinna Vinschen wrote:
> Pushed and new release uploaded.
I confirmed that the issue has been fixed in login 1.13-1.
Thank you very much!
--
Takashi Yano
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cyg
0 Takashi Yano wrote:
> > > Hello,
> > >
> > > I would like to propose a patch attached for login package.
> > >
> > > This fixes the issue that GNU screen and tmux cannot read tty input
> > > if they are started in a telnet session.
> >
ropose a patch attached for login package.
> >
> > This fixes the issue that GNU screen and tmux cannot read tty input
> > if they are started in a telnet session.
> >
> > This issue is due to the ownership of tty. With login 1.12-1, tty
> > is owned by cyg_se
Greetings, Andrew Schulman!
> screen 4.6.2-2 is now available in Cygwin. This is a Cygwin-only release that
> fixes a long-standing problem: screen -ls and screen -Q would hang in Cygwin.
> They both work now. See the discussion at
> http://cygwin.com/ml/cygwin/2019-03/msg00140.html.
screen 4.6.2-2 is now available in Cygwin. This is a Cygwin-only release that
fixes a long-standing problem: screen -ls and screen -Q would hang in Cygwin.
They both work now. See the discussion at
http://cygwin.com/ml/cygwin/2019-03/msg00140.html.
And a GOLD STAR each to Corinna and Takashi for
I try to clarify the title a little.
On Sat, 9 Mar 2019 10:35:13 +0900 Takashi Yano wrote:
> Hello,
>
> I would like to propose a patch attached for login package.
>
> This fixes the issue that GNU screen and tmux cannot read tty input
> if they are started in a telnet sessio
Hello,
I would like to propose a patch attached for login package.
This fixes the issue that GNU screen and tmux cannot read tty input
if they are started in a telnet session.
This issue is due to the ownership of tty. With login 1.12-1, tty
is owned by cyg_server after logging in via telnet
Hi,
If you need a quotation of LED Display (both for indoor, outdoor.
rental or fixed installation).
Please contact us. We can give your our best price.
Kind regards,
Roger
Web: https://ylsoled.en.alibaba.com/
win.bat, I am greeted with the
> following error when attempting to call 'screen -ls':
>
> > $ screen -ls
> > Directory /tmp/uscreens/S-MyUserName must have mode 700.
>
> Note that at this point the /tmp/uscreens directory has been created for
> the first time
the
following error when attempting to call 'screen -ls':
> $ screen -ls
> Directory /tmp/uscreens/S-MyUserName must have mode 700.
Note that at this point the /tmp/uscreens directory has been created for
the first time.
Closing this terminal, reopening it, and calling &#x
[cleaning up my mailbox I found this 3-years old but ananswered issue]
Am 01.06.2015 um 16:59 schrieb Richard Czech:
On a tablet running Windows 8.1pro I installed Cygwin 2.0.0 /64.
Unfortunately I have issues using the on-screen (virtual) keyboard with Alt-Gr
keys from within mintty
Greetings, L A Walsh!
>>> To start with, I need to hook up a PS/2 kbd & mouse
>>> to access those, while I could load the megaraid drivers
>>> then,
>>
>> Or rebuild the Win7 disk image with related drivers.
>> Been doing that for years myself, but YMMV.
> ---
> Need to learn how...just h
Andrey Repin wrote:
To start with, I need to hook up a PS/2 kbd & mouse
to access those, while I could load the megaraid drivers
then,
Or rebuild the Win7 disk image with related drivers.
Been doing that for years myself, but YMMV.
---
Need to learn how...just have been more busy
w/o
Greetings, L A Walsh!
> David Conrad wrote:
>> I think Michel LaBarre's suggestion of running chkdsk and sfc is a
>> good one;
> ---
> I agree...chkdsk indicated something odd in an attribute block,
> but I've yet to be able to correct it, since I'm running win7
> on a newer machine that uses USB
Michel LaBarre wrote:
If you need a boot environment that knows your hardware, try downloading the
backup program Reflect from Macrium - there is a free version.
Wouldn't it be more prudent in the long run to make sure the repair-environment
builtin to windows and your install disk knows
repeat steps 3-4 until you
get it right... ;-)
Michel
> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of L A Walsh
> Sent: May 21, 2018 2:28 PM
> To: cygwin@cygwin.com
> Subject: Re: normal to blue-screen windows when doing &
David Conrad wrote:
I think Michel LaBarre's suggestion of running chkdsk and sfc is a
good one;
---
I agree...chkdsk indicated something odd in an attribute block,
but I've yet to be able to correct it, since I'm running win7
on a newer machine that uses USB3 and doesn't understand
that my RAI
On Thu, May 17, 2018 at 01:54 PM, L A Walsh wrote:
> Very wierd. It triggers so fast, and whatever is causing it, likely
> happens on a probe by 'ls' before ls even displays any output.
>
> I 'can' go into the same directory and do a "echo *" (or better,
> printf "%s\n" * --- and that doesn't tr
Michel LaBarre wrote:
L A Walsh,
Please forgive the following naïve points but since I saw no mention of the
easy checks...
Did you do a "chkdsk" and "sfc /scannow" at any point to pare out any obvious
corruptions?
I have done chkdsk and sfc's in the past and both have been
clea
L A Walsh,
Please forgive the following naïve points but since I saw no mention of the
easy checks...
Did you do a "chkdsk" and "sfc /scannow" at any point to pare out any obvious
corruptions?
(When you chkdsk on C:, you will be asked if you want to do it on reboot since
the disk must be offli
Brian Inglis wrote:
Run "cygcheck ls" to see if any Windows installs added to your path pick up
api-ms-win-core-... intercept dlls e.g. Firefox, Tortoise, etc.
---
Nope. I set my path in my login profile:
reorder path, filter out dups and empty dirs and
use abbreviated paths for some com
gt; (256KB)
> is enabled -- should have dumped in C:\windows\Minidump, but nothing was
> there.
>
> I did try to see the module when the blue screen was up, but
> it rebooted too quickly.
>
>> Do you perhaps have some misbehaving drivers in your system?
&
nothing was
there.
I did try to see the module when the blue screen was up, but
it rebooted too quickly.
Do you perhaps have some misbehaving drivers in your system?
Try clearing up your device manager.
SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 && mmc.exe devmgmt.msc
---
Didn't see
er" no admin privs (did a dropmyrights
> and verified that I only had traversal priv), of /proc/sys/Global\?\?/,
> it will blue screen my system every time.
After BSOD, there should be at least aminibump.
You can use http://nirsoft.net/utils/blue_screen_view.html to examine it.
> I
Someone else wrote:
Hi,
just tried that command. There is no BSOD on my system. Windows 10
latest build, Dell laptop with latest Cygwin.
Maybe there is an issue with your anti-virus or application firewall?
---
(same Disclaimer -- replying to list on email sent to me
privately... I w
On 2018-05-15 18:22, L A Walsh wrote:
> Someone wrote:
>> I tried it for the hell of it. It worked ok for me.
>> Running windows 10 - build 1803 -
>>
>> $ uname -a
>> CYGWIN_NT-10.0 spiro1 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin
>>
>> Running as an normal user - I did not try an admin acct
Someone wrote:
I tried it for the hell of it. It worked ok for me.
Running windows 10 - build 1803 -
$ uname -a
CYGWIN_NT-10.0 spiro1 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin
Running as an normal user - I did not try an admin acct.
Good luck,
someone
(FYI -- replying to this
> Greetings, Andrew Schulman!
>
> >> > screen 4.6.2-1 is now available in Cygwin. This is an upstream bug fix
> >> > release.
> >> > The release announcement says the release includes:
> >>
> >> > * Fixes:
> >> &g
Greetings, Andrew Schulman!
>> > screen 4.6.2-1 is now available in Cygwin. This is an upstream bug fix
>> > release.
>> > The release announcement says the release includes:
>>
>> > * Fixes:
>> > - revert changes to cursor positi
> Greetings, Andrew Schulman!
>
> > screen 4.6.2-1 is now available in Cygwin. This is an upstream bug fix
> > release.
> > The release announcement says the release includes:
>
> > * Fixes:
> > - revert changes to cursor position restore behavo
Greetings, Andrew Schulman!
> screen 4.6.2-1 is now available in Cygwin. This is an upstream bug fix
> release.
> The release announcement says the release includes:
> * Fixes:
> - revert changes to cursor position restore behavour (bug #51832)
> - set fre
screen 4.6.2-1 is now available in Cygwin. This is an upstream bug fix release.
The release announcement says the release includes:
* Fixes:
- revert changes to cursor position restore behavour (bug #51832)
- set freed pointer to NULL (bug #52133)
- documentation fixes
is omitted, the
current screen width is assumed.
So the issue is either that "%*" is printing 1 too many spaces, or that "\r" is
taking up a character when it should not be.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http:/
Greetings, Andrey Repin!
> # uname -a; screen --version; screen -admS mc-server-session
> CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> Screen version 4.05.01 (GNU) 25-Feb-17
> # screen -S mc-server-session -Q windows
>
> If I SEGV the hung child, th
Greetings, Andrey Repin!
> Greetings, All!
> # uname -a; screen --version; screen -admS mc-server-session
> CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> Screen version 4.05.01 (GNU) 25-Feb-17
> # screen -S mc-server-session -Q windows
>
Still
screen 4.6.1-1 is now available in Cygwin. This is an upstream release with bug
fixes and minor enhancements. See http://savannah.gnu.org/news/?group_id=4235
for the changelog.
screen is a full-screen window manager that multiplexes a physical terminal
between several processes, typically
Greetings, All!
> # uname -a; screen --version; screen -admS mc-server-session
> CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> Screen version 4.05.01 (GNU) 25-Feb-17
> # screen -S mc-server-session -Q windows
>
> If I SEGV the hung child, there'
> On Sat, May 27, 2017 at 4:27 AM, Andrey Repin wrote:
> > # uname -a; screen --version; screen -admS mc-server-session
> > CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> > Screen version 4.05.01 (GNU) 25-Feb-17
> >
> > # screen -S mc-serv
On Sat, May 27, 2017 at 4:27 AM, Andrey Repin wrote:
> # uname -a; screen --version; screen -admS mc-server-session
> CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> Screen version 4.05.01 (GNU) 25-Feb-17
>
> # screen -S mc-server-session -Q windows
>
Greetings, All!
# uname -a; screen --version; screen -admS mc-server-session
CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
Screen version 4.05.01 (GNU) 25-Feb-17
# screen -S mc-server-session -Q windows
If I SEGV the hung child, there's a stacktrace, though I don&#
> On Wed, May 3, 2017 at 11:45 AM, Nellis, Kenneth (Conduent) wrote:
> > FWIW, I also care about announcements. It's how I monitor whether or not I
> > should update. I hope they continue.
>
> Same here
OK, I hear you.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
estion or a cygwin X question
>> since I upgraded at the same time.
>>
>> Ever since my Fedora 25 upgrade, the menus from programs running on
>> the Linux box using cygwin x as the X server appear off screen at the
>> top left. It is impossible to use these menus.
>
>
On Wed, May 3, 2017 at 11:45 AM, Nellis, Kenneth (Conduent) wrote:
> FWIW, I also care about announcements. It's how I monitor whether or not I
> should update. I hope they continue.
Same here
-- Erik
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin
From: Andrew Schulman
> ...
> I confess to forgetting or just skipping announcements sometimes. It's hard
> for
> me to tell that anyone cares about them, although I see that you do. I will
> try
> to do better, though I guess if you don't see one from me you can assume
> nothing
> important cha
screen 4.5.1-2 is now available in Cygwin.
- For x86, this update applies a small patch that should have no effect, but
makes the source code the same as in x86_64. See
https://cygwin.com/ml/cygwin-apps/2017-05/msg00018.html for discussion.
- For x86_64, there's no change. The version numbe
Hi Shaddy.
> So I noticed my recent fresh install of Cygwin has screen 4.5.1-1
> installed. And the most recent release is 4.5.2-1.
4.5.1-2
> Previously, I tracked a problem with screen
> (https://sourceware.org/ml/cygwin/2014-05/msg00331.html)
> and sadly I know how involved
On 03/05/2017 05:23, Shaddy Baddah wrote:
Hi,
So I noticed my recent fresh install of Cygwin has screen 4.5.1-1
installed. And the most recent release is 4.5.2-1.
In any case, I didn't recall the updates for screen hitting my Inbox.
Looking at the mailing list, it appears to me
Hi,
So I noticed my recent fresh install of Cygwin has screen 4.5.1-1
installed. And the most recent release is 4.5.2-1.
I've been afflicted by a screen bug that popped up some releases ago
say about 1.5 year ago. Basically, after detach, the restored screen
buffer is mildly corrupted. An
On 18/02/2017 21:59, Eliot Moss wrote:
Dear friends -- I get the message above when I start cygwin emacs-X11
32-bit while running Cygwin-X. First of all, should I care? And if
No.
This message should probably be downgraded from an error.
I should, what can I do about it? Does this have to
Dear friends -- I get the message above when I start cygwin emacs-X11
32-bit while running Cygwin-X. First of all, should I care? And if
I should, what can I do about it? Does this have to do with the
command line parameters when starting the X server, for example?
Regards - Eliot Moss
--
Pro
I recently updated the screen package in Cygwin to version 4.5.0-1. This version
turns out to have at least one security problem [1], and maybe other serious
bugs too. So I've asked for it to be removed from the Cygwin archives.
If you've installed screen 4.5.0-1, you should downgr
screen 4.5.0-1 is now available in Cygwin. This is a new upstream release, with
bug fixes and one minor new feature. See
https://savannah.gnu.org/forum/forum.php?forum_id=8780 for the list of changes.
screen is a full-screen window manager that multiplexes a physical terminal
between several
t; > 2.6.0-0.5 test release I just announced.
> > > [...]
> > > I've done some interactive testing with this using
> > > the interpreter for a Lisp dialect. I would evaluate
> > > this expression to generate a 5 second delay and then
> > > a clear screen
h this using
the interpreter for a Lisp dialect. I would evaluate
this expression to generate a 5 second delay and then
a clear screen VT100 sequence:
(progn (usleep 500) (put-string "\e[2J"))
during this time, I would scroll the buffer somewhere.
I also tested with a cursor positi
interpreter for a Lisp dialect. I would evaluate
> this expression to generate a 5 second delay and then
> a clear screen VT100 sequence:
>
> (progn (usleep 500) (put-string "\e[2J"))
>
> during this time, I would scroll the buffer somewhere.
>
> I also t
On 29.07.2016 03:39, Corinna Vinschen wrote:
On Jul 28 21:51, Corinna Vinschen wrote:
However, the former cursor position in the buffer is still known
at clear screen time. It's stored in dev_console::dwEnd. So what
I was thinking about is to check the above situation and then, rather
th
On Jul 28 21:51, Corinna Vinschen wrote:
> However, the former cursor position in the buffer is still known
> at clear screen time. It's stored in dev_console::dwEnd. So what
> I was thinking about is to check the above situation and then, rather
> then to just keep it as is,
[] cursor
>| blank
>| blank window
>| blank ---+
>| blank |
>| blank |
>| blank ---+
>| blank
>+---
>
> Performing the clear screen in this situation, the cursor will be
> repositioned to the first line in the cu
7;t grow. It's a fixed size and the
scroll bar reflects this buffer size right from the start. So the user
can scroll the console windows down into the not yet used buffer area,
i.e.:
Before:
buffer
+---
| nonblank
| nonblank
| blank
| blank
| > [] cursor
| blank
On 28.07.2016 00:08, Corinna Vinschen wrote:
Thanks for testing. I'll check in the patch as is for now, but I'd
still be interested to fix the aforementioned empty lines problem,
even if just for completeness. If you have an idea, feel free to
propose.
Hi Corinna,
The blank lines above the c
I can do that, too. Just say the
> > word.
>
> The patch looks good and in many cases avoids padding the history with
> blank lines, compared to the naive newline emission approach.
>
> Usually, the clear screen operation is preceded by a homing of the cursor.
> I.e., in
nd in many cases avoids padding the history with
blank lines, compared to the naive newline emission approach.
Usually, the clear screen operation is preceded by a homing of the
cursor.
I.e., in VT100 language: ESC [ H, ESC [ 2 J. In this case, your
approach
seems to nicely trim the console da
:
>
> From: Kaz Kylheku
> Date: Wed, 27 Jul 2016 07:49:54 -0700
> Subject: Replace bogus resize-window-to-clear-screen logic.
>
> This removes (ab)uses of SetConsoleScreenBufferSize
> which sometimes cause cmd.exe to badly misbehave.
> It probably doesn't like the clo
clear-screen logic.
This removes (ab)uses of SetConsoleScreenBufferSize
which sometimes cause cmd.exe to badly misbehave.
It probably doesn't like the closely spaced timing of
shrinking the window down to one line followed by a restore
of the size. Instead we just output newlines to clear
1 - 100 of 764 matches
Mail list logo
