Re: [dev] [ST] [PATCH] Changed type for UTF-32 codepoints from long to uint_least32_t

2015-05-06 Thread Roberto E. Vargas Caballero

Applied, thanks!



Re: [dev] [vis][RFC][PATCH 1/2] Replace first '/' of substitute command with \0

2015-05-06 Thread Silvan Jegen
Heyho

On Wed, May 6, 2015 at 3:50 AM, Eric Pruitt eric.pru...@gmail.com wrote:
 On Tue, May 05, 2015 at 06:25:29PM +0200, Silvan Jegen wrote:
 Signed-off-by: Silvan Jegen s.je...@gmail.com

 What's the point in signing off on patches where you're the sole author?
 Seems like redundant clutter to me.

I do it to indicate that I agree with the licensing terms of the
existing code and to make explicit that I want to let you use this
code (that to my best knowledge is of my own devising, does not
infringe any patents yaddayaddayadda...). That is what the Linux
kernel people use this tag for[0].

It is probably not necessary (and ineffective without the Developer's
Certificate of Origin 1.1 included in the project) but I want to be
on the safe side.

If you prefer me not to do it, I won't in the future.


Cheers,

Silvan

[0] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=refs/tags/v4.1-rc2#n407



Re: [dev] Odds and ends (2/2): $XEMBED

2015-05-06 Thread Connor Lane Smith
On 4 May 2015 at 11:56, Roberto E. Vargas Caballero k...@shike2.com wrote:
 The idea is good, but it means that you have to modify all the programs
 to accept this new feature. If you want to experiment with this idea
 you can try to add this variable in st and read it in surf.

I've written a wrapper which makes a given program support this, and
it's pretty tiny, too. Attached. Sample usage:

 #!/bin/sh
 exec 9embed -e surf $@

I've not found time to add the functionality into a terminal like st
yet, but I was happy to discover that tabbed already sets XEMBED, and
the wrapper works as expected: 'surf ' will open surf in a new
window, whereas 'surf' will open it in a new tab.

Thanks,
cls
/* (c) Connor Lane Smith, 2015 */
#include fcntl.h
#include stdio.h
#include stdlib.h
#include unistd.h

int
main(int argc, char **argv)
{
	if(argc  3) {
		fprintf(stderr, usage: %s flag cmd ...\n, argv[0]);
		return 2;
	}

	char *xembed = getenv(XEMBED);

	if(!xembed)
		goto noembed;

	int tty = open(/dev/tty, O_RDONLY);

	if(tty  0)
		goto noembed;

	pid_t pgrp = getpgrp();
	pid_t tcpgrp = tcgetpgrp(tty);

	close(tty);

	if(pgrp == tcpgrp) { // in foreground of tty
		argv[0] = argv[2];
		argv[2] = xembed;
	}
	else {
noembed:
		argv += 2;
	}

	execvp(argv[0], argv);

	perror(argv[0]); // failed to execute
	return 1;
}


Re: [dev] Odds and ends (2/2): $XEMBED

2015-05-06 Thread Connor Lane Smith
On 6 May 2015 at 11:43, Connor Lane Smith c...@lubutu.com wrote:
 I've not found time to add the functionality into a terminal like st
 yet, but I was happy to discover that tabbed already sets XEMBED, and
 the wrapper works as expected: 'surf ' will open surf in a new
 window, whereas 'surf' will open it in a new tab.

In fact, leaving that for tabbed to do could well be enough. If you
run surf so it opens in a new tab then you can switch back to the
terminal if you wish, which couldn't be done in Plan 9, but seems
reasonably useful.

With that in mind, might 9embed (perhaps under another name) be
suitable to add to the tabbed distribution?

cls



[dev] [slock] [PATCH] Option to not show failure color on clear

2015-05-06 Thread Nick Currier
Hello,

This patch adds the failonclear boolean option so that, when false,
the failure color will not appear until a failed login attempt has
been made.
It also maintains the existing behaviour (failure on clear) by default.

Thanks,
hexid
From b5fa0f2cabf03ae3d09a29b8fb5327109ec2e0e0 Mon Sep 17 00:00:00 2001
From: hexid nick.curr...@gmail.com
Date: Fri, 17 Apr 2015 11:09:02 -0600
Subject: [PATCH] Add config option to only show error color if after a
 failed login attempt

---
 config.def.h |  3 ++-
 slock.c  | 20 +++-
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/config.def.h b/config.def.h
index 4bccb5d..3ae2e6e 100644
--- a/config.def.h
+++ b/config.def.h
@@ -1,5 +1,6 @@
 static const char *colorname[NUMCOLS] = {
 	black, /* after initialization */
 	#005577,   /* during input */
 	#CC,   /* failed/cleared the input */
 };
