Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same
in config.h something along the lines of
enum color_mode {
REVERSE,
COLOR,
};
struct selection_colors {
enum color_mode;
int colors[];
}
static const struct selection_colors same = { .color_mode = COLOR,
.colors = { 7, 0 } };
static const struct selection_colors different = { .color_mode = REVERSE };
Sorry for the previous email. My email client went crazy on me.
cheers!
mar77i
Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same
in config.h something along the lines of
enum {
} color_mode;
struct {
}
static const int select_same[2] = { 7, 0 };
static const int select_different[2] = { REVERSE, REVERSE };
or any pair of ints
Re: [dev] [dvtm] Truecolor support
Hi, >> >> There is no support for true color in terminfo, so curses cannot >> handle it. > > Is this a fundamental limitation or just a lack of standardization? > > https://lists.gnu.org/archive/html/bug-ncurses/2013-10/msg7.html Mainly lack of standardization (this feature was added to terminals in the last 2/3 years), but as you can read in the thread you posted (I didn't know it), there are also other problems, because terminfo definitions uses 16 bit integers. > Also what does the init_color function actually do then? Does it > fall back to a color which best approximates the one given? >From terminfo(5): On a Tektronix-like terminal, the capability ccc may be present to indicate that colors can be modified. If so, the initc capability will take a color number (0 to colors - 1)and three more parameters which describe the color. These three parameters default to being interpreted as RGB (Red, Green, Blue) values. If the boolean capability hls is present, they are instead as HLS (Hue, Lightness, Saturation) indices. The ranges are terminal-dependent. It modifies the RGB definition of one of the colors of the terminals (usually only the first 16 colors, although it can be extended until the first 256). The point of true color is you can select any color, not only one of a pallete. >> If your application need it the only way is to print >> directly the sequences, and the only way to detect if the terminal >> has this capability is to check TERM against a list of terminals >> that suppor it. > > Well this sucks. How would you detect old version of these terminals > which do not yet have support built in? The whole point of > terminfo/curses is to abstract away these ugly details. Yes, the problem I can see here is who is going to define this new capability. This is the problem of moderm unixes. There is a similar problem with w3m-image, that has a hack that only works with xterm and fb because it detect them.
Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same
On Sun, Oct 26, 2014 at 11:01:24PM -0300, dequis wrote:
> This patch allows that text to be read by selecting it, turning it into
> text with white bg and black fg (given default values for defaultbg/fg),
> just like most normal unformatted text when selected.
> ---
> st.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/st.c b/st.c
> index 12af1ab..e2b7003 100644
> --- a/st.c
> +++ b/st.c
> @@ -3296,9 +3296,14 @@ xdraws(char *s, Glyph base, int x, int y, int charlen,
> int bytelen) {
> }
>
> if(base.mode & ATTR_REVERSE) {
> - temp = fg;
> - fg = bg;
> - bg = temp;
> + if (bg == fg) {
> + bg = &dc.col[defaultfg];
> + fg = &dc.col[defaultbg];
> + } else {
> + temp = fg;
> + fg = bg;
> + bg = temp;
> + }
> }
>
> if(base.mode & ATTR_FAINT && !(base.mode & ATTR_BOLD)) {
> --
> 2.1.2
>
I like the idea, but not the implementation. This patch changes the definition
of ATTR_REVERSE, which isn't good. The alternative would be to define a
separate color scheme for selection. I'm not sure how much complexity that
would add to the code, but in my opinion almost any complexity dedicated to
handling an unusual case like this is too much. Perhaps this patch could live
on the wiki instead of being integrated into the st proper.
Re: [dev] [dvtm] Truecolor support
> A simpler possibility is to let it enabled by default and let the user > switch it off with a command line argument (like it's done for the mouse > grabbing). I think it would make sense as all major terminal emulators > support true color. We have something similar for alternate screen to, but I am not sure if it is a good idea to add a command line option to disable each aditional feature that we have. If the sequence is not part of the terminfo definition then any program should used it, so I don't know what is the advantage of disabling it. Regards,
Re: [dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for
FRIGN said: > >> DESCRIPTION > >> The wcwidth() function returns the number of columns needed to > >> represent the wide character c. If c is a printable wide > >> character, the value is at least 0. If c > >> is null wide character (L'\0'), the value is 0. Otherwise -1 is > >> returned. > > That's how POSIX-2001 defines it. > > So yeah, using abs() to "catch" the invalid case is fine, but could be > refined even more. I don't follow your logic here. Glibc currently yelds incorrect result for a set of valid Unicode 7.0 codepoints that were invalid previously. This time they are 1 column width (I didn't verify that, so don't take my word for it), but in future wide characters may be added as well, and wcwidth() will return -1 for them as well, so the "abs()" hack won't work. IMO ideally st should either not print characters whose codepoints are unknown to libc, or should silently replace them with U+FFFD. At any rate, assumptions about codepoints' properties are not st's business. -- Dmitrij D. Czarkoff
Re: [dev] [dvtm] Truecolor support
On Mon, Oct 27, 2014 at 02:11:49PM +0100, k...@shike2.com wrote: > Hi, > > > Apparently curses provides: > > > > int init_color(short color, short r, short g, short b); > > > > not quite sure what it does internally. > > There is no support for true color in terminfo, so curses cannot > handle it. Is this a fundamental limitation or just a lack of standardization? https://lists.gnu.org/archive/html/bug-ncurses/2013-10/msg7.html Also what does the init_color function actually do then? Does it fall back to a color which best approximates the one given? > If your application need it the only way is to print > directly the sequences, and the only way to detect if the terminal > has this capability is to check TERM against a list of terminals > that suppor it. Well this sucks. How would you detect old version of these terminals which do not yet have support built in? The whole point of terminfo/curses is to abstract away these ugly details. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same
On 27 October 2014 11:54, Martti Kühne wrote: > On Mon, Oct 27, 2014 at 3:01 AM, dequis wrote: >> The background/foreground of selected text is currently set by setting >> ATTR_REVERSE, which flips its normal bg/fg. When the text being >> selected has the same bg and fg, it won't be readable after selecting >> it, either. >> > > > This may sound trivial, but. > How about you paste it somewhere else? I've done that - annoying to do constantly, but it's an okayish workaround. I've also done that by using the same input box of the irc client (which is the one that happens to be the most convenient one), which is even more annoying since you have to stop the selection within the range of the 10 pixels of width of the last character of the line, if done carelessly the newline gets selected which results in the copied line getting sent to irc. Of course I've already learnt (through many mistakes) not to do that. Call me nitpicky, I've just done it hundreds (if not thousands) of times and the annoyance stacks up. But I already have a perfectly good and trivial patch that fixes the issue, so why would I bother with a workaround like that?
Re: [dev] [dvtm] Truecolor support
On 2014-10-27 21:11, k...@shike2.com wrote:
Hi,
Apparently curses provides:
int init_color(short color, short r, short g, short b);
not quite sure what it does internally.
There is no support for true color in terminfo, so curses cannot
handle it. If your application need it the only way is to print
directly the sequences, and the only way to detect if the terminal
has this capability is to check TERM against a list of terminals
that suppor it.
The SGR parameter that selects the foreground color has code 38. Its
arguments are 5;x where x is color index (0..255) or 2;r;g;b where r,g,b
are red, green and blue color channels (out of 255). Taking a look at
vt.c:444 of the latest git head we find:
case 38:
if ((i + 2) < pcount && param[i + 1] == 5) {
b->curfg = param[i + 2];
i += 2;
}
break;
so, if the SGR code is 38 and its first argument is 5 the foreground
color is set. What we need here is a second check where if the first
parameter is 2 the control sequence is sent directly to the terminal.
I'm not sure about the best way to do this, as I don't think that we can
use put_wc(). Before going any further I'd like to hear Marc's opinion
about the issue.
An analogous change is needed for the background color (SGR code 45).
Paride
Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same
On Mon, Oct 27, 2014, at 10:54, Martti Kühne wrote: > This may sound trivial, but. > How about you paste it somewhere else? Requires having another window already open that can accept arbitrary text (and not attempt to execute it as commands).
Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same
On Mon, Oct 27, 2014 at 3:01 AM, dequis wrote: > The background/foreground of selected text is currently set by setting > ATTR_REVERSE, which flips its normal bg/fg. When the text being > selected has the same bg and fg, it won't be readable after selecting > it, either. > This may sound trivial, but. How about you paste it somewhere else? cheers! mar77i
Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same
On Mon, Oct 27, 2014, at 08:20, FRIGN wrote: > There's simply no reason to break consistency for some quirky irc-gag. But there's no compelling reason in the first place to visualize selection by inverting the colors. If you want "consistency" it can be achieved by having an actual selection color pair, or by _always_ using the default colors, but that's bikeshed painting. The reason why someone might have same-fg-as-bg on their screen is beside the point - having no way to make that text visible is a usability issue.
Re: [dev] [dvtm] Truecolor support
On 2014-10-27 21:11, k...@shike2.com wrote: Hi, Apparently curses provides: int init_color(short color, short r, short g, short b); not quite sure what it does internally. There is no support for true color in terminfo, so curses cannot handle it. If your application need it the only way is to print directly the sequences, and the only way to detect if the terminal has this capability is to check TERM against a list of terminals that suppor it. A simpler possibility is to let it enabled by default and let the user switch it off with a command line argument (like it's done for the mouse grabbing). I think it would make sense as all major terminal emulators support true color. Paride
Re: [dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for
> That's how POSIX-2001 defines it. > > So yeah, using abs() to "catch" the invalid case is fine, but could be > refined even more. > Ok, it is true. We should catch this case, but I don't like the idea of the abs. I think the correct solution should be print the invalid character. Regards,
Re: [dev] [dvtm] Truecolor support
Hi, > Apparently curses provides: > > int init_color(short color, short r, short g, short b); > > not quite sure what it does internally. There is no support for true color in terminfo, so curses cannot handle it. If your application need it the only way is to print directly the sequences, and the only way to detect if the terminal has this capability is to check TERM against a list of terminals that suppor it. > However the problem is that there can only be COLOR_PAIRS number of > different color pairs in use at any given time. Changing the content > of a pair affects all cells where it is in use. Therefore dvtm currently > maintains a 1 to 1 mapping from foreground + background color to the > associated pair. This works fine if the number of colors is 256 but > not if its 2^24. A more sophisticated mapping would be needed. St maintains a vector with the RGB components of the 256 first colors, and it extracts from them the RGB components when such colors are used, so the Term data structure only handles RGB components. If a true color is used then it only pass the RGB component to Term. If the user change the components of one of the 256 colors then st doesn't update the cells with this color and the previous color definition. As far as I know, it is the correct behaviour. Regards,
Re: [dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for
On Mon, 27 Oct 2014 13:03:49 +0100 Marc André Tanner wrote: > POSIX states for int wcwidth(wchar_t wc): "... or return -1 (if wc > does not correspond to a printable wide-character code)." Therefore > I think a return value of -1 should be handled gracefully. I have to agree here, even though I do not favor changing the code for broken libraries, I have to quote wcwidth(3): >> DESCRIPTION >> The wcwidth() function returns the number of columns needed to >> represent the wide character c. If c is a printable wide >> character, the value is at least 0. If c >> is null wide character (L'\0'), the value is 0. Otherwise -1 is >> returned. That's how POSIX-2001 defines it. So yeah, using abs() to "catch" the invalid case is fine, but could be refined even more. Cheers FRIGN -- FRIGN
Re: [dev] [dvtm] Truecolor support
On Mon, Oct 27, 2014 at 03:26:44AM +0800, Paride Legovini wrote: > Hi, > > I see that st nicely support "truecolor" sequences, as it can be > easily tested with this command: > > printf "\x1b[38;2;255;100;0mTRUECOLOR\x1b[0m\n" > > that has to be given outside any terminal multiplexer. The point is > that currently no terminal multiplexer (tmux, dvtm, screen) supports > this kind of color sequences. I'd be interested to see this feature > added to dvtm, but I'm not sure if it is possible as it may be a > limitation of libncurses. Apparently curses provides: int init_color(short color, short r, short g, short b); not quite sure what it does internally. However the problem is that there can only be COLOR_PAIRS number of different color pairs in use at any given time. Changing the content of a pair affects all cells where it is in use. Therefore dvtm currently maintains a 1 to 1 mapping from foreground + background color to the associated pair. This works fine if the number of colors is 256 but not if its 2^24. A more sophisticated mapping would be needed. I'm currently in the process of cleaning up some dvtm internals. It would thus be a good time to send patches. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same
On Sun, 26 Oct 2014 23:01:24 -0300 dequis wrote: > The background/foreground of selected text is currently set by setting > ATTR_REVERSE, which flips its normal bg/fg. When the text being > selected has the same bg and fg, it won't be readable after selecting > it, either. > > This may sound silly - my main use case is IRC channels using color > codes for black-on-black to mark 'spoilers'. > > This patch allows that text to be read by selecting it, turning it > into text with white bg and black fg (given default values for > defaultbg/fg), just like most normal unformatted text when selected. I disagree with the proposal. There's simply no reason to break consistency for some quirky irc-gag. If you want to read the spoilers, select them and paste them somewhere else. Done. Cheers FRIGN -- FRIGN
Re: [dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for
On Mon, Oct 27, 2014 at 08:21:52AM +0100, k...@shike2.com wrote: > > On 26 October 2014 19:36, Dmitrij D. Czarkoff wrote: > >> Apparently no workaround is needed - just use sane libc or avoid using > >> new codepoints until glibc fixes that. Or, if you won't feel dirty > >> after that, send a patch to glibc instead. > > > > 'Just using musl' doesn't seem feasible given a glibc-based system - > > it's easier for smaller programs, but in the case of st i'd have to > > rebuild xlib, xcb, xft, freetype, fontconfig, etc (and their > > dependencies) against musl. Not to mention that musl doesn't implement > > unicode 7.0 either, only up to 6.2. > > I tend to think that it is better fix the wrong software than add > workarounds in the correct software. I don't have problems now, > and I think is the same for almost all the users of st. Maybe you > can add this patch to the wiki, because it is sure it will be useful > for more people. > > If you really want to fix the problem you should send a patch > to the glibc mailing list. POSIX states for int wcwidth(wchar_t wc): "... or return -1 (if wc does not correspond to a printable wide-character code)." Therefore I think a return value of -1 should be handled gracefully. Having said that in dvtm it seems completely broken at the moment, no char shows up at all. Patches for that are certainly welcome ... -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
[dev] Re: surf rewrite for WebKit2GTK
I fixed a few bugs, tell me if it works for you. On Thu, Oct 23, 2014 at 1:54 PM, Quentin Rameau wrote: > Hi, I tried to port surf for the webkit2 (WebKitGTK 2.6 / GTK3), here > is the code: > git://quinq.eu.org/surf2 > There will be some bugs, feel free to try it, feedback welcomed.
Re: [dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for
> On 26 October 2014 19:36, Dmitrij D. Czarkoff wrote: >> Apparently no workaround is needed - just use sane libc or avoid using >> new codepoints until glibc fixes that. Or, if you won't feel dirty >> after that, send a patch to glibc instead. > > 'Just using musl' doesn't seem feasible given a glibc-based system - > it's easier for smaller programs, but in the case of st i'd have to > rebuild xlib, xcb, xft, freetype, fontconfig, etc (and their > dependencies) against musl. Not to mention that musl doesn't implement > unicode 7.0 either, only up to 6.2. I tend to think that it is better fix the wrong software than add workarounds in the correct software. I don't have problems now, and I think is the same for almost all the users of st. Maybe you can add this patch to the wiki, because it is sure it will be useful for more people. If you really want to fix the problem you should send a patch to the glibc mailing list. Regards,
