Hi,
* Christoph Lohmann 2014-08-02 11:34
> As mentioned in my last e‐mail: The number of sucking e‐mail providers
> is greater than two, which requires variable blinking definitions to im‐
> plement e‐mail awareness correctly.
>
> Thinking this further would allow a simple integration of a glob
On Sat, 02 Aug 2014 11:20:38 +0200
Christoph Lohmann <2...@r-36.net> wrote:
> There are two use cases for two blinking modes: Showing the advanced
> technology of st. If the refactoring works, this shows the flexibility
> of the st vt100 implementation. It’s a bit like the DEC test sequenc
Greetings.
On Sat, 02 Aug 2014 11:25:45 +0200 sta...@cs.tu-berlin.de wrote:
> * Markus Teich 2014-07-31 12:39
> > at suckless conf last year 20h mentioned, he originally implemented blinking
> > support to warn him about outlook and gmail users in mutt.
>
> epic!
>
> then he clearly needs at le
Greetings.
On Sat, 02 Aug 2014 11:20:38 +0200 "Roberto E. Vargas Caballero"
wrote:
> > > I use it in mutt to show the mails that are in delete state.
> >
> > Do you need two blinking modes for that?
>
> I was talking about the normal blinking.
>
> > Seems like the topic has closed itself.
>
On Thu, 31 Jul 2014 21:29:43 +0200
"Roberto E. Vargas Caballero" wrote:
> I just patched it, but maybe could be a good idea define this issue
> and follow a common criterion.
Good idea. I'll do it next time.
--
FRIGN
> Just push the patch, there's no need for me to sign it. Signing off is
> only meant for the original authors (read about the SCO lawsuit[0]).
The real meaning of signed-off depends of each project. In st, we are
uing it as a way to indicate who verify the patch was correct. Thre is
other tags th
On Thu, 31 Jul 2014 20:17:34 +0200
"Roberto E. Vargas Caballero" wrote:
> And it was for FRIGN, since the discussion was between him and me. Sorry
> for not indicate the name.
Just push the patch, there's no need for me to sign it. Signing off is
only meant for the original authors (read about t
> I was talking about a git sign, something like:
>
> Signed-off-by: Roberto E. Vargas Caballero
>
> that it is included with 'git commit --amend -s'. Basically it was
> a proposal of peer review, in the sense you tested it and you agree ;).
And it was for FRIGN, since the discussion was
> seems legit, however I will not cryptographically sign it, since it is not my
> work. ;)
I was talking about a git sign, something like:
Signed-off-by: Roberto E. Vargas Caballero
that it is included with 'git commit --amend -s'. Basically it was
a proposal of peer review, in the sens
On Thu, 31 Jul 2014 19:45:47 +0200
"Roberto E. Vargas Caballero" wrote:
> Ok, let's go. If you agree, sign the patch that I attach to this mail and then
> I will apply it.
Yeah, push it. It's good!
--
FRIGN
Roberto E. Vargas Caballero wrote:
> Ok, let's go. If you agree, sign the patch that I attach to this mail and then
> I will apply it.
Heyho Roberto,
seems legit, however I will not cryptographically sign it, since it is not my
work. ;)
--Markus
> > > There is no such kind of user! Realize it! It's the wrong way to go
> >
> > Hahaha ;). I would like to see the opinion of another suckless developers.
> > What do you think guys?.
>
> Heyho,
>
> at least there should be no such user who is unable to figure the fallthrough
> thing out… Be a
Roberto E. Vargas Caballero wrote:
> > Please don't bring this argument here. You are talking about an
> > imaginary user who is keen on patching st for a faster blinking mode.
> >
> > There is no such kind of user! Realize it! It's the wrong way to go
>
> Hahaha ;). I would like to see the opini
> Please don't bring this argument here. You are talking about an
> imaginary user who is keen on patching st for a faster blinking mode.
>
> There is no such kind of user! Realize it! It's the wrong way to go
Hahaha ;). I would like to see the opinion of another suckless developers.
What do you
you're doing great job with st, guys, keep up! didn't want to distract
you from the discussion but couldn't resist 20h's briliant irony. --s
On Thu, 31 Jul 2014 14:29:09 +0200
"Roberto E. Vargas Caballero" wrote:
> Well, I think is good idea have two flags instead of only one.
> If someone really needs two blink modes, he must be able to patch it
> easily, and do the or of both flags is not complex.
Please don't bring this argument h
On Thu, 31 Jul 2014 14:09:23 +0200
sta...@cs.tu-berlin.de wrote:
> then he clearly needs at least two blinking modes: one for each. what
> about hotmail?
Haha, get lost :P
As Roberto presented in his previous response, the
terminal-implementations are way too different from each other anyway.
It
> Exactly! Keep it the way it is and just fall through in the switch.
> It's 100 times simpler and it keeps the code lean.
Well, I think is good idea have two flags instead of only one.
If someone really needs two blink modes, he must be able to patch it
easily, and do the or of both flags is not
* Markus Teich 2014-07-31 12:39
> at suckless conf last year 20h mentioned, he originally implemented blinking
> support to warn him about outlook and gmail users in mutt.
epic!
then he clearly needs at least two blinking modes: one for each. what
about hotmail?
On Thu, 31 Jul 2014 13:50:18 +0200
"Roberto E. Vargas Caballero" wrote:
> I was talking about the normal blinking.
Sure that! No one needs two modes. ;)
> It seems that almost of the developer agree that we only need one
> blinking. The thing we have to do now is blink in both cases (with
> the
> > I use it in mutt to show the mails that are in delete state.
>
> Do you need two blinking modes for that?
I was talking about the normal blinking.
> Seems like the topic has closed itself.
It seems that almost of the developer agree that we only need one
blinking. The thing we have to do no
On Thu, 31 Jul 2014 12:54:15 +0200
"Roberto E. Vargas Caballero" wrote:
> I use it in mutt to show the mails that are in delete state.
Do you need two blinking modes for that?
Seems like the topic has closed itself.
--
FRIGN
> at suckless conf last year 20h mentioned, he originally implemented blinking
> support to warn him about outlook and gmail users in mutt. I don't know of any
> better use case for blinking.
I use it in mutt to show the mails that are in delete state.
--
Roberto E. Vargas Caballero
On Thu, 31 Jul 2014 12:41:17 +0200
Markus Teich wrote:
> at suckless conf last year 20h mentioned, he originally implemented blinking
> support to warn him about outlook and gmail users in mutt. I don't know of any
> better use case for blinking.
I like his sense of humour.
--
FRIGN
FRIGN wrote:
> I honestly have to say that I don't favor the fast-blinking-patch at
> all. How often do you stumble upon blinking-tags anyway?
Heyho,
at suckless conf last year 20h mentioned, he originally implemented blinking
support to warn him about outlook and gmail users in mutt. I don't kno
On Thu, 31 Jul 2014 12:10:43 +0200
"Roberto E. Vargas Caballero" wrote:
> Yeah, it is true. I will apply it only if it fits well in the new
> main-loop. I have modified the original patch and now it may be applied
> to HEAD. The patch itself is not bad, and the complexity it pays for two
> blinks
> I honestly have to say that I don't favor the fast-blinking-patch at
> all. How often do you stumble upon blinking-tags anyway? Even if there
> is a broad application of it in some program I don't know about, I'm
> absolutely sure that the dependency on two blinking speeds is just
> ridiculuous!
On Thu, 31 Jul 2014 11:32:11 +0200
"Roberto E. Vargas Caballero" wrote:
> The case 26 is a bit different, because we implemented fast blinking
> with normal blinking, and he sent a patch to have a correct fast
> blinking. I have not applied it yet, but I think I am going to apply it.
I honestly
> > I think you can find information about them in the same reference that
> > Michael Forney posted.
>
> Yeah, I just wanted to know if he had another document with different
> behaviors, I’m particularly curious about his cases 21 and 26.
The case 21 was in the code before the patches of Anders
On Mon, Jul 28, 2014 at 12:35:54PM +0200, Roberto E. Vargas Caballero wrote:
> > > Faint, invisible, struck and fast blink are added as glyph attributes.
> > > Since there's an edit here, let's take the opportunity to reorder them
> > > so that they correspond to the two's power of the correspondin
> > Faint, invisible, struck and fast blink are added as glyph attributes.
> > Since there's an edit here, let's take the opportunity to reorder them
> > so that they correspond to the two's power of the corresponding escape
> > code. (just for neatness, let's hope that property never gets used for
Hi,
On Tue, Jun 24, 2014 at 11:45:42PM +0200, Anders Eurenius wrote:
> From eedd5902aa34efb9d2cd7bd2565286753a318c64 Mon Sep 17 00:00:00 2001
> From: Anders Eurenius
> Date: Sat, 21 Jun 2014 20:29:36 +0200
> Subject: [PATCH 1/8] Reorder and extend glyph attributes
>
> Faint, invisible, struck an
I will apply this patch. Even if we don't implement at the end any
difference between fast and slow blinking, I think is a good idea at least
have different bits for them. The same criteria apply to faint, struck
and invisible bits.
Regards,
--
Roberto E. Vargas Caballero
Ok, no problem.
aes
From eedd5902aa34efb9d2cd7bd2565286753a318c64 Mon Sep 17 00:00:00 2001
From: Anders Eurenius
Date: Sat, 21 Jun 2014 20:29:36 +0200
Subject: [PATCH 1/8] Reorder and extend glyph attributes
Faint, invisible, struck and fast blink are added as glyph attributes.
Since there's a
34 matches
Mail list logo