+static const Bool failonclear = True;
diff --git a/slock.c b/slock.c
index 6502c86..8a12cde 100644
--- a/slock.c
+++ b/slock.c
@@ -26,7 +26,7 @@
 enum {
 	INIT,
 	INPUT,
-	EMPTY,
+	FAILED,
 	NUMCOLS
 };
 
@@ -42,6 +42,7 @@ typedef struct {
 static Lock **locks;
 static int nscreens;
 static Bool running = True;
+static Bool failure = False;
 static Bool rr;
 static int rrevbase;
 static int rrerrbase;
@@ -153,8 +154,10 @@ readpw(Display *dpy, const char *pws)
 #else
 running = !!strcmp(crypt(passwd, pws), pws);
 #endif
-if (running)
+if (running) {
 	XBell(dpy, 100);
+	failure = True;
+}
 len = 0;
 break;
 			case XK_Escape:
@@ -177,9 +180,16 @@ readpw(Display *dpy, const char *pws)
 	XClearWindow(dpy, locks[screen]-win);
 }
 			} else if (llen != 0  len == 0) {
-for (screen = 0; screen  nscreens; screen++) {
-	XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[EMPTY]);
-	XClearWindow(dpy, locks[screen]-win);
+if (failure || failonclear) {
+	for (screen = 0; screen  nscreens; screen++) {
+		XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[FAILED]);
+		XClearWindow(dpy, locks[screen]-win);
+	}
+} else {
+	for (screen = 0; screen  nscreens; screen++) {
+		XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[INIT]);
+		XClearWindow(dpy, locks[screen]-win);
+	}
 }
 			}
 			llen = len;
-- 
2.3.5



Re: [dev] [vis][RFC][PATCH 1/2] Replace first '/' of substitute command with \0

2015-05-06 Thread Eric Pruitt
On Wed, May 06, 2015 at 10:10:21AM +0200, Silvan Jegen wrote:
 I do it to indicate that I agree with the licensing terms of the
 existing code and to make explicit that I want to let you use this
 code (that to my best knowledge is of my own devising, does not
 infringe any patents yaddayaddayadda...). That is what the Linux
 kernel people use this tag for[0].

How does that indicate you agree with the terms? If you aren't GPG
signing the commits, that message adds no additional insurance that you
are actually the author of the commit; anyone can add that line to the
patch if they so desire.

 If you prefer me not to do it, I won't in the future.

I don't even have commit privileges to any of the suckless repositories,
so it's not up to me.

Eric



Re: [dev] Odds and ends (2/2): $XEMBED

2015-05-06 Thread Jason Woofenden
 In fact, leaving that for tabbed to do could well be enough. If you
 run surf so it opens in a new tab then you can switch back to the
 terminal if you wish, which couldn't be done in Plan 9, but seems
 reasonably useful.

If you don't replace the terminal window, then you're just talking
about window management, which should perhaps be done with the
window manager. The XEMBED thing only works on a few clients. The
WM can meddle with just about all the clients.

tabbed is neato, and I'd probably use it, (at least for a while) if
I was happier with surf, but I can't help thinking that the cleaner
and more generally useful solution is to build whatever tabbing
features you want into the WM. That way you can have tabs with
whatever windows you want.


Another way you can get close to having the new graphical client
replace your terminal is to auto-close the terminal by binding a
key in your shell to run the program you typed in the background
and then close the terminal. I did this trick to create a
run-dialog with zsh. Here's the zsh keybind that does the important
magick:

bindkey -s ^M ^E /dev/null 21 ! ; exit\n

This would be a little cleaner if you set your WM to stack new
windows just after the focused one.

-- 
Jason



Re: [dev] [vis] [PATCH] Add '--' as end of options.

2015-05-06 Thread Matias Linares
I attached the patch with the corrections on vis.c and the new info on the
man page.

Sorry for the previous, bad tested, patch.

Greetings.

-- 
XMPP/Mail: matiasl...@openmailbox.org
GPG: http://www.famaf.unc.edu.ar/~mlm0111/pubkey.asc | BBD8 CADC C236 AD16
From 20b251fe256171252193caabab0dff4b100b15bc Mon Sep 17 00:00:00 2001
From: Matias Linares matiasl...@openmailbox.org
Date: Wed, 6 May 2015 20:23:50 -0300
Subject: [PATCH] Add '--' as end of options

Now it works properly, `vis -- -v` edit a file named `-v`. Also added the
proper info to the man page.
---
 vis.1 | 3 +++
 vis.c | 6 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/vis.1 b/vis.1
index 452e02f..63d0103 100644
--- a/vis.1
+++ b/vis.1
@@ -13,5 +13,8 @@ is a highly efficient vim like text editor.
 .SH OPTIONS
 .B \-v
 Print version information to standard output and exit.
