Re: [dev] [st] Understading st behaviour
The issue is that the command xmonad uses to spawn st double-forks the process, making the SIGHUP signal not being sent to the correct pid. See [1]. Uh. I think this is a fault of momad, but, do you know why another terminal emulators work fine even with this double fork? Regards, -- Roberto E. Vargas Caballero
[dev] OpenBSD takes a stab at SSL
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/
[dev] [PATCH] Don't make bold text bright with default color
From: Yuri Karaban d...@dev97.com Hello, I found that st behavior is inconsistent with XTerm and RXVT in regard to handling bold text. XTerm and RXVT are not making bold font bright if default color is used (with light background and black foreground it's looking rather ugly, brightened black font becomes gray and unreadable on light gray background). There is one subtle detail, foreground color is not brightened only if it's implicit, therefore if default color is black: echo -e \033[1m Bold but not bright should print the string in bold with black color but when black is specified explicitly like: echo -e \033[30;1m Bold and bright or echo -e \033[30m \033[1m Bold and bright it should print the string in bold but with gray (brightened) color. Please consider adopting standard behavior, otherwise it's making the bold text hard to read on a gray background ;-) Yuri Karaban (1): Show bold glyphs in bright color only when color is explicit st.c | 29 +++-- 1 file changed, 19 insertions(+), 10 deletions(-) -- 1.9.2
[dev] [PATCH] Show bold glyphs in bright color only when color is explicit
From: Yuri Karaban d...@dev97.com
This makes behavior consistent with XTerm and RXVT. When default
foreground color is black (implicit):
echo -e \033[1m Bold but not bright
should show bold black string, and when color is explicit (black too):
echo -e \033[30;1m Bold and bright
or
echo -e \033[30m\033[1m Bold and bright
should show bold gray (brightened) string.
---
st.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/st.c b/st.c
index df660ff..accba74 100644
--- a/st.c
+++ b/st.c
@@ -185,6 +185,7 @@ typedef struct {
ushort mode; /* attribute flags */
uint32_t fg; /* foreground */
uint32_t bg; /* background */
+ bool fgcustcolor; /* custom foreground color is in effect */
} Glyph;
typedef Glyph *Line;
@@ -1703,6 +1704,7 @@ tsetattr(int *attr, int l) {
| ATTR_BLINK);
term.c.attr.fg = defaultfg;
term.c.attr.bg = defaultbg;
+ term.c.attr.fgcustcolor = False;
break;
case 1:
term.c.attr.mode |= ATTR_BOLD;
@@ -1738,11 +1740,14 @@ tsetattr(int *attr, int l) {
term.c.attr.mode = ~ATTR_REVERSE;
break;
case 38:
- if ((idx = tdefcolor(attr, i, l)) = 0)
+ if ((idx = tdefcolor(attr, i, l)) = 0) {
term.c.attr.fg = idx;
+ term.c.attr.fgcustcolor = True;
+ }
break;
case 39:
term.c.attr.fg = defaultfg;
+ term.c.attr.fgcustcolor = False;
break;
case 48:
if ((idx = tdefcolor(attr, i, l)) = 0)
@@ -1754,10 +1759,12 @@ tsetattr(int *attr, int l) {
default:
if(BETWEEN(attr[i], 30, 37)) {
term.c.attr.fg = attr[i] - 30;
+ term.c.attr.fgcustcolor = True;
} else if(BETWEEN(attr[i], 40, 47)) {
term.c.attr.bg = attr[i] - 40;
} else if(BETWEEN(attr[i], 90, 97)) {
term.c.attr.fg = attr[i] - 90 + 8;
+ term.c.attr.fgcustcolor = True;
} else if(BETWEEN(attr[i], 100, 107)) {
term.c.attr.bg = attr[i] - 100 + 8;
} else {
@@ -3153,15 +3160,17 @@ xdraws(char *s, Glyph base, int x, int y, int charlen,
int bytelen) {
}
if(base.mode ATTR_BOLD) {
- if(BETWEEN(base.fg, 0, 7)) {
- /* basic system colors */
- fg = dc.col[base.fg + 8];
- } else if(BETWEEN(base.fg, 16, 195)) {
- /* 256 colors */
- fg = dc.col[base.fg + 36];
- } else if(BETWEEN(base.fg, 232, 251)) {
- /* greyscale */
- fg = dc.col[base.fg + 4];
+ if (base.fgcustcolor) {
+ if(BETWEEN(base.fg, 0, 7)) {
+ /* basic system colors */
+ fg = dc.col[base.fg + 8];
+ } else if(BETWEEN(base.fg, 16, 195)) {
+ /* 256 colors */
+ fg = dc.col[base.fg + 36];
+ } else if(BETWEEN(base.fg, 232, 251)) {
+ /* greyscale */
+ fg = dc.col[base.fg + 4];
+ }
}
/*
* Those ranges will not be brightened:
--
1.9.2
Re: [dev] OpenBSD takes a stab at SSL
On Tue, 15 Apr 2014 16:31:22 +0200 Jakub Lach jakub_l...@mailplus.pl wrote: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/ I stumbled upon it via [1]. I'm glad this idea finally is being realized. Discussing this topic with many of my colleagues, there definitely is need for a community of skilled developers like OpenBSD to make OpenSSL suck less. Imho, re-releasing it under OpenTLS would be a great idea! What do you think about this fork finally getting rid of backwards-compatibility and welcoming maintainable code and less bugs? Cheers FRIGN [1]: https://lobste.rs/s/3utipo/openbsd_has_started_a_massive_strip-down_and_cleanup_of_openssl/comments/fkwgqw -- FRIGN d...@frign.de
Re: [dev] [PATCH] Don't make bold text bright with default color
if default color is used (with light background and black foreground it's looking rather ugly, brightened black font becomes gray and unreadable on light gray background). If you don't like you can always change the background. Please consider adopting standard behavior, otherwise it's making the bold text hard to read on a gray background ;-) standard? could you explain what standard are you talking?, because I think no iso, or ansi, or whenever you want made a standard about it. Regards, -- Roberto E. Vargas Caballero
Re: [dev] OpenBSD takes a stab at SSL
Greetings. On Tue, 15 Apr 2014 17:26:30 +0200 FRIGN d...@frign.de wrote: On Tue, 15 Apr 2014 16:31:22 +0200 Jakub Lach jakub_l...@mailplus.pl wrote: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/ I stumbled upon it via [1]. I'm glad this idea finally is being realized. Discussing this topic with many of my colleagues, there definitely is need for a community of skilled developers like OpenBSD to make OpenSSL suck less. Imho, re-releasing it under OpenTLS would be a great idea! What do you think about this fork finally getting rid of backwards-compatibility and welcoming maintainable code and less bugs? Hopefully the API will be sanitized too and the BIO buffer code be re‐ moved. Sincerely, Christoph Lohmann
Re: [dev] [PATCH] Don't make bold text bright with default color
REVC == Roberto E Vargas Caballero k...@shike2.com writes: if default color is used (with light background and black foreground it's looking rather ugly, brightened black font becomes gray and unreadable on light gray background). REVC If you don't like you can always change the background. Quite the opposite, I like my background color and I don't want to change it. Bold colors are brightened to stand out even more. But with the light background and dark foreground brightening acts contrary making the letters less emphasized. Please consider adopting standard behavior, otherwise it's making the bold text hard to read on a gray background ;-) REVC standard? could you explain what standard are you talking?, REVC because I think no iso, or ansi, or whenever you want made a REVC standard about it. Don't jeer, believe you understood that I mean de-facto standards (xterm, rxvt, gnome terminals based on libvte, etc.). Every terminal which I tried behaves consistently (doesn't brighten implicit default foreground with bold face). You may try yourself escape sequences which I provided. I'm sorry for disturbing you, I thought my observation would be useful. I was wrong. -- Concordia salus.
Re: [dev] [PATCH] Don't make bold text bright with default color
Greetings. On Tue, 15 Apr 2014 17:49:20 +0200 Yuri Karaban suckl...@dev97.com wrote: REVC == Roberto E Vargas Caballero k...@shike2.com writes: if default color is used (with light background and black foreground it's looking rather ugly, brightened black font becomes gray and unreadable on light gray background). REVC If you don't like you can always change the background. Quite the opposite, I like my background color and I don't want to change it. Bold colors are brightened to stand out even more. But with the light background and dark foreground brightening acts contrary making the letters less emphasized. Please consider adopting standard behavior, otherwise it's making the bold text hard to read on a gray background ;-) REVC standard? could you explain what standard are you talking?, REVC because I think no iso, or ansi, or whenever you want made a REVC standard about it. Don't jeer, believe you understood that I mean de-facto standards (xterm, rxvt, gnome terminals based on libvte, etc.). Every terminal which I tried behaves consistently (doesn't brighten implicit default foreground with bold face). You may try yourself escape sequences which I provided. I'm sorry for disturbing you, I thought my observation would be useful. I was wrong. You give up too easily. Sincerely, Christoph Lohmann
Re: [dev] [PATCH] Don't make bold text bright with default color
Hi Christoph! Probably, but would it be better if I stay and continue to irritate habitues? Si fueris Romae, Romano vivito more; Si fueris alibi, vivito sicut ibi. (When at Rome, do as the Romans do.) CL == Christoph Lohmann 2...@r-36.net writes: CL Greetings. CL You give up too easily. -- Deus vult!
Re: [dev] [PATCH] Don't make bold text bright with default color
Greetings. On Tue, 15 Apr 2014 18:20:11 +0200 Yuri Karaban suckl...@dev97.com wrote: Hi Christoph! Probably, but would it be better if I stay and continue to irritate habitues? We don’t like sissies turning around after the first question. Sincerely, Christoph Lohmann
Re: [dev] [st] Understading st behaviour
On Thu, Apr 10, 2014 at 05:03:33PM -0300, Amadeus Folego wrote: I probably discovered why this happens. The WM_DELETE_WINDOW command is being received with success, I tested it. The issue is that the command xmonad uses to spawn st double-forks the process, making the SIGHUP signal not being sent to the correct pid. See [1]. So the question remains if we should cover this case or not, since xmonad's approach is probably nonsense. I never experienced this with other applications though. [1]: http://xmonad.org/xmonad-docs/xmonad/src/XMonad-Core.html#spawn How would the way in which st was started interfere with its ability to kill the process it spawned? No, you have to take a step back: What is the problem here? mutt is not being killed. mutt, however, runs inside the shell that runs inside st. And you quit st. So, what happened? st reacted to the DELETE_WINDOW message by killing the shell with SIGHUP. Now, your shell may ignore SIGHUP, since it is waiting for mutt to finish. Or it may die. If it died and sent mutt the SIGHUP, too, that would be great, however, some shells don't send SIGHUP on exit by default, and some users don't want that. However, I don't understand why mutt doesn't just die of end of file. I mean, its in- and output are the pseudo terminal slave, right? st is the only process having the corresponding master open, and when it exits, it closes that master implicitly. Shouldn't the PTY react just like a pipe in that case? Read on broken pipe means EOF, immediately. But maybe mutt isn't written to take EOF into account when reading. In short: st doesn't care for its PPID. And neither should it. Or maybe I misunderstood you, and you mean you have a double forking shell command (i.e. st forks a shell command, which in turn forks and then exits). That would cause st to exit as soon as the shell command does (single-forked shell exits - SIGCHLD to st - waitpid() - exit()). Or you have a needlessly convoluted shell which double forks and keeps the single-forked process running, waiting for the parent process. Maybe even catching or ignoring SIGHUP in the process. But that would just be broken on purpose. Ciao, Markus
Re: [dev][ubase] Implement switch_root
On Sun, Apr 13, 2014 at 02:10:51PM +0200, FRIGN wrote:
Good day,
sometimes, you depend on an initramfs to do stuff for you before
the rootfs is available.
Busybox has become the standard for all your initramfs needs, but
tbh, I hate working with it.
Statically linking sbase and ubase and choosing the tools you need for
the job almost solves the problem, but the lack of switch_root, which
almost every initramfs depends on, forces you to use busybox (because
util-linux doesn't link statically).
Now, I would've already sent in a patch, but I am pretty sure somebody
here already hacked it together before. So, to save my time, I better
ask now.
Cheers
FRIGN
--
FRIGN d...@frign.de
Why switch_root and not pivot_root? Here's a sh mockup of how to do what
you wrote with pivot_root:
set -e
new_root=$1
put_old=$2
[ -d $put_old ] || made_dir=1
mkdir -p $put_old
cd $new_root
pivot_root $new_root $put_old
chroot $new_root
umount ${put_old#$new_root}
[ $made_dir ] rm -rf ${put_old#$new_root}
It only depends on the new root being writable, and thus does not
require the initramfs to be a RAMFS or TMPFS (I remember being able to
boot from USB hard disk only by creating an initramfs, having that loaded
by the bootloader and launching linux with root=/dev/ram0, which made my
temporary root a SquashFS. In that case, switch_root will just refuse to
work)
Re: [dev][ubase] Implement switch_root
On Tue, Apr 15, 2014 at 06:44:54PM +0200, Markus Wichmann wrote:
On Sun, Apr 13, 2014 at 02:10:51PM +0200, FRIGN wrote:
Good day,
sometimes, you depend on an initramfs to do stuff for you before
the rootfs is available.
Busybox has become the standard for all your initramfs needs, but
tbh, I hate working with it.
Statically linking sbase and ubase and choosing the tools you need for
the job almost solves the problem, but the lack of switch_root, which
almost every initramfs depends on, forces you to use busybox (because
util-linux doesn't link statically).
Now, I would've already sent in a patch, but I am pretty sure somebody
here already hacked it together before. So, to save my time, I better
ask now.
Cheers
FRIGN
--
FRIGN d...@frign.de
Why switch_root and not pivot_root? Here's a sh mockup of how to do what
you wrote with pivot_root:
set -e
new_root=$1
put_old=$2
[ -d $put_old ] || made_dir=1
mkdir -p $put_old
cd $new_root
pivot_root $new_root $put_old
chroot $new_root
umount ${put_old#$new_root}
[ $made_dir ] rm -rf ${put_old#$new_root}
Because if it is a shell script then it cannot be included in ubase-box
which means that it needs to be maintained separately. Also the existing
build system for ubase/sbase doesn't cope with shell scripts (can be fixed
but not until we have a very good reason).
Cheers,
sin
Re: [dev][ubase] Implement switch_root
On Tue, Apr 15, 2014 at 05:57:25PM +0100, Dimitris Papastamos wrote:
On Tue, Apr 15, 2014 at 06:44:54PM +0200, Markus Wichmann wrote:
On Sun, Apr 13, 2014 at 02:10:51PM +0200, FRIGN wrote:
Good day,
sometimes, you depend on an initramfs to do stuff for you before
the rootfs is available.
Busybox has become the standard for all your initramfs needs, but
tbh, I hate working with it.
Statically linking sbase and ubase and choosing the tools you need for
the job almost solves the problem, but the lack of switch_root, which
almost every initramfs depends on, forces you to use busybox (because
util-linux doesn't link statically).
Now, I would've already sent in a patch, but I am pretty sure somebody
here already hacked it together before. So, to save my time, I better
ask now.
Cheers
FRIGN
--
FRIGN d...@frign.de
Why switch_root and not pivot_root? Here's a sh mockup of how to do what
you wrote with pivot_root:
set -e
new_root=$1
put_old=$2
[ -d $put_old ] || made_dir=1
mkdir -p $put_old
cd $new_root
pivot_root $new_root $put_old
chroot $new_root
umount ${put_old#$new_root}
[ $made_dir ] rm -rf ${put_old#$new_root}
Because if it is a shell script then it cannot be included in ubase-box
which means that it needs to be maintained separately. Also the existing
build system for ubase/sbase doesn't cope with shell scripts (can be fixed
but not until we have a very good reason).
Scratch that, it cannot be fixed. Real programmers write in C.
Re: [dev] OpenBSD takes a stab at SSL
On 15/04/2014, Jakub Lach jakub_l...@mailplus.pl wrote: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/ Win. OpenBSD tolerates little bullshit. On this note, de Raadt's [uncommonly restrained ☺] comment on OpenSSL: http://article.gmane.org/gmane.os.openbsd.misc/211963
Re: [dev] [PATCH] Don't make bold text bright with default color
REVC == Roberto E Vargas Caballero k...@shike2.com writes: Bold colors are brightened to stand out even more. But with the light background and dark foreground brightening acts contrary making the letters less emphasized. REVC It is not the first time this question is discussed in the REVC list, and your patch is the second about this issue. I was not aware that it's a sore subject here ;-) Thank you for pointing, I found several topics only when searched site:suckless.org bold st. But they there solving different problem (they were deciding is brightening needed with bold or not). I'm not objecting against brightening, it's a standard behavior. The only exception to brightening, which is standard to other virtual terminals, that if no color was specified with ANSI sequence no brightening should be applied. Don't jeer, believe you understood that I mean de-facto standards (xterm, rxvt, gnome terminals based on libvte, etc.). Every terminal which I tried behaves consistently (doesn't brighten implicit default REVC Suckless software is not a place where the sentence do it in REVC this way because another do it has meaning. I understand REVC your point of view, but I don't like the idea of having REVC different behaviour based in if the background color is the REVC default or not (what happen if you have the same problem with REVC your default background?), but I think maybe a patch with a REVC new option to st could be good. What opinion do you have REVC guys? It's not a question of internal design but question of interoperability. Since such behavior is standard between virtual terminals many software is relying on it. It was an argument in past: http://lists.suckless.org/dev/1210/12743.html So I can give you an example with plain 'top', you can compare: xterm -fg black -bg \#c0c0c0 -e top and how it looks on st (with the same fg/bg colors!): st -e top I agree that this behavior is odd, but since it's the expected behavior by most programs probably it should be adopted. PS. On my opinion, for the terminals with light background and dark text it would be great if bold text was darkened instead of brightening (e.g. in emacs many packages are configuring foreground faces depending on background light/dark). But many application tuned for standard behavior would look differently. -- Quidquid discis, tibi discis
Re: [dev] [PATCH] Don't make bold text bright with default color
F == FRIGN d...@frign.de writes: F No, seriously. If you bring up a point, and we discuss it, we F prefer discussions which cut the bullshit and get to the point F of the problem - or - non-problem. Don't confuse this with being F habitutional, it's just that we have agreed on ways to develop F software and it's important to discuss patches like this if they F fit to the suckless concept or not. Since you already wrote a F patch, I suppose you have strong reasons to support this change F and I'm really interested to find out in which case this might F be useful. Thank you for the warm words. After second look I don't feel that this list is unfriendly, even quite the opposite :-) I will describe cases why I need it: 1. I had bold shell prompt, which was black in all virtual terminals I have used so far. When I run st first time the first thing that caught my eye was the _gray_ prompt. It was looking awfully on gray background. Now I have changed prompt to use color, but first impression was spoiled. 2. When you run 'top' in st with black fg and #c0c0c0 fg in st you will see that it doesn't look as good as in other terminals with the same fg/bg 3. VIM status line (which displays mode like ---INSERT--) is displaying the messages in gray instead of black. 4. man output is using bold faces extensively, and in st I see all headers as gray (by the way I just noticed that st is also brightening underline text, while other terminals don't) 5. I think that's enough (I think I can find more examples of inconsistent behavior if provided examples are not convincing) F Imho, checking if the default color has been altered just F invites nasty edge-cases and generally bloats the code up F unnecessarily. However, I'm open for new ideas. I love symmetry in code too, and it's disappointing when new circumstance does not fit into an elegant model. But if such behavior is expected by programs, probably it worth to be implemented. My solution is not only possible, I believe there are other ways to do it. What if to allocate foreground color outside of first 256 entries, then color cannot be set with an ANSI sequence, and we can check if default color was altered just by comparing fg to defaultfg. Also fgcustcolor won't be needed (and errors when we forget to set/reset it are won't be possible). Let's just decide, don't you (community) like the whole idea or just current implementation (patch). If it's just the implementation, I think I can develop my idea from the past paragraph to new patch. -- A mari usque ad mare
Re: [dev] [st] Understading st behaviour
On Tue, Apr 15, 2014 at 5:36 PM, Amadeus Folego amadeusfol...@gmail.com wrote: It looks like I am spawning st with tmux (e.g. st -e tmux), and the issue is that tmux is reparenting the process id to tmux's daemon. Example: tmux | \_newsbeuter | \_vim st.c It is not an issue with xmonad after all, and I can confirm that the issue happens on urxvt as well (e.g. urxvt -e tmux). That’s this issue?: 1. If you open a program like mutt, ssh, or newsbeuter and kill the window with the wm (like xmonad) the process will not be killed. I am pretty sure that’s wholly by design as far as tmux goes. Just don’t try to exit your tmux session through the WM.
Re: [dev] [st] Understading st behaviour
Yeah, I think you're right, that's why I said I'll have to find another way to have scrolling. But at least we should warn on the section we recommend tmux as a viable multiplexer about this, what do you think? On Tue, Apr 15, 2014 at 05:53:13PM -0700, Ryan O’Hara wrote: On Tue, Apr 15, 2014 at 5:36 PM, Amadeus Folego amadeusfol...@gmail.com wrote: It looks like I am spawning st with tmux (e.g. st -e tmux), and the issue is that tmux is reparenting the process id to tmux's daemon. Example: tmux | \_newsbeuter | \_vim st.c It is not an issue with xmonad after all, and I can confirm that the issue happens on urxvt as well (e.g. urxvt -e tmux). That’s this issue?: 1. If you open a program like mutt, ssh, or newsbeuter and kill the window with the wm (like xmonad) the process will not be killed. I am pretty sure that’s wholly by design as far as tmux goes. Just don’t try to exit your tmux session through the WM.
Re: [dev] [st] Understading st behaviour
Greetings. On Wed, 16 Apr 2014 06:36:15 +0200 Amadeus Folego amadeusfol...@gmail.com wrote: Hi Guys, thank you for your feedback and taking your time to help me! I identified the issue. It looks like I am spawning st with tmux (e.g. st -e tmux), and the issue is that tmux is reparenting the process id to tmux's daemon. Example: tmux | \_newsbeuter | \_vim st.c It is not an issue with xmonad after all, and I can confirm that the issue happens on urxvt as well (e.g. urxvt -e tmux). I did not find any tmux option to disable this reparenting behaviour, so I guess I'll have to find another way to scroll the screen with st. :( Add set -g destroy-unattached on to your ~/.tmux.conf. Of course this will destroy every session you open and needs to be explictly disabled. Sincerely, Christoph Lohmann
Re: [dev] [PATCH] Don't make bold text bright with default color
Greetings. On Wed, 16 Apr 2014 06:37:45 +0200 Yuri Karaban suckl...@dev97.com wrote: I will describe cases why I need it: 1. I had bold shell prompt, which was black in all virtual terminals I have used so far. When I run st first time the first thing that caught my eye was the _gray_ prompt. It was looking awfully on gray background. Now I have changed prompt to use color, but first impression was spoiled. 2. When you run 'top' in st with black fg and #c0c0c0 fg in st you will see that it doesn't look as good as in other terminals with the same fg/bg 3. VIM status line (which displays mode like ---INSERT--) is displaying the messages in gray instead of black. 4. man output is using bold faces extensively, and in st I see all headers as gray (by the way I just noticed that st is also brightening underline text, while other terminals don't) If you request the brightening of underline, you will get brightened un‐ derline. 5. I think that's enough (I think I can find more examples of inconsistent behavior if provided examples are not convincing) F Imho, checking if the default color has been altered just F invites nasty edge-cases and generally bloats the code up F unnecessarily. However, I'm open for new ideas. I love symmetry in code too, and it's disappointing when new circumstance does not fit into an elegant model. But if such behavior is expected by programs, probably it worth to be implemented. My first thought after reading all of your posts was: Fix those damn programs, they are doing it all wrong for years. Your idea of moving fg and bg out of the color array is interesting and might add the semantics of a relative »background« or »foreground« color to a dynamic selected custom color. Sincerely, Christoph Lohmann
