Applied, thanks.
The control flow is necessary in a terminal because you have two
asynchronous process, one in the terminal and another in the computer,
comunicate between them through a serial line using buffers in every
side. When one of this buffer is full, then it must signal to the
other process because in ot
> Your patch makes st echo STOP and START signals. It is just wrong. If
> the other end says 'STOP', st should stop sending and buffer what it is
> going to send. It is already done in the kernel so we should not worry
> about it even if the other end is a real terminal and user pastes a huge
> buf
On Sun, Apr 19, 2015 at 10:40:18AM +0200, Roberto E. Vargas Caballero wrote:
> > As per "The C Programming Language 2nd Edition" and the BSD style guide,
> > the "proper" way to loop infinitely in C is "for(;;)".
> > I agree about moving the assignment out of the loop initialization
> > though. It
On Sun, Apr 19, 2015 at 02:52:18PM -0400, Alex Pilon wrote:
> On Sun, Apr 19, 2015 at 02:36:35PM -0300, Amadeus Folego wrote:
> > Alex, you just posted the diffstat, not the patch itself.
>
> I know. I was only proving a point about it being small and trying to
> reduce the noise, though moot now.
> On Sun, Apr 19, 2015 at 01:05:50PM -0400, Alex Pilon wrote:
> > Is there much appetite for flow control support in
> > what-shall-we-call-it—‘mainline’?
> >
> > I occasionally have a use for it, but would rather not further feature
> > creep into what everybody else uses without darn good reason.
LEN(colorname) may be below 256 for some configurations.
---
st.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/st.c b/st.c
index 759a3b1..0b2997e 100644
--- a/st.c
+++ b/st.c
@@ -2906,7 +2906,7 @@ xsetcolorname(int x, const char *name) {
XRenderColor color = { .alpha
---
st.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/st.c b/st.c
index bb8c365..759a3b1 100644
--- a/st.c
+++ b/st.c
@@ -2868,11 +2868,10 @@ xloadcols(void) {
int i;
XRenderColor color = { .alpha = 0x };
static bool loaded;
- Color *cp
---
st.c | 84
1 file changed, 30 insertions(+), 54 deletions(-)
diff --git a/st.c b/st.c
index 0b2997e..8c88e47 100644
--- a/st.c
+++ b/st.c
@@ -414,6 +414,7 @@ static void xhints(void);
static void xclear(int, int, int, int);
On Sun, Apr 19, 2015 at 01:05:50PM -0400, Alex Pilon wrote:
> Is there much appetite for flow control support in
> what-shall-we-call-it—‘mainline’?
>
> I occasionally have a use for it, but would rather not further feature
> creep into what everybody else uses without darn good reason.
How do yo
On Sun, Apr 19, 2015 at 02:36:35PM -0300, Amadeus Folego wrote:
> Alex, you just posted the diffstat, not the patch itself.
I know. I was only proving a point about it being small and trying to
reduce the noise, though moot now. Should have attached it in the first
place. Made it shorter now too.
Alex, you just posted the diffstat, not the patch itself.
Is there much appetite for flow control support in
what-shall-we-call-it—‘mainline’?
I occasionally have a use for it, but would rather not further feature
creep into what everybody else uses without darn good reason.
It's tiny anyway.
commit db60d9e32c91f5c209b7df1290bd3a9c7a3cfdfe
Auth
I've added a manpage and applied all of FRIGN and Hiltjo's style
changes.
Regards,
--
Wolfgang Corcoran-Mathe
#include
#include
#include
#include
#include
#include "arg.h"
#include "text.h"
#include "utf.h"
#include "util.h"
enum {
INIT = 1,
GROW = 2,
};
enum {
EX
> To be clear, in my opinion -f should ignore -r and suppress the total
> block count for -lgnos, and take a 'fast track' function where it just
> prints directory entries as it encounters them, rather than reading
> them all into memory and waiting until the end before (not) sorting
> them and pri
On 19 April 2015 at 15:47, Connor Lane Smith wrote:
> That's why -r is to be ignored,
> and -lgnos may be ignored: because they are all problematic for that
> behaviour (e.g. because they require that the directory be preceded by
> a total block count).
To be clear, in my opinion -f should ignore
On 19 April 2015 at 12:41, FRIGN wrote:
> > enum { AlphaSort, SizeSort = 'S', TimeSort = 't' },
>
> Rather use an "int sorttype = 'a';" and change it while parsing the flags.
So exactly what I said except using an int instead of an enum? That's
fine too, although the compiler won't then be aware
>> To be honest, it's a bit weird how -St are separate booleans, given
>> the fact that you could really better define the behaviour of those
>> flags with an enum { AlphaSort, SizeSort = 'S', TimeSort = 't' },
>> rather than having to always ensure that Sflag and tflag are not both
>> true at once
On Sun, 19 Apr 2015 10:50:06 +0100
Connor Lane Smith wrote:
> To be honest, it's a bit weird how -St are separate booleans, given
> the fact that you could really better define the behaviour of those
> flags with an enum { AlphaSort, SizeSort = 'S', TimeSort = 't' },
> rather than having to alway
Hi,
On 19 April 2015 at 09:16, Quentin Rameau wrote:
> I noticed that ls didn't really behaved as stated by POSIX so I worked
> a little on that. Here are four patches, the second one introduce big
> changes, so I'll be glad if you could review it.
1. Rather than turning off, and refusing to tur
> As per "The C Programming Language 2nd Edition" and the BSD style guide,
> the "proper" way to loop infinitely in C is "for(;;)".
> I agree about moving the assignment out of the loop initialization
> though. It is cleaner this way.
I totally agree. for (;;) is the only one true ;). I will rev
On Sun, Apr 19, 2015 at 4:16 AM, Quentin Rameau wrote:
>
> Hi,
> I noticed that ls didn't really behaved as stated by POSIX so I worked
> a little on that. Here are four patches, the second one introduce big
> changes, so I'll be glad if you could review it.
> Thanks!
Hey,
Just a question - hav
On 04/18/2015 06:45 PM, noname wrote:
---
st.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/st.c b/st.c
index 3fa58da..30f296d 100644
--- a/st.c
+++ b/st.c
@@ -3930,8 +3930,9 @@ run(void) {
clock_gettime(CLOCK_MONOTONIC, &last);
lastblink = last;
+
Hi,
I noticed that ls didn't really behaved as stated by POSIX so I worked
a little on that. Here are four patches, the second one introduce big
changes, so I'll be glad if you could review it.
Thanks!
0001-ls-fix-f-flag.patch
Description: Binary data
0002-ls-rework-of-the-display-and-recursion
24 matches
Mail list logo