+
+.B \-\-
+Denotes the end of the options. Arguments after this will be handled as a file name. This can be used to edit a filename that starts with a '-'.
 .SH AUTHOR
 vis is written by Marc André Tanner mat at brain-dump.org
diff --git a/vis.c b/vis.c
index 051f256..cd73d99 100644
--- a/vis.c
+++ b/vis.c
@@ -2026,9 +2026,13 @@ int main(int argc, char *argv[]) {
 		die(Could not load syntax highlighting definitions\n);
 
 	char *cmd = NULL;
+	bool end_of_options = false;
 	for (int i = 1; i  argc; i++) {
-		if (argv[i][0] == '-') {
+		if (argv[i][0] == '-'  !end_of_options) {
 			switch (argv[i][1]) {
+			case '-':
+end_of_options = true;
+break;
 			case 'v':
 die(vis %s, compiled  __DATE__   __TIME__ \n, VERSION);
 break;
-- 
2.3.7



pgp6aieJtC1B9.pgp
Description: PGP signature


Re: [dev] Odds and ends (2/2): $XEMBED

2015-05-06 Thread Connor Lane Smith
On 6 May 2015 at 11:59, Connor Lane Smith c...@lubutu.com wrote:
 With that in mind, might 9embed (perhaps under another name) be
 suitable to add to the tabbed distribution?

Having had Christoph's approval, I've attached a patch which adds the
utility (under the name of xembed) to tabbed.

Thanks,
cls


0001-add-xembed-wrapper-utility.patch
Description: Binary data


[dev] [dwm] [PATCH] support _NET_SUPPORTING_WM_CHECK

2015-05-06 Thread Jason Woofenden
As documented here: 
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317670464
---

I developed this in the hopes that it would fix issues with feh running
fullscreen. It didn't help with that (feh using the innacurate _MOTIF_WM_HINTS
method) but it should at least stop gtk+ 3.3.8+ from polling regularly for WM
features.

The change to gtk+ is discussed here: 
https://bugzilla.gnome.org/show_bug.cgi?id=666921


 dwm.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/dwm.c b/dwm.c
index 169adcb..1e53a68 100644
--- a/dwm.c
+++ b/dwm.c
@@ -62,7 +62,7 @@ enum { CurNormal, CurResize, CurMove, CurLast }; /* cursor */
 enum { SchemeNorm, SchemeSel, SchemeLast }; /* color schemes */
 enum { NetSupported, NetWMName, NetWMState,
NetWMFullscreen, NetActiveWindow, NetWMWindowType,
-   NetWMWindowTypeDialog, NetClientList, NetLast }; /* EWMH atoms */
+   NetWMWindowTypeDialog, NetClientList, NetSupportingWMCheck, NetLast }; 
/* EWMH atoms */
 enum { WMProtocols, WMDelete, WMState, WMTakeFocus, WMLast }; /* default atoms 
*/
 enum { ClkTagBar, ClkLtSymbol, ClkStatusText, ClkWinTitle,
ClkClientWin, ClkRootWin, ClkLast }; /* clicks */
@@ -1526,6 +1526,7 @@ setup(void) {
netatom[NetWMWindowType] = XInternAtom(dpy, _NET_WM_WINDOW_TYPE, 
False);
netatom[NetWMWindowTypeDialog] = XInternAtom(dpy, 
_NET_WM_WINDOW_TYPE_DIALOG, False);
netatom[NetClientList] = XInternAtom(dpy, _NET_CLIENT_LIST, False);
+   netatom[NetSupportingWMCheck] = XInternAtom(dpy, 
_NET_SUPPORTING_WM_CHECK, False);
/* init cursors */
cursor[CurNormal] = drw_cur_create(drw, XC_left_ptr);
cursor[CurResize] = drw_cur_create(drw, XC_sizing);
@@ -1744,6 +1745,12 @@ updatebars(void) {
m-barwin = XCreateWindow(dpy, root, m-wx, m-by, m-ww, bh, 
0, DefaultDepth(dpy, screen),
  CopyFromParent, DefaultVisual(dpy, 
screen),
  
CWOverrideRedirect|CWBackPixmap|CWEventMask, wa);
+   XChangeProperty(dpy, root, netatom[NetSupportingWMCheck], 
XA_WINDOW, 32,
+   PropModeReplace, (unsigned char *) 
(m-barwin), 1);
+   XChangeProperty(dpy, m-barwin, netatom[NetSupportingWMCheck], 
XA_WINDOW, 32,
+   PropModeReplace, (unsigned char *) 
(m-barwin), 1);
+   XChangeProperty(dpy, m-barwin, netatom[NetWMName], XA_STRING, 
8,
+   PropModeReplace, (unsigned char *) dwm, 3);
XDefineCursor(dpy, m-barwin, cursor[CurNormal]-cursor);
XMapRaised(dpy, m-barwin);
}
-- 
2.1.4




Re: [dev] [vis][RFC][PATCH 1/2] Replace first '/' of substitute command with \0

2015-05-06 Thread Silvan Jegen
On Wed, May 06, 2015 at 09:00:17AM -0700, Eric Pruitt wrote:
 On Wed, May 06, 2015 at 05:12:25PM +0200, Silvan Jegen wrote:
  On Wed, May 06, 2015 at 07:24:30AM -0700, Eric Pruitt wrote:
   On Wed, May 06, 2015 at 10:10:21AM +0200, Silvan Jegen wrote:
I do it to indicate that I agree with the licensing terms of the
existing code and to make explicit that I want to let you use this
code (that to my best knowledge is of my own devising, does not
infringe any patents yaddayaddayadda...). 
  [...]
  Sure, but why would they? To indicate that I contributed the code? Worst
  case I can deny it and it would be a patt situation.
 
 By that logic, why would someone contribute to a project if they didn't
 agree to the license?

Hehe, they did not contribute, they just sent an unreadable email with
funny characters in it! :P Also, maybe they did not read the license?...

It really is not that important. I'll leave the tag out next time.




Re: [dev] [vis][PATCH] Use the command name without the Filerange in argv

2015-05-06 Thread Marc André Tanner
Thanks, will apply.

-- 
 Marc André Tanner  http://www.brain-dump.org/  GPG key: CF7D56C0



Re: [dev] [vis][RFC][PATCH 1/2] Replace first '/' of substitute command with \0

2015-05-06 Thread Marc André Tanner
On Tue, May 05, 2015 at 06:25:29PM +0200, Silvan Jegen wrote:
 Replacing the first '/' allows the 's' command name to be correctly
 identified even though it is part of its own argument.

Special casing '/' seems wrong, an arbitrary delimiter can be used

 :s,foo,bar

is perfectly valid. The end of the command name should probably be
detected by isalpha(3) or similar. Hence instead of doing a strdup(...)
we should probably do a malloc(strlen(...)+2) in combination with
a strcpy/memcpy and then memmove(...) the arguments one position to
the right and NUL-terminate the name.

 This is hacky because afterwards we will add the '/' back in before
 calling the 'sed' program.

Relying on the fact that cmd_set was called with (i.e. that argv[0]
was set to) ':s/' is wrong, it could also be ':substitute/'.

With the strategy outlined above argv[1] would contain the argument
(= search pattern) which could be prefixed by 's'. Furthermore if
the pattern doesn't contain the delimiter at the end, it should
be appended.

Please send an updated patch if you think this makes sense ...

-- 
 Marc André Tanner  http://www.brain-dump.org/  GPG key: CF7D56C0



Re: [dev] [vis] [PATCH] Add '--' as end of options.

2015-05-06 Thread Matias Linares
 Thanks for the patch, however it doesn't do what it describes?
 
  $ vis -- -v
 
 Still prints the version instead of opening a file called -v.

Yeah, I just tried opening files. Sorry for this :/

 Also it would be nice to add a note to the man page.

I will redo the patch and I'll add this on the man page also


pgpozfhHT8pFq.pgp
Description: PGP signature


Re: [dev] [vis][RFC][PATCH 2/2] Implement the execution of external commands and cmd_substitute

2015-05-06 Thread Marc André Tanner
Thanks, this will require more time to properly review than I currently
have. What follows are therefore only a few general remarks.

 The code for the read/write loops communicating through a pipe with the
 external process is very ugly. There must be a better way to implement
 the pipe communication but I could not figure it out.

This is where a proper libuv based main loop would come in handy. Ideally
the editor core should remain responsive while the asynchronous I/O is beeing
done. There should be some kind of progress indication and a way to cancel
those long running tasks. Also while doing so the text should essentially
be marked read only.

 This approach uses a unnecessary amount of memory too since it keeps a lot
 of the input data for the external process

This should not be necessary, it should be possible to repeatedly call 
text_range_write (ignoring for now that it always takes a snapshot) with
a resonable range which is adjusted each time.
  
 as well as its output data in memory at the same time

Similarly it should be possible to insert the data from the external process
as it becomes available. One idea is to write the new data after the 
specified range which is being written out.

Assuming we want to process the range [10, 100] it would work as follows:

 1) text_snapshot

 2) while (data to write or data to read)
   if (data to write)
   write range [10, 20] (on next iteration [20, 30] etc ...)
   if (data to read)
   read range and insert into [100, 110] ([110, 120], ...)

 3) read command exit status depending on success
 - either delete original range [10, 100] and snapshot
 - or revert to last snapshot (text_undo)

-- 
 Marc André Tanner  http://www.brain-dump.org/  GPG key: CF7D56C0



Re: [dev] [vis][PATCH] Make the '.' Filerange work on one line

2015-05-06 Thread Marc André Tanner
When an incomplete range is specified i.e. only a start position
the cursor should jump to it. This patch breaks this functionality.
For example :nn (absolute line), :+n (relative line), :'m mark
(move to mark) is broken.

You probably want something ugly like the following?

On Tue, May 05, 2015 at 06:23:53PM +0200, Silvan Jegen wrote:
 Signed-off-by: Silvan Jegen s.je...@gmail.com
 ---
  vis.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/vis.c b/vis.c
 index 051f256..cf157f7 100644
 --- a/vis.c
 +++ b/vis.c
 @@ -1714,8 +1714,10 @@ static Filerange parse_range(char **cmd) {
   break;
   default:
char start = **cmd;
r.start = parse_pos(cmd);
if (**cmd != ',') {
if (start == '.')
r.end = text_line_end(txt, r.start);
return r;
}

Also should '.' include the new line character? It seems like it does
in vim. Then text_line_next should be used.

At the moment if no range is specified the range is set to the whole
file in exec_cmdline_command. This should probably be changed such
that the commands are called with an empty range. Then each command 
can decide what its default should be. For example :write should
default to the whole file while :s/foo/bar/ should only be applied
to the current line by default.

Thanks,
Marc

-- 
 Marc André Tanner  http://www.brain-dump.org/  GPG key: CF7D56C0



Re: [dev] [slock] [PATCH] Option to not show failure color on clear

2015-05-06 Thread Nick Currier
On Wed, May 6, 2015 at 9:20 AM, Markus Teich markus.te...@stusta.mhn.de wrote:
 I think the new behaviour actually is a more reasonable default.

I had talked to both sin and dsp about this and they thought it best
to keep the existing behaviour.
However, it's easy enough to change if the consensus is to change the default.

 locks[screen]-colors[failure || failonclear ?  FAILED : INIT]

I've made this change and attached the updated patch.

Thanks,
hexid
From e7faddb33b183e966bc2858d146ab9ba78695377 Mon Sep 17 00:00:00 2001
From: hexid nick.curr...@gmail.com
Date: Wed, 6 May 2015 09:34:59 -0600
Subject: [PATCH] Add config option to only show error color after a
 failed login attempt

---
 config.def.h | 1 +
 slock.c  | 9 ++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/config.def.h b/config.def.h
index 4bccb5d..fca0ae0 100644
--- a/config.def.h
+++ b/config.def.h
@@ -3,3 +3,4 @@ static const char *colorname[NUMCOLS] = {
 	#005577,   /* during input */
 	#CC,   /* failed/cleared the input */
 };
+static const Bool failonclear = True;
diff --git a/slock.c b/slock.c
index 6502c86..1551a9e 100644
--- a/slock.c
+++ b/slock.c
@@ -26,7 +26,7 @@
 enum {
 	INIT,
 	INPUT,
-	EMPTY,
+	FAILED,
 	NUMCOLS
 };
 
@@ -42,6 +42,7 @@ typedef struct {
 static Lock **locks;
 static int nscreens;
 static Bool running = True;
+static Bool failure = False;
 static Bool rr;
 static int rrevbase;
 static int rrerrbase;
@@ -153,8 +154,10 @@ readpw(Display *dpy, const char *pws)
 #else
 running = !!strcmp(crypt(passwd, pws), pws);
 #endif
-if (running)
+if (running) {
 	XBell(dpy, 100);
+	failure = True;
+}
 len = 0;
 break;
 			case XK_Escape:
@@ -178,7 +181,7 @@ readpw(Display *dpy, const char *pws)
 }
 			} else if (llen != 0  len == 0) {
 for (screen = 0; screen  nscreens; screen++) {
-	XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[EMPTY]);
+	XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[failure || failonclear ? FAILED : INIT]);
 	XClearWindow(dpy, locks[screen]-win);
 }
 			}
