On Sun, Dec 20, 2020 at 11:39:15PM +, Thorsten Glaser wrote:
> Thomas Dickey dixit:
>
> >I'm guessing that it's timing, e.g., xterm could wait a few milliseconds
> >to retry and then give up on that loop, in case the window events don't
> >arrive rapidly enough.
>
> “rapidly enough” as
Thomas Dickey dixit:
>I'm guessing that it's timing, e.g., xterm could wait a few milliseconds
>to retry and then give up on that loop, in case the window events don't
>arrive rapidly enough.
“rapidly enough” as criterium isn’t going to help everyone.
We have multi-GHz desktop bolides, few-MHz
On Sun, Dec 20, 2020 at 10:40:39PM +, Thorsten Glaser wrote:
> Thomas Dickey dixit:
>
> >how far below?
> >
> >Just the window-decoration, or a line or so?
>
> About a line, give or take (for the syslog window, the last line
> is the cursor, so I don’t need it, and I took a bit more than a
>
Thomas Dickey dixit:
>how far below?
>
>Just the window-decoration, or a line or so?
About a line, give or take (for the syslog window, the last line
is the cursor, so I don’t need it, and I took a bit more than a
line there; for that test, it’s a bit less).
>Looking at the changes for #361,
On Sun, Dec 20, 2020 at 07:47:15PM +, Thorsten Glaser wrote:
> Thomas Dickey dixit:
>
> >I see that version in testing, but don't see a problem on the screen.
> >I made a short script to cat those lines to the terminal, sleeping 0.2
> >seconds between bursts, and the result looks ok, even
On Sun, 20 Dec 2020, Thorsten Glaser wrote:
> corruption effects which vary (see screenshot).
Oops, attached.
Thomas Dickey dixit:
>I see that version in testing, but don't see a problem on the screen.
>I made a short script to cat those lines to the terminal, sleeping 0.2
>seconds between bursts, and the result looks ok, even with a magnifier.
Indeed, tricky. I experimented with this a bit.
I can
On Fri, Nov 27, 2020 at 12:04:07AM +, Thorsten Glaser wrote:
> Hi Thomas,
>
> >If you're going to compile it, the debug-trace can be useful
> >(--enable-trace). If not, the -report-fonts option is helpful.
>
> I hadn’t recompiled, at least not with actual changes.
> The -report-fonts output
Hi Thomas,
>If you're going to compile it, the debug-trace can be useful
>(--enable-trace). If not, the -report-fonts option is helpful.
I hadn’t recompiled, at least not with actual changes.
The -report-fonts output is attached, fNorm is the one
in question.
I did a little bisecting: Debian’s
On Thu, Nov 26, 2020 at 10:52:38PM +, Thorsten Glaser wrote:
> Thomas Dickey dixit:
>
> >"Recently" could be something overlooked in #362's change
>
> No, 362 is the current one, and I definitely had this in
> the previous version shipped in Debian as well, but I can’t
> narrow it down
Thomas Dickey dixit:
>"Recently" could be something overlooked in #362's change
No, 362 is the current one, and I definitely had this in
the previous version shipped in Debian as well, but I can’t
narrow it down further than that. According to apt history
log, that was 361.
>On the other hand
On Wed, Nov 25, 2020 at 06:26:14AM +0100, Thorsten Glaser wrote:
> Package: xterm
> Version: 362-1
> Severity: normal
> X-Debbugs-Cc: t...@mirbsd.de
>
> I’ve got the following in my ~/.xinitrc…
>
> /usr/bin/xterm +sb -fg black -geom 78x10+1+637 \
> -bg slateblue -e top &
>
Package: xterm
Version: 362-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I’ve got the following in my ~/.xinitrc…
/usr/bin/xterm +sb -fg black -geom 78x10+1+637 \
-bg slateblue -e top &
/usr/bin/xterm +sb -fg black -geom 90x11+475+637 \
-bg
13 matches
Mail list logo
