> > Sorry, this is wrong, enacs=\E)0 and smacs=\E(0, so the problem is enacs.
> > I don't know why urwid is using enacs. I will review that the definition
> > of it is correct, but again, it seems like an error of urwid.
I have checked the definitions, and there were an error in the
definition of
On Wed, Oct 08, 2014 at 09:11:35AM +0200, Roberto E. Vargas Caballero wrote:
> > > Sorry, this is wrong, enacs=\E)0 and smacs=\E(0, so the problem is enacs.
> > > I don't know why urwid is using enacs. I will review that the definition
> > > of it is correct, but again, it seems like an error of ur
St has enacs, which must be printed if a program requires to use
the alternate charset (graphic charset), that in st case was to
select charset graphic for G1, but it was not useful
at all because smacs and rmacs were always redefining the value
of G0.
---
st.info | 4 ++--
1 file changed, 2 inser
These sequences are the equivalents of LS0 and LS1, but for G2 and
G3.
---
st.c | 4
1 file changed, 4 insertions(+)
diff --git a/st.c b/st.c
index 19e4379..22a1ce6 100644
--- a/st.c
+++ b/st.c
@@ -2497,6 +2497,10 @@ eschandle(uchar ascii) {
case 'k': /* old title set compatibility *
SI (0x0F or ^O) means Shift In, and it selects G1 charset definition,
and SO (0x0E or ^N) means Shift Out, and it selects G0 charset
definition, but st was doing just the inverse.
---
st.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/st.c b/st.c
index c90bed1..19e437
> >If a compatible keyboard extension isn't present in the X server,
> >XkbBell calls XBell with the specified display and percent,
> >and returns False. Otherwise, XkbBell calls XkbDeviceBell
> >with the specified display, window, percent, and name, a device_spec
> >of XkbUseCoreKbd, a bell_class
Heyho,
I am using a status bar script written in go[0]. Recently I have noticed two
problems related to the time display, but first here is the relevant part of the
code:
for clock := range time.Tick(time.Second) {
// …
clock.Format("Mon 02 15:04:05")
Hi
On Wed, Oct 08, 2014 at 12:23:59PM +0200, Markus Teich wrote:
> Heyho,
>
> I am using a status bar script written in go[0]. Recently I have noticed two
> problems related to the time display, but first here is the relevant part of
> the
> code:
>
> for clock := range time.Tick(time.Sec
On Wed, Oct 08, 2014 at 12:23:59PM +0200, Markus Teich wrote:
> The second problem is when using ntp to synchronize the clock. In this
> case the channel provided by time.Tick() stops to send on that channel and
> therefore the whole loop stops and the status bar is not updated anymore.
>
> Can you
On Wed, Oct 8, 2014 at 11:23 AM, Markus Teich
wrote:
> Now the first problem occured when I was travelling to another timezone and
> updated my timezone information. Since clock only get's initialized once, we
> don't catch the new timezone info and the displayed time stays in the old
> timezone u
This patch installs lib9.a in ${DESTDIR}${PREFIX}/lib/ so it can be
linked against with -l9 (given the correct -L). I found that necessary
to compile y.tab.c generated by 9base's yacc due to sprint().
-emg
diff --git a/lib9/Makefile b/lib9/Makefile
index 8031113..b83ab2b 100644
--- a/lib9/Makefile
Brandon Mulcahy wrote:
> Is there a reason this wouldn't work?
>
> for {
> // ...
> time.Now().Format("Mon 02 Ý 15:04:05"),
> // ...
> time.Sleep(time.Second)
> }
This would work of course, but it leaves one tiny little feature out, which I
would like to have if it is basi
Silvan Jegen wrote:
> In this issue https://code.google.com/p/go/issues/detail?id=6007 in answer #30
> they mention that they use a monotonic clock on Linux now with Go 1.3 and up
> which should solve this (this is the commit
> https://code.google.com/p/go/source/detail?r=79f855ac890d ). What platf
On Thu, Oct 09, 2014 at 04:17:29AM +0200, Markus Teich wrote:
> Brandon Mulcahy wrote:
> > Is there a reason this wouldn't work?
> >
> > for {
> > // ...
> > time.Now().Format("Mon 02 Ý 15:04:05"),
> > // ...
> > time.Sleep(time.Second)
> > }
>
> The for loop you recommended takes
14 matches
Mail list logo