-- 
2.3.7



Re: [dev] [vis] [PATCH] Add '--' as end of options.

2015-05-06 Thread Marc André Tanner
 Some programs (like ranger) expect the editor to have this feature.

Thanks for the patch, however it doesn't do what it describes?

 $ vis -- -v

Still prints the version instead of opening a file called -v.

Also it would be nice to add a note to the man page.

-- 
 Marc André Tanner  http://www.brain-dump.org/  GPG key: CF7D56C0



Re: [dev] Odds and ends (2/2): $XEMBED

2015-05-06 Thread Connor Lane Smith
On 6 May 2015 at 15:28, Jason Woofenden ja...@jasonwoof.com wrote:
 If you don't replace the terminal window, then you're just talking
 about window management, which should perhaps be done with the
 window manager. The XEMBED thing only works on a few clients. The
 WM can meddle with just about all the clients.

I'm not sure this can be done for clients not supporting an XEmbed
flag, since there is no way in general to associate PIDs with XIDs.
The two processes have to be in cahoots.

 Another way you can get close to having the new graphical client
 replace your terminal is to auto-close the terminal by binding a
 key in your shell to run the program you typed in the background
 and then close the terminal.

This has a few drawbacks:

* You have to remember a new keybind, only for backgrounding X clients.
* If the command fails you can't tell or see why, since stderr is lost.
* Once the command has finished you can't go back to the terminal.

