Eric Pruitt writes:
> [...]
>
> If it were _just_ brighter, I probably wouldn't care, but to me, the
> difference in color is like night and day. I understand that I'm an
> obvious minority in caring about the difference which is why I didn't
> request the patch I submitted get merged into master;
Perhaps I've missed something deep in the simplicity of sbase that
makes it unnecessary, but is there any plan to implement the POSIX
-F flag for grep?
Thanks,
--
Wolfgang Corcoran-Mathe
On Wed, May 21, 2014 at 07:35:50PM -0700, Charlie Kester wrote:
> Maybe this is one of those things like hi-fidelity stereo equipment where
> some people are acutely aware of differences the hoi polloi can't perceive,
> but whatever differences *I* can see don't seem worth fussing about. I don't
>
On Wed 21 May 2014 at 15:31:18 PDT Eric Pruitt wrote:
I'm curious what non-st terminal emulator you use. On Urxvt, my all
colors beyond #16 look the same as in Xterm without any changes to my
Xresources file or the need to recompile Urxvt. Likewise for MinTTY and
its parent PuTTY. You can even s
On Wed, May 21, 2014 at 11:54:48PM +0200, Roberto E. Vargas Caballero wrote:
> Sorry, it is not a standard behaviour, it is only the xterm behaviour.
> I can say you that any of the terminals that I use (real terminals
> or terminal emulatorts) have this behaviour.
I'm curious what non-st terminal
> Read this: http://www.4p8.com/eric.brasseur/gamma.html
>
> We need to generally re-think the algorithm used here. I hate the idea
> of being conformant to this or that terminal emulator and instead
> prefer an implementation according to how it's defined (!).
I like this idea, but I don't know
> On Wed, May 21, 2014 at 11:04:02PM +0200, FRIGN wrote:
> > Predictability =!= Common Behaviour.
> >
> > Just because "everyone" does it, doesn't make it right!
Last week I met a worker of Red Hat in a conference, and he tried
to convience me about why is impossible to avoid that software
become
On Wed, May 21, 2014 at 11:04:02PM +0200, FRIGN wrote:
> Predictability =!= Common Behaviour.
>
> Just because "everyone" does it, doesn't make it right!
But "brightening" colors by incrementing the number is? I'm not sure why
you so vehemently defend a broken implementation of uncommon feature.
Y
On Wed, 21 May 2014 16:21:05 -0400
Nick wrote:
> This seems like a reasonable point to me. If increasing brightness
> of coloured text isn't something we can do accurately by changing
> the colour, in the limitations of 256 colour, doing as this patch
> does sounds sensible to me.
Read this:
On Wed, 21 May 2014 15:05:08 -0500
Eric Pruitt wrote:
> You _just_ stated that "It's about predictability." What makes xterm the
> authority? The fact that every application and terminal emulator that
> supports 256 color schemes and 256 color expects them to be and renders
> them in accordance t
I thought I'd re-read this thread, as it was brought up again
recently.
Quoth Eric Pruitt:
> On Mon, Dec 02, 2013 at 10:54:54AM +0100, Christoph Lohmann wrote:
> > > Brilliant! I feel silly for not noticing it only affected the bold
> > > colors. The fix was simple, and I've attached a patch in t
On Wed, May 21, 2014 at 10:00:38PM +0200, FRIGN wrote:
> > If that's your defense, then my patch should be applied to st. That was
> > the only time I've used a 256 color terminal emulator and had anything
> > beyond the 16 color ANSI(?) range be different from xterm.
>
> In which way is xterm the
On Wed, 21 May 2014 14:55:10 -0500
Eric Pruitt wrote:
> If that's your defense, then my patch should be applied to st. That was
> the only time I've used a 256 color terminal emulator and had anything
> beyond the 16 color ANSI(?) range be different from xterm.
In which way is xterm the authori
On Wed, May 21, 2014 at 09:47:13PM +0200, FRIGN wrote:
> What do you define by "color compatibility" anyway? Do you take a
> screenshot of your terminal and compare it with ones from other
> terminals?
I didn't even need to take a screenshot to tell the difference. The
first time I loaded up Vim,
On Wed, 21 May 2014 14:34:18 -0500
Eric Pruitt wrote:
> I would think so as well, but I've been wrong before; apparently
> breaking color compatibility with practically every other terminal with
> 256 color support [is a feature][1], so some commentary from one of the
> official / core maintainer
> > Is this a bug or deliberate design decision?
>
> A bug, presumably.
Yes, I agree. The copy part could be improved a lot, because we have some
problems with it now (for example the tab to space conversion is ugly).
--
Roberto E. Vargas Caballero
On Wed, May 21, 2014 at 03:14:02PM -0400, Nick wrote:
> Oh, I know why. It's because it's in the copy part, not the paste
> part; try "printf 'XXX\n\n\nXXX\n' | xclip" and it'll paste fine in
> st. I guess I don't copy much out of terminals using the mouse.
Yes, I understood the fault was on st's
Quoth Eric Pruitt:
> When copying text from st, all intermittent blank lines get removed. For
I can confirm this, with tip and 0.5 and 0.4. I'm surprised I hadn't
really noticed it before.
Oh, I know why. It's because it's in the copy part, not the paste
part; try "printf 'XXX\n\n\nXXX\n' | xcl
When copying text from st, all intermittent blank lines get removed. For
example, if I run "printf 'XXX\n\n\nXXX\n'" then copy and paste the
printed text, I get:
XXX
XXX
Instead the expected:
XXX
XXX
Is this a bug or deliberate design decision?
Eric
19 matches
Mail list logo
