Re: [dev] [st] xft: line drawing

2012-09-26 Thread Christoph Lohmann
Greetings comrades.

You guys forced me to do it. Attached is a preliminary patch to add line
drawing, which is using UTF-8 characters, to the latest tip of st.

There are bugs:
* the implementation is a pure hack (It is a proof of concept. Some
people really seem to need those line drawing characters, so they have
to fix it.)
* alsamixer has problems drawing the different characters inline (I
don't have the time to fix it now.)
* copy and paste does not really work, because this hack does not
affect it (I don't want to fix it, but if someone sends the patch it
will be fixed.)

Please don't report back »works« or »does not work«. This crap is only
implemented because you people are unable to fix any applications or are
too lazy to do so. This is suckless, where you are supposed to go deeper
and fix bugs.

Sincerely,

Christoph Lohmann
diff -r 36f8cd105d65 st.c
--- a/st.c	Tue Sep 25 21:39:25 2012 +0200
+++ b/st.c	Wed Sep 26 08:41:32 2012 +0200
@@ -1177,7 +1177,7 @@
 		switch(attr[i]) {
 		case 0:
 			term.c.attr.mode = ~(ATTR_REVERSE | ATTR_UNDERLINE | ATTR_BOLD \
-	| ATTR_ITALIC | ATTR_BLINK | ATTR_GFX);
+	| ATTR_ITALIC | ATTR_BLINK);
 			term.c.attr.fg = DefaultFG;
 			term.c.attr.bg = DefaultBG;
 			break;
@@ -1676,12 +1676,18 @@
 strhandle();
 		} else if(term.esc  ESC_ALTCHARSET) {
 			switch(ascii) {
-			case '0': /* Line drawing crap */
+			case '0': /* Line drawing set */
 term.c.attr.mode |= ATTR_GFX;
 break;
-			case 'B': /* Back to regular text */
+			case 'B': /* USASCII */
 term.c.attr.mode = ~ATTR_GFX;
 break;
+			case 'A': /* UK (IGNORED) */
+			case '': /* multinational charset (IGNORED) */
+			case '5': /* Finnish (IGNORED) */
+			case 'C': /* Finnish (IGNORED) */
+			case 'K': /* German (IGNORED) */
+break;
 			default:
 fprintf(stderr, esc unhandled charset: ESC ( %c\n, ascii);
 			}
@@ -1700,10 +1706,13 @@
 strescseq.type = ascii;
 term.esc |= ESC_STR;
 break;
-			case ')':
-			case '(':
+			case '(': /* set primary charset G0 */
 term.esc |= ESC_ALTCHARSET;
 break;
+			case ')': /* set secondary charset G1 (IGNORED) */
+			case '*': /* set tertiary charset G2 (IGNORED) */
+			case '+': /* set quaternary charset G3 (IGNORED) */
+break;
 			case 'D': /* IND -- Linefeed */
 if(term.c.y == term.bot)
 	tscrollup(term.top, 1);
@@ -2068,6 +2077,8 @@
 	Font *font = dc.font;
 	XGlyphInfo extents;
 	int i;
+	char *as, *asp;
+	int al;
 
 	/* only switch default fg/bg if term is in RV mode */
 	if(IS_SET(MODE_REVERSE)) {
@@ -2093,14 +2104,60 @@
 	XSetBackground(xw.dpy, dc.gc, dc.col[bg]);
 	XSetForeground(xw.dpy, dc.gc, dc.col[fg]);
 
+	/*
+	 * Most of the code proudly stolen from the rxvt codebase.
+	 */
+	as = NULL;
 	if(base.mode  ATTR_GFX) {
-		for(i = 0; i  bytelen; i++) {
-			char c = gfx[(uint)s[i] % 256];
-			if(c)
-s[i] = c;
-			else if(s[i]  0x5f)
-s[i] -= 0x5f;
+		fprintf(stderr, ATTR_GFX: '%.*s'\n, bytelen, s);
+		al = strlen(s) * 4;
+		asp = as = xmalloc(al+1);
+		memset(as, 0, al+1);
+
+		char *vt100_0[62] = { /* 0x41 - 0x7e */
+			↑, ↓, →, ←, █, ▚, ☃, /* A - G */
+			0, 0, 0, 0, 0, 0, 0, 0, /* H - O */
+			0, 0, 0, 0, 0, 0, 0, 0, /* P - W */
+			0, 0, 0, 0, 0, 0, 0,  , /* X - _ */
+			◆, ▒, ␉, ␌, ␍, ␊, °, ±, /* ` - g */
+			␤, ␋, ┘, ┐, ┌, └, ┼, ⎺, /* h - o */
+			⎻, ─, ⎼, ⎽, ├, ┤, ┴, ┬, /* p - w */
+			│, ≤, ≥, π, ≠, £, ·, /* x - ~ */
+		};
+
+		char *c;
+		int cl = 0, sb = bytelen;
+
+		charlen = 0;
+		bytelen = 0;
+		for(i = 0; i  sb; i++) {
+			if((uint)s[i]  0x41 || (uint)s[i]  0x7e
+	|| !vt100_0[(uint)s[i] - 0x41]) {
+as = strncat(as, s[1], 1);
+asp++;
+charlen++;
+bytelen++;
+continue;
+			}
+
+			c = vt100_0[(uint)s[i] - 0x41];
+			cl = strlen(c);
+
+			fprintf(stderr, '%c' - '%s'\n, s[i], c);
+
+			if(asp + cl  as + al - 1)
+break;
+
+			asp = strcat(asp, c);
+			asp += cl;
+			bytelen += cl;
+			charlen++;
 		}
+		fprintf(stderr, as (%d) (%d) = '%s'\n, charlen, bytelen, as);
+	}
+	if(as != NULL) {
+		s = as;
+		width = charlen * xw.cw;
 	}
 
 	XftTextExtentsUtf8(xw.dpy, font-xft_set, (FcChar8 *)s, bytelen, extents);
@@ -2110,6 +2167,9 @@
 
 	if(base.mode  ATTR_UNDERLINE)
 		XDrawLine(xw.dpy, xw.buf, dc.gc, winx, winy+1, winx+width-1, winy+1);
+
+	if(as != NULL)
+		free(as);
 }
 
 void


Re: [dev] [st] xft: line drawing

2012-09-26 Thread Brandon Invergo
 For those alternative charsets remapping some ranges of the symbols is
 required, which could be easily done using UTF=E2=80=908 characters.

But how exactly should this work? I tried naively just filling gfx[]
with the appropriate mappings (i.e. ['x'] =3D '|' (pretend that's the
unicode vertical line)), but of course that won't work since gfx is a
char[]. I got a bunch of wchar warnings and it, not surprisingly, didn't
work.=20



I'll give it another try today. 



Re: [dev] [st] xft: line drawing

2012-09-26 Thread Roberto E. Vargas Caballero
On Wed, Sep 26, 2012 at 08:49:43AM +0200, Christoph Lohmann wrote:
 Greetings comrades.

 You guys forced me to do it. Attached is a preliminary patch to add line
 drawing, which is using UTF-8 characters, to the latest tip of st.

Testing your patch, I saw that mutt doesn't use never \033 ( 0. I think it
see that locale is utf8 capable and directly writes utf8 codes, so my
problems are not related to the patch you sent. Surely they are part of the
incomplete font. Since I am using the default font, maybe we should change
the default font to other with better drawing support, as for example
Liberation Mono.


Sincerely.



Re: [dev] [st] xft: line drawing

2012-09-26 Thread Christoph Lohmann
Greetings comrades.

In  tip  is  now a better implementation of this alternative charset. It
does the linedrawing in alsamixer correctly, when using  the  Liberation
Mono font, which is just because of this reason now the default font for
st. When the font symbol selection is fixed this may change.


Sincerely,

Christoph Lohmann




Re: [dev] [st] xft: line drawing

2012-09-25 Thread Roberto E. Vargas Caballero
 Line drawing seems to be broke using the latest tip of st. I've tried it

I also have problems with them. Using the default font I have some problems
with line drawings and attributes (for example http://www.shike2.com/st.png).

Is it the problem you have?.


Best regards,



Re: [dev] [st] xft: line drawing

2012-09-25 Thread Kurt H Maier
On Tue, Sep 25, 2012 at 05:47:07PM +0200, Brandon Invergo wrote:
 
 Anyone else have this problem or is it just me?
 

we have to find out if it's working on christophms mac or it won't get
fixed



Re: [dev] [st] xft: line drawing

2012-09-25 Thread Martti Kühne
On Tue, Sep 25, 2012 at 9:24 PM, Kurt H Maier khm-suckl...@intma.in wrote:
 On Tue, Sep 25, 2012 at 05:47:07PM +0200, Brandon Invergo wrote:

 Anyone else have this problem or is it just me?



works here. but long shot what I did to make it work.
maybe I'm just using tmux which handles line drawing just fine?
maybe I just commented out the gfx[] matching in st source?
- although, checking the source, the line char c = gfx[blah...] is
there, and it should match quite a bunch of chars.
maybe it's because with xft support, the transition between line
drawing and the corresponding wtf8 glyph just works...

sorry for not being very precise here, 0xe29480 (horizontal line)
displays fine otherwise in st without tmux... and I'm using an
extremely incomplete xft font, envy-code-r.

cheers!
mar77i



Re: [dev] [st] xft: line drawing

2012-09-25 Thread Thuban
I noticed this problem too. Lines are replaced by some strange small
squares.

Le 17:47:07 le 25 sept. 2012 , Brandon Invergo a écrit :
 Line drawing seems to be broke using the latest tip of st. I've tried it
 with the default config.def.h as well as using some other fonts but with
 no luck. I tried changing the gfx[] array contents in config.def.h except
 its use is rather opaque and I couldn't get anything to work.
 
 Anyone else have this problem or is it just me?
 
 -brandon
 
 

-- 
 ,--.   Xavier Cartron   ,   /(
: /` )  M2 MEFPCo **}=\\,\(,,  
| `-'   Debian user0--(___(_\\
 \_ jabber : thu...@jabber.fr  / ,)   ,/ ``==



Re: [dev] [st] xft: line drawing

2012-09-25 Thread Christoph Lohmann
Greetings comrades.

On Wed, 26 Sep 2012 07:18:49 +0200 Thuban thu...@singularity.fr wrote:
 I noticed this problem too. Lines are replaced by some strange small
 squares.

A  »strange  small  square« means in xft that your font is missing some‐
thing. The line drawing issue is a bit more complex.  The  gfx  code  is
from corefonts and not supposed to work with xft.

For  those  alternative charsets remapping some ranges of the symbols is
required, which could be easily done using UTF‐8 characters.

This alternative charset mode is really obscure.


Sincerely,

Christoph Lohmann