All in all, I think having a wrapper for this is worthwhile.

Thanks,
cls



Re: [dev] [slock] [PATCH] Option to not show failure color on clear

2015-05-06 Thread Markus Teich
Nick Currier wrote:
 On Wed, May 6, 2015 at 9:20 AM, Markus Teich markus.te...@stusta.mhn.de
 wrote:
  I think the new behaviour actually is a more reasonable default.
 
 I had talked to both sin and dsp about this and they thought it best to keep
 the existing behaviour.  However, it's easy enough to change if the consensus
 is to change the default.

Heyho,

I think the failcolor should notify the user about malicious intentions from
other people. Pressing a key (maybe even by accident) is not malicious in my
opinion. Also sometimes I begin typing my password (out of a habit) before the
screen wakes up and it would be nice to still be able to check if someone else
tried to login before.

What were your thoughts, sin and dsp?

--Markus



Re: [dev] [slock] [PATCH] Option to not show failure color on clear

2015-05-06 Thread FRIGN
On Wed, 6 May 2015 18:27:01 +0200
Markus Teich markus.te...@stusta.mhn.de wrote:

 What were your thoughts, sin and dsp?

I like the new behaviour, namely making the state dirty as soon
as a key has been pressed or a wrong password entered.

It's a big contribution to security and you often wonder if
somebody tried to access your computer while you were out with friends
or fetching some food from the local pub.

Come to think of this sentence, who seriously eats at a pub?

Cheers

FRIGN

-- 
FRIGN d...@frign.de



Re: [dev] [vis][RFC][PATCH 1/2] Replace first '/' of substitute command with \0

2015-05-06 Thread Silvan Jegen
On Wed, May 06, 2015 at 07:24:30AM -0700, Eric Pruitt wrote:
 On Wed, May 06, 2015 at 10:10:21AM +0200, Silvan Jegen wrote:
  I do it to indicate that I agree with the licensing terms of the
  existing code and to make explicit that I want to let you use this
  code (that to my best knowledge is of my own devising, does not
  infringe any patents yaddayaddayadda...). That is what the Linux
  kernel people use this tag for[0].
 
 How does that indicate you agree with the terms? If you aren't GPG
 signing the commits, that message adds no additional insurance that you
 are actually the author of the commit; anyone can add that line to the
 patch if they so desire.

Sure, but why would they? To indicate that I contributed the code? Worst
case I can deny it and it would be a patt situation.

I'm not a lawyer (thank god) but it seems to me like the legal status
of email is a murky topic anyway. I don't assume that all email archives
used in court are without exception stemming from non-forgeable email
addresses for example (though I would certainly hope so)...

What I am doing with this tag is expressing my good intentions.


  If you prefer me not to do it, I won't in the future.
 
 I don't even have commit privileges to any of the suckless repositories,
 so it's not up to me.

This was more directed at the people on the list in general.

I don't feel strongly either way (especially since I am located in Europe
where software patents are not legally binding anyways AFAIK).


Cheers,

Silvan




Re: [dev] [ST] [PATCH] Clean up xdraws and optimize glyph drawing with non-unit kerning values

2015-05-06 Thread suigin
Here's a third version of the patch with some minor changes. It removes
the curly braces around the body of the `if' clause in
`xmakeglyphfontspecs' that checks for ATTR_WDUMMY. It simplifies some
of the conditional logic in `xdrawglyphfontspecs', by pulling out the
check to see if `base.fg' is the same as `defaultfg' when changing the
foreground color, and it also adds an ATTR_BOLD_FAINT composite attribute
to simplify some of bold/faint exclusive or checks in this function.
diff --git a/st.c b/st.c
index 4add638..c2da66b 100644
--- a/st.c
+++ b/st.c
@@ -58,7 +58,6 @@ char *argv0;
 #define ESC_ARG_SIZ   16
 #define STR_BUF_SIZ   ESC_BUF_SIZ
 #define STR_ARG_SIZ   ESC_ARG_SIZ
-#define DRAW_BUF_SIZ  20*1024
 #define XK_ANY_MODUINT_MAX
 #define XK_NO_MOD 0
 #define XK_SWITCH_MOD (113)
@@ -87,18 +86,19 @@ char *argv0;
 
 
 enum glyph_attribute {
-	ATTR_NULL  = 0,
-	ATTR_BOLD  = 1  0,
-	ATTR_FAINT = 1  1,
-	ATTR_ITALIC= 1  2,
-	ATTR_UNDERLINE = 1  3,
-	ATTR_BLINK = 1  4,
-	ATTR_REVERSE   = 1  5,
-	ATTR_INVISIBLE = 1  6,
-	ATTR_STRUCK= 1  7,
-	ATTR_WRAP  = 1  8,
-	ATTR_WIDE  = 1  9,
-	ATTR_WDUMMY= 1  10,
+	ATTR_NULL   = 0,
+	ATTR_BOLD   = 1  0,
+	ATTR_FAINT  = 1  1,
+	ATTR_ITALIC = 1  2,
+	ATTR_UNDERLINE  = 1  3,
+	ATTR_BLINK  = 1  4,
+	ATTR_REVERSE= 1  5,
+	ATTR_INVISIBLE  = 1  6,
+	ATTR_STRUCK = 1  7,
+	ATTR_WRAP   = 1  8,
+	ATTR_WIDE   = 1  9,
+	ATTR_WDUMMY = 1  10,
+	ATTR_BOLD_FAINT = ATTR_BOLD | ATTR_FAINT,
 };
 
 enum cursor_movement {
@@ -232,6 +232,7 @@ typedef struct {
 	Line *line;   /* screen */
 	Line *alt;/* alternate screen */
 	bool *dirty;  /* dirtyness of lines */
+	XftGlyphFontSpec *specbuf; /* font spec buffer used for rendering */
 	TCursor c;/* cursor */
 	int top;  /* topscroll limit */
 	int bot;  /* bottom scroll limit */
@@ -418,7 +419,8 @@ static void ttywrite(const char *, size_t);
 static void tstrsequence(uchar);
 
 static inline ushort sixd_to_16bit(int);
-static void xdraws(char *, Glyph, int, int, int, int);
+static int xmakeglyphfontspecs(XftGlyphFontSpec *, const Glyph *, int, int, int);
+static void xdrawglyphfontspecs(const XftGlyphFontSpec *, Glyph, int, int, int);
 static void xdrawglyph(Glyph, int, int);
 static void xhints(void);
 static void xclear(int, int, int, int);
@@ -2819,6 +2821,9 @@ tresize(int col, int row) {
 		free(term.alt[i]);
 	}
 
+	/* resize to new width */
+	term.specbuf = xrealloc(term.specbuf, col * sizeof(XftGlyphFontSpec));
+
 	/* resize to new height */
 	term.line = xrealloc(term.line, row * sizeof(Line));
 	term.alt  = xrealloc(term.alt,  row * sizeof(Line));
@@ -3257,38 +3262,155 @@ xinit(void) {
 	XSync(xw.dpy, False);
 }
 
-void
-xdraws(char *s, Glyph base, int x, int y, int charlen, int bytelen) {
-	int winx = borderpx + x * xw.cw, winy = borderpx + y * xw.ch,
-	width = charlen * xw.cw, xp, i;
-	int frcflags, charexists;
-	int u8fl, u8fblen, u8cblen, doesexist;
-	char *u8c, *u8fs;
-	Rune unicodep;
+int
+xmakeglyphfontspecs(XftGlyphFontSpec *specs, const Glyph *glyphs, int len, int x, int y)
+{
+	float winx = borderpx + x * xw.cw, winy = borderpx + y * xw.ch, xp, yp;
+	ushort mode, prevmode = USHRT_MAX;
 	Font *font = dc.font;
+	int frcflags = FRC_NORMAL;
+	float runewidth = xw.cw;
+	Rune rune;
+	FT_UInt glyphidx;
 	FcResult fcres;
 	FcPattern *fcpattern, *fontpattern;
 	FcFontSet *fcsets[] = { NULL };
 	FcCharSet *fccharset;
+	int i, f, numspecs = 0;
+
+	for(i = 0, xp = winx, yp = winy + font-ascent; i  len; ++i) {
+		/* Fetch rune and mode for current glyph. */
+		rune = glyphs[i].u;
+		mode = glyphs[i].mode;
+
+		/* Skip dummy wide-character spacing. */
+		if(mode == ATTR_WDUMMY)
+			continue;
+
+		/* Determine font for glyph if different from previous glyph. */
+		if(prevmode != mode) {
+			prevmode = mode;
+			font = dc.font;
+			frcflags = FRC_NORMAL;
+			runewidth = xw.cw * ((mode  ATTR_WIDE) ? 2.0f : 1.0f);
+			if((mode  ATTR_ITALIC)  (mode  ATTR_BOLD)) {
+font = dc.ibfont;
+frcflags = FRC_ITALICBOLD;
+			} else if(mode  ATTR_ITALIC) {
+font = dc.ifont;
+frcflags = FRC_ITALIC;
+			} else if(mode  ATTR_BOLD) {
+font = dc.bfont;
+frcflags = FRC_BOLD;
+			}
+			yp = winy + font-ascent;
+		}
+
+		/* Lookup character index with default font. */
+		glyphidx = XftCharIndex(xw.dpy, font-match, rune);
+		if(glyphidx) {
+			specs[numspecs].font = font-match;
+			specs[numspecs].glyph = glyphidx;
+			specs[numspecs].x = (short)xp;
+			specs[numspecs].y = (short)yp;
+			xp += runewidth;
+			numspecs++;
+			continue;
+		}
+
+		/* Fallback on font cache, search the font cache for match. */
+		for(f = 0; f  frclen; f++) {
+			glyphidx = XftCharIndex(xw.dpy, frc[f].font, rune);
+			/* Everything correct. */
+			if(glyphidx  frc[f].flags == frcflags)
+break;
+			/* We got a default font for a not found glyph. */
+			if(!glyphidx  frc[f].flags == frcflags
+	 frc[f].unicodep == rune) {
+break;
+			}
+		}
+
+		/* 

Re: [dev] [vis][RFC][PATCH 1/2] Replace first '/' of substitute command with \0

2015-05-06 Thread Nick
Quoth Silvan Jegen:
 What I am doing with this tag is expressing my good intentions.

Good intentions are assumed for all the patches here, which is 
reasonable and right. If some lawsuit came about (which it won't) 
the norms of behaviour on the list should trump any git tags.



Re: [dev] Odds and ends (2/2): $XEMBED

2015-05-06 Thread Raphaël Proust
On 6 May 2015 at 15:28, Jason Woofenden ja...@jasonwoof.com wrote:
 This would be a little cleaner if you set your WM to stack new
 windows just after the focused one.

Assuming your window is stacked and not floating…

More seriously, the behaviour 9embed provides is to have a window
content being swapped whilst its other attributes remain. This is
transparent to the window manager. (It's like changing a value but
keeping the pointer. Your approach is to create a new value and change
the pointer. Both might be useful…)


Ideally, when the process terminates (when you quit surf) the window
goes back to the terminal emulator and your shell resumes. Obviously,
if you quit surf by closing the window that's different.


-- 
__
Raphaël Proust



Re: [dev] [slock] [PATCH] Option to not show failure color on clear

2015-05-06 Thread Markus Teich
Heyho,

Nick Currier wrote:
 This patch adds the failonclear boolean option so that, when false,
 the failure color will not appear until a failed login attempt has
 been made.
 It also maintains the existing behaviour (failure on clear) by default.

I think the new behaviour actually is a more reasonable default.

 + if (failure || failonclear) {
 + for (screen = 0; screen  nscreens; 
 screen++) {
 + XSetWindowBackground(dpy, 
 locks[screen]-win, locks[screen]-colors[FAILED]);
 + XClearWindow(dpy, 
 locks[screen]-win);
 + }
 + } else {
 + for (screen = 0; screen  nscreens; 
 screen++) {
 + XSetWindowBackground(dpy, 
 locks[screen]-win, locks[screen]-colors[INIT]);
 + XClearWindow(dpy, 
 locks[screen]-win);
 + }

Can you also change this to use

locks[screen]-colors[failure || failonclear ?  FAILED : INIT]

instead of the outer if-else block?

--Markus



Re: [dev] [vis][RFC][PATCH 1/2] Replace first '/' of substitute command with \0

2015-05-06 Thread Eric Pruitt
On Wed, May 06, 2015 at 05:12:25PM +0200, Silvan Jegen wrote:
 On Wed, May 06, 2015 at 07:24:30AM -0700, Eric Pruitt wrote:
  On Wed, May 06, 2015 at 10:10:21AM +0200, Silvan Jegen wrote:
   I do it to indicate that I agree with the licensing terms of the
   existing code and to make explicit that I want to let you use this
   code (that to my best knowledge is of my own devising, does not
   infringe any patents yaddayaddayadda...). 
 [...]
 Sure, but why would they? To indicate that I contributed the code? Worst
 case I can deny it and it would be a patt situation.

By that logic, why would someone contribute to a project if they didn't
agree to the license?

Eric