Re: [dev] [ubase] compile using musl

[Eric Pruitt]

On Fri, Mar 15, 2024 at 04:22:19PM -0300, Brian Mayer wrote:
> My guess is that glibc provides that function by musl doesn't. So as
> my system is using musl that function is not found. Can I get some
> help?

The splice(2) call is provided by musl:

src/linux/splice.c:ssize_t splice(int fd_in, off_t *off_in, int fd_out, 
off_t *off_out, size_t len, unsigned flags)
include/fcntl.h:ssize_t splice(int, off_t *, int, off_t *, size_t, 
unsigned);

What version of musl are you using? I don't get that compilation error
on my x86_64 desktop, but the build does fail to find makedev which
seems to be due to an issue with the header includes:

ubase$ make -j1 CC=/home/ericpruitt/emus/core/musl-1.2.4/bin/musl-cc
/home/ericpruitt/emus/core/musl-1.2.4/bin/musl-cc -s -o mknod mknod.o 
libutil.a -lcrypt
/usr/bin/ld: mknod.o: in function `main':
mknod.c:(.text+0x27d): undefined reference to `makedev'
collect2: error: ld returned 1 exit status
gmake: *** [Makefile:161: mknod] Error 1

The glibc documentation says makedev and related macros should be
included via  which mknod.c does not use. I assume it
works on glibc because one of the explicitly mentioned headers itself
pulls in sysmacros.h. I would guess you're running into a similar issue.

Eric

Re: [dev] gtk2 without atk

[Eric Pruitt]

On Thu, Jan 11, 2024 at 09:46:15PM +, stefan1 wrote:
> Is anyone else here interested in this?
> Does anyone have similar projects?

I think there's nothing wrong with wanting slimmer software, and I could
see myself using this, but re: the README, "like atk and accessiblilty
nonsense," I don't think it's nonsense to want to make it easier for
people with disabilities to use software.

I was going to comment that sentiment of "**I** don't need it, so it's
nonsense" reminds me of some past discussions on the suckless lists
where some people complained about supporting non-Latin character sets
in graphical projects by way of fallback font logic, and then as I was
looking through the commit history, I saw that you deleted tons of
translation and language support files...

Eric

Re: [dev] minimal sound effect/music generator

[Eric Pruitt]

On Sun, Dec 24, 2023 at 12:19:48PM +1100, syg wrote:
> After working on it on and off for about three years now, I figured it
> was time to shill my little program to you fine people.
> 
> https://sndc.studio

Is there a license for this somewhere? I couldn't find one.

Eric

[dev] surf: usage does not match supported flags

[Eric Pruitt]

Since at least commit fce76429b8f8ed48116557df3a478bc435145d94, the
flags in surf's usage don't match what's actually supported.

Eric

[dev] Can I prevent active window / input focus change when using shortcuts?

[Eric Pruitt]

Is there a way to configure or patch dwm that makes it so using keyboard
shortcuts doesn't result input focus being lost? For example, if I use
non-ACPI shortcuts to change my volume while I'm playing games, it will
result in some momentarily muting audio or pausing the game briefly.

Eric

Re: [dev] [dwm][bug] Programs teleport tag on startup

[Eric Pruitt]

On Sun, Jan 17, 2021 at 10:58:10AM +, Hritik Vijay wrote:
> > Are there window managers that do NOT behave this way with respect
> > to workspaces?
>
> I've seen i3 handle this case with a i3-exec binary. It basically
> launches the target application and signals the i3wm where it was
> executed. I guess something similar could be developed here. It could
> be used as a wrapper inside dmenu launcher.

I can't find a binary named i3-exec in the i3 GitHub repository
(https://github.com/i3/i3) or in lists of files for the i3 Debian
package (https://packages.debian.org/bullseye/amd64/i3-wm/filelist).

Eric

Re: [dev] [dwm][bug] Programs teleport tag on startup

[Eric Pruitt]

On Sat, Jan 16, 2021 at 10:13:11PM -0800, Spenser Truex wrote:
> To me this seems like undesirable behaviour, since after opening a
> program one has to wait for it to load before switching the current tag.
> 
> Reproduction:
> Run a program (eg. firefox) in tag 1
> Switch tag view before it loads to tag 2
> It gets labeled in tag 2, not tag 1.
> 
> Expect: use tag 1, not 2.
> 
> I can't imagine any way that this is desirable. I will try to patch a
> fix later, seems like low hanging fruit.

This is completely unsurprising to me because dwm doesn't know about the
application until a window gets created. Are there window managers that
do NOT behave this way with respect to workspaces? I can think of ways
you could work around this, but I wouldn't consider any of them low
hanging fruit. What do you have in mind to address this?

Eric

Re: [dev] [dmenu] ASCII tab and unit separator cause startup lag

[Eric Pruitt]

On Thu, Aug 06, 2020 at 10:06:35AM -0400, Greg B wrote:
> I am using the packaged dmenu in Ubuntu 20.04. A sample of the output of
> my window listing script is below, along with two simpler samples
> exhibiting slow startup behavior.
> 
> I'm happy to do further testing or troubleshooting if anyone can point
> me in the right direction.
> 
> -gb
> 
> $ dmenu -v
> dmenu-4.8
> 
> # simple repro with tabs - startup render seems to scale linearly with
> # number of tabs
> $ for i in {1..10}; do echo $'\t'; done | dmenu

I can reproduce this issue on Debian 10.

Eric

Re: [dev] startup time of some interpreters

[Eric Pruitt]

On Thu, Feb 20, 2020 at 12:22:53PM -0500, Greg Reagle wrote:
> Hello. I am amazed at how fast Lua is to start up and shut down. Is my
> benchmark defective in any way? Lua seems to start up and exit faster
> than bash, python, rc, and ksh. Dash and mksh are faster. These
> interpreters are all packages from Debian Stable 10 "Buster".

One problem I see with these benchmarks is that it's not an entirely
fair comparison. For example, in Python, you're only printing some text,
but you aren't importing any modules. Just about every non-trivial
Python script will import at least one module which will in turn import
others, and imports affect how long it takes before the core of your
script runs:

$ time for _ in {1..10}; do python -c 'print("Hello world")'; done
...
[0.376s (98.63% CPU; User: 0.322, Sys: 0.049)]

$ time for _ in {1..10}; do python -c 'import subprocess; import os; 
print("Hello world")'; done
...
[0.502s (99.91% CPU; User: 0.402, Sys: 0.099)]

I've used "os" and "subprocess" in my examples since those are among the
most likely to be used if you're replacing a shell script with a Python
script.

Also, you didn't include AWK interpreters. On my system MAWK and the
typically slower GAWK take around the same time to print "Hello world"
as dash does on my machines:

$ time for _ in {1..10}; do mawk 'BEGIN { print "Hello world" }'; done > 
/dev/null
[0.112s (100.60% CPU; User: 0.107, Sys: 0.005)]

$ time for _ in {1..10}; do gawk 'BEGIN { print "Hello world" }'; done > 
/dev/null
[0.152s (99.90% CPU; User: 0.150, Sys: 0.002)]

$ time for _ in {1..10}; do sh -c 'echo Hello world'; done > /dev/null
[0.115s (100.53% CPU; User: 0.104, Sys: 0.012)]

Eric

Re: [dev] [st] monospace rendering gaps

[Eric Pruitt]

On Sat, Dec 07, 2019 at 03:50:09AM +, sylvain.bertr...@gmail.com wrote:
> I did fool around with your patch and the dejavu font: when I forced the
> pixel size I got those gaps. Not to mention the anti-aliasing seems to be
> involved.

I don't understand how it would be possible to have the gaps if you're
forcing the sizes. Could you post a screenshot? Also, are you certain
your changes are going into effect? You could test it by setting the
bounding boxes to something ridiculously small like 0.5 for ch/cwscale
or something like 6 pixels if you're using absolute values.

Eric

Re: [dev] [st] monospace rendering gaps

[Eric Pruitt]

On Thu, Dec 05, 2019 at 06:19:16PM +, sylvain.bertr...@gmail.com wrote:
> I know I am walking on eggs: it seems st monospace font rendering with 
> freetype
> (I use dejavu mono) has some vertical and/or horizontal gaps (whatever the
> rendering size).
>
> To illustrate, with lynx web browser:
> https://en.wikipedia.org/wiki/Box-drawing_character#Examples
>
> I don't know what is the bottom of this, anyone?

I've had this same problem since I upgraded to Debian 10. I believe this
is due to changes in character bounding box sizes because you can fix
this by adjusting cwscale and chscale. On my systems, I only have
vertical gaps, and setting chscale to 0.94 removes them. I submitted a
patch to the mailing list to allow both values to be specified using
absolute values of pixels instead of multipliers
(https://lists.suckless.org/hackers/1907/16943.html) so you can ensure
bounding boxes were always the same size regardless of what the font
library reports character dimensions to be, but it was not committed.

Eric

Re: [dev] [dwm][bug] dwm sometimes causes Xorg to freeze

[Eric Pruitt]

On Fri, May 03, 2019 at 11:17:25PM +0200, Przemek Dragańczuk wrote:
> Every so often when running dwm my xorg seems to freeze. I can se the
> mouse cursor move and change according to what's on the screen, but
> the screen itself is frozen, almost as if it was a screenshot. The
> only way to "fix" it is to log into a second tty and kill xorg, but
> the problem comes back, sometimes within minutes.

Try running strace on dwm when this happens. I observed some similar
issues in the past in which dwm would be stuck in an EAGAIN loop reading
the X11 socket. Unfortunately I don't recall how I fixed the issue off
the top of my head.

Eric

Re: [dev] [dwm]/[dmenu] Suggestion: Remove dmenu-integration from dwm

[Eric Pruitt]

On Fri, Mar 01, 2019 at 12:37:06PM -0800, Anselm Garbe wrote:
> So I'd say the primary question is, if we want to keep the -m flag
> handling in dmenu or not. I suggest to drop it.

How about setting an environment variable with the monitor number? It
won't allow for drop-in uses, but people can always write shell script
wrappers to insert it wherever it's needed for their use-case.

Eric

Re: [dev] [dwm] new release - transition from Openbox

[Eric Pruitt]

On Tue, Feb 05, 2019 at 07:20:22PM +0100, Szpak wrote:
> That's a reasonable choice. I actually do the same in my environment. W-key
> is probably the only way to not interact with any app.

I use Caps Lock after mapping it to Hyper:

xmodmap -e "remove mod4 = Hyper_L" \
-e "remove Lock = Caps_Lock" \
-e "keysym Caps_Lock = Hyper_L" \
-e "add mod3 = Hyper_L"

Eric

Re: [dev] [Announce] [dwm-6.2] [dmenu-4.9] new release

[Eric Pruitt]

On Mon, Feb 04, 2019 at 05:37:59PM +0100, Hiltjo Posthuma wrote:
> When the initial version is ready and some (old and) new bugs are squashed it
> will be posted for review ofcourse.

Did you happen to fix the bug where UTF-8 sequences could be broken by
the ellipsis logic in drw_text?

Eric

Re: [dev] [Announce] [dwm-6.2] [dmenu-4.9] new release

[Eric Pruitt]

On Sun, Feb 03, 2019 at 11:17:59PM +0100, a wrote:
> Very nice. Hopefully there will be patches to restore xft support in
> case it's wanted.

I'll be maintaining Xft patches for -- or perhaps forking dwm and dmenu
because fallback font support is critical for me. Once the Xft code has
actually been removed, I'll post links to my patches if I opt for the
former approach.

Eric

Re: [dev] [st] 1) build not working for version >0.5 2) control-tab not working

[Eric Pruitt]

On Sun, Jan 13, 2019 at 08:32:31PM +0200, Alex Yegupov wrote:
> 2) 'control+tab' keypress seems not wokring (at least emacs -nw
> consider it like just 'Tab')
> Is there a way to make this keypress work?

You need to modify the "key" array in config.h. This is what I use for
Ctrl+(Shift)+Tab:

// Ctrl+Tab
{ XK_Tab,   ControlMask,"\033[27;5;9~",  0,0},
// Ctrl+Shft+Tab
{ XK_ISO_Left_Tab,  ShiftControl,   "\033[27;6;9~",  0,0},

Eric

Re: [dev] freetype2/fc pain

[Eric Pruitt]

On Mon, Sep 24, 2018 at 09:22:14PM +0600, Eon S. Jeon wrote:
> Hello, Manu.
>
> Sorry, but merging font is not a good option.
>
> Each font contains settings like height, padding and hinting
> parameters, which are optimized for its glyphs by designers. So,
> merging fonts (or importing glyphs from other fonts) likely to cause
> character misalignment and hinting problems, especially when merging
> fonts of different languages.

Agreed. I actually tried doing this a few years ago. I had managed to
automate the process to some degree using Fontforge, but I ran into all
kinds of rendering issues that I didn't have the patience to debug.

Eric

Re: [dev] freetype2/fc pain

[Eric Pruitt]

On Sun, Sep 23, 2018 at 11:31:29PM -0700, Eric Pruitt wrote:
> Yes, st's fallback font support is the main reason I began to use it. I
> use st and dwm with Japanese and Chinese text almost every single day.

I forgot to add that supporting Japanese, Chinese and Korean is THE
reason I wrote "Add Xft and follback-fonts support to graphics lib" /
14343e69cc596b847f71f1e825d3019ab1a29aa8 in dwm. I was tired of seeing
missing glyph rectangles all the time, and the Pango patches I
originally used no longer applied to HEAD.

Eric

Re: [dev] freetype2/fc pain

[Eric Pruitt]

On Sun, Sep 23, 2018 at 11:19:46PM -0700, AR Garbe wrote:
> On 23 September 2018 at 11:56, Eric Pruitt  wrote:
> > It's not just about Emoji or anti-aliasing. If you work with languages
> > that use non-Latin characters, support for fallback fonts is a must.
>
> Well, are you using st with glyphs that require fallback fonts?
> I wonder if at suckless we should aim for the general purpose.

Yes, st's fallback font support is the main reason I began to use it. I
use st and dwm with Japanese and Chinese text almost every single day.

> I weigh code clarity and consistency higher than being able to render
> all kinds of glyphs through fallback font declarations.
> If a user needs to display cyrillic, there are plain old xfonts with
> excellent support.

If supporting languages spoken by billions of people isn't reason enough
for you, then there's not much point in me arguing because I can't come
up with a better rationale.

Eric

Re: [dev] freetype2/fc pain

[Eric Pruitt]

On Sun, Sep 23, 2018 at 09:14:11AM -0700, AR Garbe wrote:
> I totally agree. I'd be in favour in a st just using plain X fonts.
> This emoji unicode porn and anti-aliasing TTF support doesn't make
> sense to me.

It's not just about Emoji or anti-aliasing. If you work with languages
that use non-Latin characters, support for fallback fonts is a must.

Eric

Re: [dev] [sbase] find and xargs different results than busybox

[Eric Pruitt]

On Wed, Jul 18, 2018 at 06:32:57PM +0200, Markus Wichmann wrote:
> And that's where you're wrong. "find | xargs" is wrong for the same reason
> "sudo su" is wrong, for the same reason "cat singlefile | whatever" is
> wrong: You're doing it wrong. In your case "find -exec" does everything
> you want. It also supports all possible file names.

I didn't provide a case, but here's one I have mind: what if you only
want to run commands if "find" finishes with an exit status of 0? With
find -print0 and xargs -0, it'd look like this:

set -e
find ... -print0 > results
xargs -0 ... < results

Re: [dev] [sbase] find and xargs different results than busybox

[Eric Pruitt]

On Tue, Jul 17, 2018 at 07:05:43AM -0700, Evan Gates wrote:
> find -print0 is not specified by POSIX. If you want to print nul
> separated data use:

The suckless tools don't strictly follow POSIX. For example, sbase mv(1)
and cp(1) don't support "-i". Furthermore it's pretty portable; find(1)
on OpenBSD, FreeBSD, macOS and GNU find(1) all support using NUL bytes.
It's the only sane way to securely support any legal filename.

Eric

[dev] Re: [PATCH] [dwm] Make unset property fallback strings configurable

[Eric Pruitt]

On Sun, Apr 01, 2018 at 02:43:04PM -0700, Eric Pruitt wrote:
>  config.def.h | 5 +
>  dwm.c| 7 +++
>  2 files changed, 8 insertions(+), 4 deletions(-)
>

Whoops; wrong list. I'm resending this to hackers@.

Eric

[dev] [PATCH] [dwm] Make unset property fallback strings configurable

[Eric Pruitt]

Since the default rule matching does substring comparisons, using the
fixed string "broken" as a fallback value can complicate or make
unambiguous matching impossible, so this change makes various fallback
strings for unset properties configurable via config.h.
---
 config.def.h | 5 +
 dwm.c| 7 +++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git config.def.h config.def.h
index a9ac303..8dfc8b1 100644
--- config.def.h
+++ config.def.h
@@ -43,6 +43,11 @@ static const Layout layouts[] = {
 	{ "[M]",  monocle },
 };
 
+/* Fallback strings for unset window properties. */
+static const char unset_instance_fallback[] = "broken";
+static const char unset_class_fallback[] = "broken";
+static const char unset_name_fallback[] = "broken";
+
 /* key definitions */
 #define MODKEY Mod1Mask
 #define TAGKEYS(KEY,TAG) \
diff --git dwm.c dwm.c
index c98678d..9735e32 100644
--- dwm.c
+++ dwm.c
@@ -235,7 +235,6 @@ static int xerrorstart(Display *dpy, XErrorEvent *ee);
 static void zoom(const Arg *arg);
 
 /* variables */
-static const char broken[] = "broken";
 static char stext[256];
 static int screen;
 static int sw, sh;   /* X display screen geometry width, height */
@@ -288,8 +287,8 @@ applyrules(Client *c)
 	c->isfloating = 0;
 	c->tags = 0;
 	XGetClassHint(dpy, c->win, );
-	class= ch.res_class ? ch.res_class : broken;
-	instance = ch.res_name  ? ch.res_name  : broken;
+	class= ch.res_class ? ch.res_class : unset_class_fallback;
+	instance = ch.res_name  ? ch.res_name  : unset_instance_fallback;
 
 	for (i = 0; i < LENGTH(rules); i++) {
 		r = [i];
@@ -1998,7 +1997,7 @@ updatetitle(Client *c)
 	if (!gettextprop(c->win, netatom[NetWMName], c->name, sizeof c->name))
 		gettextprop(c->win, XA_WM_NAME, c->name, sizeof c->name);
 	if (c->name[0] == '\0') /* hack to mark broken clients */
-		strcpy(c->name, broken);
+		strcpy(c->name, unset_name_fallback);
 }
 
 void

Re: [dev] [st] [patch] If no Glyph Found, Do Not Keep a Font Loaded

[Eric Pruitt]

On Wed, Mar 21, 2018 at 05:42:07PM -0400, Gary Allen Vollink wrote:
> Any request for a glyph that isn't present will load the LastResort
> font, effectively killing all future fallback searches.
>
> I have NO idea how to fix this without opening the vacuum of space
> (wow, a lot of suck).  I will note that if frc[] is not an array then
> it wouldn't be checked for an already opened font (fixed)!  I am still
> NOT advocating this.
>
> Fontconfig sucks.

I have a patch for st that allows the user to define multiple fallback
fonts as an array:

https://github.com/ericpruitt/edge/blob/master/patches/st-00-font-array-support.diff
This doesn't necessarily eliminate the problem, but by explicitly
specifying fonts for languages you care about, you can at least mitigate
the problem for the common case of languages you care about.

Eric

Re: [dev] [dwm] Crash with emojis on title bar

[Eric Pruitt]

On Sun, Feb 11, 2018 at 08:55:17PM +, Stancil, Robert Andrew wrote:
> Unless I'm mistaken, doesn't the pango patch[1] answer this question? Or
> does the color emoji crash happen for both pango and xft?
>
> https://dwm.suckless.org/patches/pango/

Just because that patch exists doesn't mean that's the solution Hiltjo
had in mind:

On Sat, Feb 10, 2018 at 08:13:27PM +0100, Hiltjo Posthuma wrote:
> It doesn't sound like a dwm issue, but rather Xft. I won't add more
> dependencies to dwm. Rather we should get rid of Xft.

Pango is a much heavier library than Xft, so I would be surprised if
Hiltjo was suggesting that was use Pango.

Eric

Re: [dev] [dwm] Crash with emojis on title bar

[Eric Pruitt]

On Sat, Feb 10, 2018 at 05:30:16PM -0200, Igor Fontana wrote:
> > It doesn't sound like a dwm issue, but rather Xft. I won't add more
> > dependencies to dwm. Rather we should get rid of Xft.
>
> yes, teh guy said something about fontconfig+harfbuzz-ng.
>
> > I cannot reproduce the issue on my machine, but there are other reports that
> > have a similar issue. Feel free to debug it and send a patch.
>
> ok ty!

I also have never had dwm crash when displaying emojis. I think (but I'm
not 100% certain) one of the common elements among users that get
crashes from emojis is having color emoji fonts installed. The only
emoji font I have installed on my computer is the colorless Symbola
(https://fontlibrary.org/en/font/symbola). If you happen to have some
other font(s) installed, consider temporarily uninstalling them or
disabling them with fonts.conf to see if that eliminates the crashes. If
that fixes the issue and you still really want color emojis to be used
in applications that support them, you could modify dwm so that it
favors Symbola. You can find the patch I use to explicitly define
fallback fonts here:

- 
https://github.com/ericpruitt/edge/blob/master/patches/st-00-font-array-support.diff

In your case, the configuration would be something like this:

static const char *fonts[] = {
"",
"Symbola",
};

Eric

Re: [dev] [dwm] Crash with emojis on title bar

[Eric Pruitt]

On Sat, Feb 10, 2018 at 08:13:27PM +0100, Hiltjo Posthuma wrote:
> It doesn't sound like a dwm issue, but rather Xft. I won't add more
> dependencies to dwm. Rather we should get rid of Xft.

And replace it with what?

Eric

Re: [dev] [st] Some tmux trouble

[Eric Pruitt]

On Sun, Dec 31, 2017 at 10:15:24PM +0100, Hadrien Lacour wrote:
> I'm trying to do
> `st -e "tmux a -t cmus"`

Use `st -e tmux -a -t cmus` as documented in st(1) which reads "-e
command [arguments...]".

Eric

Re: [dev] [st] How can I scroll up in emacs

[Eric Pruitt]

On Fri, Nov 17, 2017 at 10:39:10PM +0800, Amos Bird wrote:
> Mouse wheel events are translated to key presses. ^E and ^Y are for
> Vi/Vim/less. Change it in config.h to work with EMACS if you like.

This is wrong. Applications that support the X11 TTY extensions are sent
dedicated escape sequences whenever there's a mouse a event, scrolling
included. If an application does not support the extensions, then the ^Y
/ ^E (or whatever you have configured in config.h) is sent. For example,
I have mouse support in tmux disabled, so when I switch to copy mode and
use my mouse, scrolling works via ^E / ^Y, but if I open Vim and run
":set mouse=a", scrolling is communicated to Vim as "^[[Ma,8" /
"^[[M`,8".

On Sat, Nov 18, 2017 at 02:22:39PM +0800, Amos Bird wrote:
> Thanks! But why does scrolling work in tmux then?

Can you use the mouse if you run EMACS without running it inside of
tmux? If not, have you configured EMACS to use the mouse i.e.
https://stackoverflow.com/questions/18198387/ ?

Eric

Re: [dev] [st] Emojis

[Eric Pruitt]

On Sun, Sep 17, 2017 at 07:01:58PM -0400, Gary Allen Vollink wrote:
> I noted in a previous thread [
> https://lists.suckless.org/dev/1709/32306.html ] that wcwidth was
> recently fixed/updated in Linux's glibc: [
> https://lists.gnu.org/archive/html/info-gnu/2017-08/msg0.html ].
> Ultimately, this (and recompiling everything that links it statically)
> is the RIGHT way to fix all of these issues.

I decided to tackle my own character width problems again and finally
got them sorted out thanks in part to this message. The solution for me
was a bit different: I statically compile various command line tools
that I commonly use -- GNU Awk, tmux and Bash to name a few -- using
musl. Since st depends on X11, I always build it dynamically using my
Linux distro's default libc which is always GNU libc. As far as I can
tell, musl's wcwidth(3) hasn't been updated in a very long time. I
gutted the original implementation and made it a thin wrapper around
utf8proc (https://github.com/JuliaLang/utf8proc). Here is the
corresponding code in my Makefile that does this:

(cd $(UTF8PROC) && cpp -P -E utf8proc.c) > $(MUSL)/src/ctype/wcwidth.c
printf '%s\n' >> $(MUSL)/src/ctype/wcwidth.c \
'#include ' \
'int wcwidth(wchar_t wc)' \
'{' \
'return utf8proc_charwidth((utf8proc_int32_t) wc);' \
'}'

The utf8proc_charwidth function returns 0 in cases where wcwidth(3)
would return -1, but this has not been a problem for me in practice
because all of the text I care about is well-formed UTF8.

Eric

[dev] Re: [st] Unable to map Ctrl+$NUMBER

[Eric Pruitt]

On Tue, Oct 10, 2017 at 10:01:32PM -0700, Eric Pruitt wrote:
> I dug into this some more, and this code is what's causing the shortcuts
> to be ignored:
>
> if (i == LEN(mappedkeys)) {
> if ((k & 0x) < 0xFD00)
> return NULL;
> }
>
> For whatever reason, kmap is written so that anything that falls below
> 0xFD00 will never make it to the for loop that looks up mappings in the
> "key" array. I'm not providing a patch because I don't know what the
> rationale behind this decision was, and my personal copy of st is very
> out of sync with the upstream repo.

Actually, I just figured this out -- the comment for mappedkeys explains
this, but if you haven't read the comments in keysymdef.h
(https://cgit.freedesktop.org/xorg/proto/x11proto/plain/keysymdef.h), I
think it's not obvious what it means. It reads "If you want keys other
than the X11 function keys [...]." In this context, "function keys" does
NOT refer to F1, F2, F3, etc. or functions in the shortcuts array. The
solution to this was to simply add the number keys to mappedkeys:

static KeySym mappedkeys[] = { XK_1, XK_2, XK_3, XK_4 };

Eric

[dev] Re: [st] Unable to map Ctrl+$NUMBER

[Eric Pruitt]

On Mon, Oct 09, 2017 at 10:32:02AM -0700, Eric Pruitt wrote:
> When I press Ctrl+1 after making that change, the iso14755 function is
> executed as expected. I looked at the code that's responsible for
> handling key presses in both arrays, but it's not clear to me exactly
> what the problem is.

I dug into this some more, and this code is what's causing the shortcuts
to be ignored:

if (i == LEN(mappedkeys)) {
if ((k & 0x) < 0xFD00)
return NULL;
}

For whatever reason, kmap is written so that anything that falls below
0xFD00 will never make it to the for loop that looks up mappings in the
"key" array. I'm not providing a patch because I don't know what the
rationale behind this decision was, and my personal copy of st is very
out of sync with the upstream repo.

Eric

[dev] [st] Unable to map Ctrl+$NUMBER

[Eric Pruitt]

I would like to create custom mappings for pressing Control with a
digit. I added this binding for Ctrl+1 to the top of the "key" array:

/* keysmmaskstring appkey   appcursorcrlf */
{  XK_1,ControlMask,"\033OP",   0,  0,  0 },

When I press Ctrl+1, a "1" is printed instead of the escape sequence. I
added a similar mapping to the "shortcuts" array:

/* mask maskstring  argument */
{  ControlMask, ControlMask,iso14755,   {.i = 0} }

When I press Ctrl+1 after making that change, the iso14755 function is
executed as expected. I looked at the code that's responsible for
handling key presses in both arrays, but it's not clear to me exactly
what the problem is. Is there something wrong with the way I'm trying to
map Ctrl+1 or is this a bug of some sort?

Thanks,
Eric

Re: [dev] [st] Start with text already input

[Eric Pruitt]

On Fri, Sep 15, 2017 at 09:41:32PM +0200, Hadrien Lacour wrote:
> I basically wanted a way to open a terminal with the beginning of a
> command ("pass -c " in my case) already typed.
>
> I finally settled for the dmenu integration, but this still could be
> useful. I'll probably have better chance with xdotool.

The only method I'm aware of for pushing characters to a terminal
requires using ioctl, and I think (but am not certain) this only works
if the process in question is the session leader. In C, this looks like
"ioctl(tty, TIOCSTI, data)" where "tty" is a file descriptor for the
terminal. Maybe you could create a wrapper program that uses ioctl to
push bytes into the input buffer then spawns a shell.

Eric

Re: [dev] [st] macOS: Wide Asian Glyphs

[Eric Pruitt]

On Thu, Sep 14, 2017 at 01:51:26PM -0700, Eric Pruitt wrote:
> On Thu, Sep 14, 2017 at 12:01:42PM -0400, Gary Allen Vollink wrote:
> > 3) I'm not proud of this, but it works reliably.  I wrote a nasty hack
> > that force-fixes the width/overlap problem with Emoji (and some other
> > odd font-substitution problems).  I know that this is 'fixed' in
> > glibc's most recent release - following UNICODE recent guidance that
> > all Emoji are double-width, but it isn't fixed on macOS (Emoji without
> > spaces don't even work right in Terminal.app).  Anyway, it is
> > something I could throw together as a diff - sub 40 lines.  I don't
> > have a handle on what the protocol is for sharing such a thing.
>
> Make a patch. Attach the patch to an email or submit it to the wiki
> (https://git.suckless.org/sites/tree/st.suckless.org/patches).
> Instructions for submitting patches are provided on
> https://suckless.org/hacking.

Also, please post the patch to the mailing list either way. Even if it
doesn't get accepted into mainline or the wiki, I would like to see it
since I've had some problems with emoji width on Linux that I haven't
spent time investigating yet.

Eric

Re: [dev] [st] macOS: Wide Asian Glyphs

[Eric Pruitt]

On Thu, Sep 14, 2017 at 12:01:42PM -0400, Gary Allen Vollink wrote:
> 3) I'm not proud of this, but it works reliably.  I wrote a nasty hack
> that force-fixes the width/overlap problem with Emoji (and some other
> odd font-substitution problems).  I know that this is 'fixed' in
> glibc's most recent release - following UNICODE recent guidance that
> all Emoji are double-width, but it isn't fixed on macOS (Emoji without
> spaces don't even work right in Terminal.app).  Anyway, it is
> something I could throw together as a diff - sub 40 lines.  I don't
> have a handle on what the protocol is for sharing such a thing.

Make a patch. Attach the patch to an email or submit it to the wiki
(https://git.suckless.org/sites/tree/st.suckless.org/patches).
Instructions for submitting patches are provided on
https://suckless.org/hacking.

Eric

Re: [dev] [st] font fallback

[Eric Pruitt]

On Sun, Sep 03, 2017 at 06:31:44PM +0200, Hadrien Lacour wrote:
> I see, thanks. Don't know why I thought it was like this. Well, I'll try it
> but fontconfig is indeed a big pain in the ass (editing XML is never fun).

If you don't mind running an older revision of st (or porting my changes
to a newer release), you can use my patch:
https://github.com/ericpruitt/edge/blob/master/patches/st-00-font-array-support.diff

Eric

Re: [dev] less(1) replacement?

[Eric Pruitt]

On Fri, Aug 25, 2017 at 07:37:56PM +, fao_ wrote:
> > 9base is not intended for interactive use, so no, p does not really
> > belong into 9base. 9base is intended to be a scripting environment.
>
> Excuse me if this is a stupid question, but: What's the difference?

Interactive: things that use ncurses, terminfo, termcap, etc.

Scripting: programs like sed, ed, awk, grep, etc. These programs are
often used in the context of larger tasks with pipes for transforming /
processing data.

Eric

Re: [dev] [st] Larger HISTSIZE consumes huge memory

[Eric Pruitt]

On Wed, Jun 21, 2017 at 07:39:07PM +0600, Techno Implant wrote:
> So my question is if there's a patch that can make st handle
> scrollback lines dynamically rather than preallocate.
>
> And also will there be any daemon mode available for st?

You could use tmux. It dynamically allocates memory for the scrollback
buffer, and using tmux would also give you something akin to daemon
mode. You also wouldn't have to worry about waiting for someone to
update the st history patch after st has been modified.

Eric

Re: [dev] [slock] [PATCH] Add option to show the password on the screen

[Eric Pruitt]

On Sat, Apr 01, 2017 at 02:49:47PM +0530, Aditya Goturu wrote:
> Actually, I have a better suggestion. Rather than burdening the user
> with things like passwords, we must make it such that it will simply
> allow the user to unlock as soon as the enter key is pressed. Perhaps we
> should integrate with Microsoft Active Directory to allow this.

This feature was previously implemented for Linux systems using certain
types of authentication schemes, but unfortunately, it was removed last
August:

- http://www.openwall.com/lists/oss-security/2016/08/18/22
- 
http://git.suckless.org/slock/commit/?id=d8bec0f6fdc8a246d78cb488a0068954b46fcb29

Eric

Re: [dev] [Announce] Desktop Entry Launcher

[Eric Pruitt]

On Sat, Feb 11, 2017 at 02:03:18PM +0100, Jan Christoph Ebersbach wrote:
> The one thing I noticed is that I couldn't get del to work at first
> because it was messing the .del file in $HOME.
>
> del: open: /home/jceb/.del: No such file or directory
> del: dmenu died with exit status 1
>
> It took a while until I figured out that "del -r" would create the
> missing file.

I'm glad you found it useful. I just pushed an update to the program to
make it clear what needs to be done when running del for the first time:

@@ -428,7 +428,8 @@ static void usage(const char *self)
 "\n"
 "DEL searches for Freedesktop Desktop Entries, generates a list of 
"
 "graphical\ncommands and uses dmenu as a front-end so the user can 
"
-"select a command to\nexecute.\n"
+"select a command to\nexecute. The first time DEL is executed, it "
+"should be invoked as \"del -r\" to\ngenerate the application 
list.\n"
 "\n"
 "Exit statuses:\n"
 "  1Fatal error encountered.\n"
@@ -622,7 +623,11 @@ static int menu(const char *menu_list_path, char 
**argv)
 } else if (close(STDIN_FILENO) && errno != EBADF) {
 perror("del: could not close stdin");
 } else if (open(menu_list_path, O_RDONLY) < 0) {
-verror("del: open: %s", menu_list_path);
+if (errno == ENOENT) {
+fmterr("del: %s missing; was \"del -r\" run?", 
menu_list_path);
+} else {
+verror("del: open: %s", menu_list_path);
+}
 } else {
 execvp(argv[0], argv);
 verror("del: %s", argv[0]);

Eric


signature.asc
Description: Digital signature

[dev] [Announce] Desktop Entry Launcher

[Eric Pruitt]

I use dmenu to run programs, but I did not like that dmenu_run included
every single program included those without GUIs. I maintained a list of
programs manually, then I wrote a script to generate the list based on
whether or not a binary linked to GUI libraries. Recently, I wrote a C
program that uses nftw(3) to find [desktop entry files][1], parses them
and adds them to a list saved at ~/.del by default. The source is here:
https://github.com/ericpruitt/edge/blob/master/utilities/del.c . I
believe it is POSIX compliant, and I was able to compile it on Linux,
OpenBSD and FreeBSD.

  [1]: https://specifications.freedesktop.org/desktop-entry-spec/latest/

Here's the usage information:

DEL searches for Freedesktop Desktop Entries, generates a list of graphical
commands and uses dmenu as a front-end so the user can select a command to
execute.

Exit statuses:
  1Fatal error encountered.
  2Non-fatal error encountered.
  > 128The dmenu subprocess was killed by a signal.

Options:
  -h   Show this text and exit.
  -f PATH  Use specified file as the command list. When this is
   unspecified, it defaults to ~/.del
  -r   Search for desktop entries to refresh the command list.
   Trailing command line parameters are interpreted as
   folders to be searched. Folders on different devices
   must be explicitly enumerated because the search will
   not automatically cross filesystem boundaries; in terms
   of find(1), the search is equivalent to the following:
   find $ARGUMENTS -xdev -name '*.desktop'
   When no paths are given, "/" is searched by default.
   A newline-separated list of programs can be fed to del
   via stdin to include programs that do not have desktop
   entries in the generated launcher list. The programs
   must exist in $PATH or they will be silently ignored.

When "-r" is not specified, dmenu is launched with the command list feed
into standard input. Trailing command line arguments can be used to pass
flags to dmenu or use a different menu altogether:

  Set the background color of selected text to red:
  $ del -- -sb "#ff"

  Use rofi in dmenu mode instead of dmenu:
  $ del rofi -dmenu

Please let me know what you think.

Thanks,
Eric

Re: [dev] [st] keep some glyph modes for the cursor

[Eric Pruitt]

On Mon, Feb 06, 2017 at 12:48:45PM -0600, LaFreniere, Joseph wrote:
> May I ask why the patch was included in the message body as opposed to an
> attachment?  I am unfamiliar to mailing list conventions, but it seems that
> a discrete file would be more easily managed.

>From http://suckless.org/community:

> When sending a patch use the following commands:
>
> cd $project
> git send-email --subject-prefix="$(basename $(pwd))][PATCH" \
> --to hack...@suckless.org -1
>
> This will send the last commit of the repository to the mailinglist
> adding a prefix to the subject which includes the appropriate project
> name. This allows easier referencing and filtering of the e-mails for
>  the maintainers subscribed to hackers@.

There have been discussions about the preferred patch format, but there
were lots of differing opinions, and people still often use attachments
despite what the community documentation requests.

Eric

Re: [dev] [st/dwm] Alt-Shift-C and Mod1-Shift-C

[Eric Pruitt]

On Thu, Jan 12, 2017 at 07:25:06PM +0100, Patrick Bucher wrote:
> I'm using st and dwm at the same time, and today I discovered a little problem
> when using the default config of both programs. st uses Alt-Shift-C to copy 
> text
> into the clipboard, dwm uses Mod1-Shift-C for closing the selected window,
> whereas Mod1 is Alt by default, at least on my machine. (Maybe some of you use
> Super_L, vulgo "the Windows key".)

I use Caps Lock as my window manager key since I don't have any other
use for it:

xmodmap -e "remove mod4 = Hyper_L" \
-e "remove Lock = Caps_Lock" \
-e "keysym Caps_Lock = Hyper_L" \
-e "add mod3 = Hyper_L"

I know a lot of Vimmers like to map caps to escape, but I use "qq"
instead of escape.

Eric

[dev] Re: [st] [PATCH] Make missing attribute fallback color optional

[Eric Pruitt]

On Wed, Dec 14, 2016 at 07:53:57PM -0800, Eric Pruitt wrote:
>  config.def.h | 2 +-
>  st.c | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)

I re-sent this to the correct list, hackers@.

Eric

[dev] [st] [PATCH] Make missing attribute fallback color optional

[Eric Pruitt]

I wasted an hour trying to figure out why st on different hosts using
the exact same terminfo configuration and statically compiled tmux was
displaying some text in yellow. The hosts where this produced yellow
text were using an Ubuntu-based Linux distro while the hosts where st
continued to work as it always had were using Debian 8. I didn't dig
into the problem too much after I narrowed down the problem to a
specific commit, so I don't know which attributes st was unable to find.
However, the output rendered on the hosts that st's font selection
thought had incorrect attributes is almost a pixel perfect match for the
hosts where st was able to find a font that was an exact match which
makes this fallback color a false-positive for all practical intents. I
have modified st to make the fallback coloring optional because I'm sure
this is going to surprise someone else in the future, too.
---
 config.def.h | 2 +-
 st.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git config.def.h config.def.h
index 32d107d..2e29064 100644
--- config.def.h
+++ config.def.h
@@ -139,7 +139,7 @@ static unsigned int mousebg = 0;
 
 /*
  * Color used to display font attributes when fontconfig selected a font which
- * doesn't match the ones requested.
+ * doesn't match the ones requested. Set this to 0 to disable this feature.
  */
 static unsigned int defaultattr = 11;
 
diff --git st.c st.c
index d6fe58a..2ee04fa 100644
--- st.c
+++ st.c
@@ -3824,10 +3824,10 @@ xdrawglyphfontspecs(const XftGlyphFontSpec *specs, 
Glyph base, int len, int x, i
 
/* Fallback on color display for attributes not supported by the font */
if (base.mode & ATTR_ITALIC && base.mode & ATTR_BOLD) {
-   if (dc.ibfont.badslant || dc.ibfont.badweight)
+   if (defaultattr && (dc.ibfont.badslant || dc.ibfont.badweight))
base.fg = defaultattr;
-   } else if ((base.mode & ATTR_ITALIC && dc.ifont.badslant) ||
-   (base.mode & ATTR_BOLD && dc.bfont.badweight)) {
+   } else if (defaultattr && ((base.mode & ATTR_ITALIC && 
dc.ifont.badslant) ||
+   (base.mode & ATTR_BOLD && dc.bfont.badweight))) {
base.fg = defaultattr;
}
 
-- 
2.1.4

Re: [dev] [announce] wjt-0.1 - slider widget

[Eric Pruitt]

On Tue, Dec 13, 2016 at 08:18:14AM -0600, Ian Remmler wrote:
> There's not much to see, really.  I don't think a picture tells enough
> to justify adding to the repo.

It's a **G**UI widget. How it looks and works is 99% of what matters.
Can someone that's compiled and run the code please post a screenshot to
this list?

Eric

Re: [dev] dwm systray diff for 6.1 fails.

[Eric Pruitt]

On Wed, Sep 21, 2016 at 05:48:51PM +0100, Nick Warne wrote:
> Was going to use this to monitor battery, but HUNK #10 fails - looking
> at the patch and dwm.c, the code is totally different at around line
> 664:

Are you using the tagged 6.1 release or 6.1/HEAD? My version of the
patch applies cleanly against the current dwm HEAD:
https://github.com/ericpruitt/edge/blob/master/patches/dwm-00-systray.diff

Eric

Re: [dev] [st] bitmap font and chscale 1< line drawing bug

[Eric Pruitt]

On Wed, Sep 07, 2016 at 11:36:47PM -0700, le...@bitmessage.ch wrote:
> On Wed, Sep 07, 2016 at 09:39:08PM -0700, Eric Pruitt wrote:
> > Even if you don't debug and / or fix the problem, at least post the
> > offending commit, and I will take a look.
>
> I was able to fix it the problem by rolling back part of commit
> 528241aa3835e2f1f052abeeaf891737712955a0
> and all of
> 0e48a1995eee1c2babc58523ef0be296e4b1c3e8

I don't know enough about FontCofig and related things to comment with
any certainty, but this looks like one of those situations where a bug
(or less-than-ideal implementation of a feature) resulted in desirable
behavior. Hopefully someone more knowledgeably will chime in.

Eric

Re: [dev] [st] bitmap font and chscale 1< line drawing bug

[Eric Pruitt]

On Wed, Sep 07, 2016 at 09:20:39PM -0700, le...@bitmessage.ch wrote:
> This did not happen in st-0.6. Okay I'll check out git-bisect and see if
> I can figure it out. I'll submit a patch or pull request if I find a
> solution. Thanks.

Even if you don't debug and / or fix the problem, at least post the
offending commit, and I will take a look.

Eric

Re: [dev] [st] bitmap font and chscale 1< line drawing bug

[Eric Pruitt]

On Wed, Sep 07, 2016 at 06:01:48PM -0700, Eric Pruitt wrote:
> On Wed, Sep 07, 2016 at 05:51:49PM -0700, le...@bitmessage.ch wrote:
> > After moving to st-0.7, I am experiencing a bug with line drawing. When
> > using a bitmap font (eg terminus) and a chscale=1.2 in config.h, every
> > vertical line has gaps in it (ex tree or tmux). This persists for different
> > bitmap fonts
> > but goes away when chscale is set to 1.0.
>
> Did this not happen before st-0.7? I implemented the ch* factors in a
> simple way just to control the invisible bounding boxes for each
> character, and they don't scale the font itself; the behavior you're
> seeing is working as intended, and it's also what I observed when I was
> testing the feature and experimented with different scaling factors. I
> have noticed that on some operating systems, even using the exact same
> st compile options and fonts, I get slightly different results -- on my
> work computer, there are 1-pixel gaps between vertical lines (not pipe
> but "│"), but at home, the gaps aren't there. I don't find this annoying
> enough to invest any effort into figuring out why that happens despite
> both computers being Debian-based.

Also, if this doesn't happen in earlier versions, you could use
git-bisect (https://git-scm.com/docs/git-bisect) to figure out which
commit introduced the problem.

Eric

Re: [dev] [st] bitmap font and chscale 1< line drawing bug

[Eric Pruitt]

On Wed, Sep 07, 2016 at 05:51:49PM -0700, le...@bitmessage.ch wrote:
> After moving to st-0.7, I am experiencing a bug with line drawing. When
> using a bitmap font (eg terminus) and a chscale=1.2 in config.h, every
> vertical line has gaps in it (ex tree or tmux). This persists for different 
> bitmap fonts
> but goes away when chscale is set to 1.0.

Did this not happen before st-0.7? I implemented the ch* factors in a
simple way just to control the invisible bounding boxes for each
character, and they don't scale the font itself; the behavior you're
seeing is working as intended, and it's also what I observed when I was
testing the feature and experimented with different scaling factors. I
have noticed that on some operating systems, even using the exact same
st compile options and fonts, I get slightly different results -- on my
work computer, there are 1-pixel gaps between vertical lines (not pipe
but "│"), but at home, the gaps aren't there. I don't find this annoying
enough to invest any effort into figuring out why that happens despite
both computers being Debian-based.

Eric

Re: [dev] [PATCH] [slock] React to key release rather than key press events

[Eric Pruitt]

On Thu, Jan 28, 2016 at 07:20:12PM +1300, David Phillips wrote:
> That behaviour is unwanted if the first key in a password is 'shift'.
> The new behaviour will still turn slock to the failure colour if the
> shift key
> is pressed, but only once it is released and the buffer is still
> clear.

I wrote a variant of the patch which is attached. It works well with
"failonclear = 1", and I think it addresses the problems mentioned in
this thread. It modifies slock so modifier keys that are depressed
without a complementary key only cause the screen to show the failure
color once they're released, and it only does that after at least one
key is pressed after launching slock; if you have slock mapped to, say,
Ctrl+Shift+L, it won't turn $FAILURE_COLOR when you take you lift your
hands off the keyboard. To hopefully clarify, here are a few examples:

A:
1. Shift pressed down
2. Shift released
3. Screen turns $FAILURE_COLOR

B:
1. Shift pressed down
2. "a" pressed down while Shift is still down
3. "a" and Shift are released
4. Screen turns $TYPING_IN_PROGRESS_COLOR

C:
1. Screen is unlocked
2. User presses Ctrl+Shift+L to lock screen
3. slock shows $NO_ACTIVITY_COLOR.
4. User removes hand from keyboard.
5. slock color does **not** change

Eric
diff --git slock.c slock.c
index a00fbb9..f24fd21 100644
--- slock.c
+++ slock.c
@@ -127,6 +127,7 @@ readpw(Display *dpy, const char *pws)
 	KeySym ksym;
 	XEvent ev;
 	static int oldc = INIT;
+	int seenkeypress = 0;
 
 	len = 0;
 	running = True;
@@ -136,9 +137,14 @@ readpw(Display *dpy, const char *pws)
 	 * utility. This way the user can easily set a customized DPMS
 	 * timeout. */
 	while (running && !XNextEvent(dpy, )) {
-		if (ev.type == KeyPress) {
+		if (ev.type == KeyPress || ev.type == KeyRelease) {
 			explicit_bzero(, sizeof(buf));
 			num = XLookupString(, buf, sizeof(buf), , 0);
+			seenkeypress |= ev.type == KeyPress;
+			if ((ev.type == KeyRelease && (num || !seenkeypress)) ||
+			(ev.type == KeyPress && !num)) {
+continue;
+			}
 			if (IsKeypadKey(ksym)) {
 if (ksym == XK_KP_Enter)
 	ksym = XK_Return;

Re: [dev] [st] [PATCH] Converted "font" string to "fonts" array

[Eric Pruitt]

On Mon, Aug 15, 2016 at 03:59:40AM +0300, Amer wrote:
> I don't understand at all how you can apply this embedded-into-body
> patch with all tabs replaced by spaces and lines wrapped on 80.
> What magic I need for this?

It was unintentional. Normally, I send patches to the list as
attachments, but I decided to send it inline this time around because it
was mentioned as the preferred method on one of the suckless.org pages.
I didn't notice the text wrapping had been changed.

Eric

Re: [dev] neatroff

[Eric Pruitt]

On Tue, Aug 09, 2016 at 06:56:35PM -0700, Eli Cohen wrote:
> I'm trying to get neatroff compiled in a stali fashion. I've run into
> a slight impasse regarding licensing.  for typesetting, neatroff uses
> ghostscript fonts, which are gpl. (really my goal with all this is
> just to display man pages)

How is this an "impasse?" If you're just compiling it for yourself, I
don't see why licensing matters.

Eric

[dev] [st] [PATCH] Converted "font" string to "fonts" array

[Eric Pruitt]

Modifies st to support user-defined fallback fonts specified in an
array. This change also resolves an issue where fallback fonts were used
in place of default fonts in an inconsistent manner which caused
identical sets of text to sometimes use different fonts.
---
 config.def.h |  15 +---
 st.c | 120 ++-
 2 files changed, 87 insertions(+), 48 deletions(-)

diff --git a/config.def.h b/config.def.h
index b41747f..638c3c5 100644
--- a/config.def.h
+++ b/config.def.h
@@ -1,11 +1,16 @@
 /* See LICENSE file for copyright and license details. */

-/*
- * appearance
- *
- * font: see http://freedesktop.org/software/fontconfig/fontconfig-user.html
+/**
+ * Array of the primary font and fallback fonts. The first string in the array
+ * is the primary font while the rest of the fonts will be used as fallbacks
+ * when preceding fonts are missing a specific glyph. See
+ * http://freedesktop.org/software/fontconfig/fontconfig-user.html for more
+ * info on font definitions.
  */
-static char font[] = "Liberation 
Mono:pixelsize=12:antialias=true:autohint=true";
+static char *fonts[] = {
+   "Liberation Mono:pixelsize=12:antialias=true:autohint=true",
+};
+
 static int borderpx = 2;

 /*
diff --git a/st.c b/st.c
index 2594c65..f7973bd 100644
--- a/st.c
+++ b/st.c
@@ -353,10 +353,17 @@ typedef struct {
FcPattern *pattern;
 } Font;

+typedef struct {
+   Font font;
+   Font bfont;
+   Font ifont;
+   Font ibfont;
+} FontFamily;
+
 /* Drawing Context */
 typedef struct {
Color col[MAX(LEN(colorname), 256)];
-   Font font, bfont, ifont, ibfont;
+   FontFamily fontfamily;
GC gc;
 } DC;

@@ -434,7 +441,7 @@ static void xloadcols(void);
 static int xsetcolorname(int, const char *);
 static int xgeommasktogravity(int);
 static int xloadfont(Font *, FcPattern *);
-static void xloadfonts(char *, double);
+static void xloadfonts(const char *, double);
 static void xsettitle(char *);
 static void xresettitle(void);
 static void xsetpointermotion(int);
@@ -533,7 +540,7 @@ static char *opt_name  = NULL;
 static char *opt_title = NULL;
 static int oldbutton   = 3; /* button event on startup: 3 = release */

-static char *usedfont = NULL;
+static const char *usedfont = NULL;
 static double usedfontsize = 0;
 static double defaultfontsize = 0;

@@ -542,6 +549,9 @@ static uchar utfmask[UTF_SIZ + 1] = {0xC0, 0x80, 0xE0, 
0xF0, 0xF8};
 static Rune utfmin[UTF_SIZ + 1] = {   0,0,  0x80,  0x800,  0x1};
 static Rune utfmax[UTF_SIZ + 1] = {0x10, 0x7F, 0x7FF, 0x, 0x10};

+static FontFamily fontfamilies[16];
+static int fontfamiliescount = 0;
+
 /* Font Ring Cache */
 enum {
FRC_NORMAL,
@@ -3307,11 +3317,16 @@ xloadfont(Font *f, FcPattern *pattern)
 }

 void
-xloadfonts(char *fontstr, double fontsize)
+xloadfonts(const char *fontstr, double fontsize)
 {
FcPattern *pattern;
double fontval;
float ceilf(float);
+   FontFamily fontfamily;
+
+   if (fontfamiliescount >= LEN(fontfamilies)) {
+   die("Font family array is full.\n");
+   }

if (fontstr[0] == '-') {
pattern = XftXlfdParse(fontstr, False, False);
@@ -3345,37 +3360,43 @@ xloadfonts(char *fontstr, double fontsize)
defaultfontsize = usedfontsize;
}

-   if (xloadfont(, pattern))
+   if (xloadfont(, pattern))
die("st: can't open font %s\n", fontstr);

if (usedfontsize < 0) {
-   FcPatternGetDouble(dc.font.match->pattern,
+   FcPatternGetDouble(fontfamily.font.match->pattern,
   FC_PIXEL_SIZE, 0, );
usedfontsize = fontval;
if (fontsize == 0)
defaultfontsize = fontval;
}

-   /* Setting character width and height. */
-   xw.cw = ceilf(dc.font.width * cwscale);
-   xw.ch = ceilf(dc.font.height * chscale);
-
FcPatternDel(pattern, FC_SLANT);
FcPatternAddInteger(pattern, FC_SLANT, FC_SLANT_ITALIC);
-   if (xloadfont(, pattern))
+   if (xloadfont(, pattern))
die("st: can't open font %s\n", fontstr);

FcPatternDel(pattern, FC_WEIGHT);
FcPatternAddInteger(pattern, FC_WEIGHT, FC_WEIGHT_BOLD);
-   if (xloadfont(, pattern))
+   if (xloadfont(, pattern))
die("st: can't open font %s\n", fontstr);

FcPatternDel(pattern, FC_SLANT);
FcPatternAddInteger(pattern, FC_SLANT, FC_SLANT_ROMAN);
-   if (xloadfont(, pattern))
+   if (xloadfont(, pattern))
die("st: can't open font %s\n", fontstr);

FcPatternDestroy(pattern);
+
+   /* Setting character width and height. */
+   if (!fontfamiliescount) {
+   xw.cw = ceilf(fontfamily.font.width * cwscale);
+   xw.ch = ceilf(fontfamily.font.height * chscale);
+   dc.fontfamily = fontfamily;
+ 

Re: [dev] new pre-patched version of dwm available

[Eric Pruitt]

On Sun, Jul 31, 2016 at 08:26:36AM +0200, Jan Christoph Ebersbach wrote:
> Have you tried to increase patch's fuzz factor with the --fuzz option in
> order to achieve the same result?

I messed tried messing with the fuzzing factor, but I had some patches
apply in wrong place. I am not certain because it's been a while since I
tried this, but I want to say the problem was generally caused by code
that's often repeated e.g. for loops for counting windows or iterating
over monitors. I just ran dwm.c through "sort | uniq -c | sort -n," and
"for (m = mons; m; m = m->next)" appears at least 6 times.

> I never used the rebase model described in the customization section.
> Since you know both ways, why did you switch to patch files?

I've actually tried three approaches: (1) the rebase my own tree onto
the suckless one, (2) patches alongside the dwm source code and my
current approach which is (3) patches completely divorced from the dwm
repository. With the first two approaches, I found dealing with
patch-breaking updates far too tedious especially when patches were
dependent on one another. My config.mk also differed from the suckless
one, so I generally had to review it and manually adjust the
corresponding flags in my file. There are several things I like about
using patches and an external dwm repository, but some this also applies
to (2):

- When dwm gets updated, I can work on one patch at a time in almost any
  order (of my 16 dwm patches, only 2 have dependencies while the
  remaining 14 can be applied with or without the other).

- Because of how my build system works, I can temporarily disable a
  patch by simply renaming it from *.diff to something like *.diff.x
  because the Makfile target only globs for *.diff. I often use vidir
  (https://joeyh.name/code/moreutils/) to do this with multiple patches.

- Similarly, if I want to discard a patch because I don't use it or the
  functionality has been accepted upstream, I don't have to use "git
  revert" and hunt for all changes related to a specific feature and
  hope there are no dependency issues. Instead, I just "git rm" the diff
  file and call it a day.

Eric


signature.asc
Description: Digital signature

[dev] Re: [st] [PATCH] Converted "font" string to "fonts" array

[Eric Pruitt]

On Sun, Jul 31, 2016 at 03:01:24PM -0700, Eric Pruitt wrote:
> -static char font[] = "Liberation 
> Mono:pixelsize=12:antialias=true:autohint=true";
> +static char *fonts[] = {
> +"Liberation Mono:pixelsize=12:antialias=true:autohint=true",
> +};

I used tabs when editing st.c, but I just noticed I accidentally used
spaces when I changed config.def.h. It's only one line, and I don't
think it's worth creating another thread, but if aren't willing to edit
the patch to fix that, let me know.

Eric

[dev] [st] [PATCH] Converted "font" string to "fonts" array

[Eric Pruitt]

Modifies st to support user-defined fallback fonts specified in an
array. This change also resolves an issue where fallback fonts were used
in place of default fonts in an inconsistent manner which caused
identical sets of text to sometimes use different fonts.
---
 config.def.h |  15 +---
 st.c | 120 ++-
 2 files changed, 87 insertions(+), 48 deletions(-)

diff --git a/config.def.h b/config.def.h
index b41747f..2febe40 100644
--- a/config.def.h
+++ b/config.def.h
@@ -1,11 +1,16 @@
 /* See LICENSE file for copyright and license details. */

-/*
- * appearance
- *
- * font: see http://freedesktop.org/software/fontconfig/fontconfig-user.html
+/**
+ * Array of the primary font and fallback fonts. The first string in the array
+ * is the primary font while the rest of the fonts will be used as fallbacks
+ * when preceding fonts are missing a specific glyph. See
+ * http://freedesktop.org/software/fontconfig/fontconfig-user.html for more
+ * info on font definitions.
  */
-static char font[] = "Liberation 
Mono:pixelsize=12:antialias=true:autohint=true";
+static char *fonts[] = {
+"Liberation Mono:pixelsize=12:antialias=true:autohint=true",
+};
+
 static int borderpx = 2;

 /*
diff --git a/st.c b/st.c
index 2594c65..f7973bd 100644
--- a/st.c
+++ b/st.c
@@ -353,10 +353,17 @@ typedef struct {
FcPattern *pattern;
 } Font;

+typedef struct {
+   Font font;
+   Font bfont;
+   Font ifont;
+   Font ibfont;
+} FontFamily;
+
 /* Drawing Context */
 typedef struct {
Color col[MAX(LEN(colorname), 256)];
-   Font font, bfont, ifont, ibfont;
+   FontFamily fontfamily;
GC gc;
 } DC;

@@ -434,7 +441,7 @@ static void xloadcols(void);
 static int xsetcolorname(int, const char *);
 static int xgeommasktogravity(int);
 static int xloadfont(Font *, FcPattern *);
-static void xloadfonts(char *, double);
+static void xloadfonts(const char *, double);
 static void xsettitle(char *);
 static void xresettitle(void);
 static void xsetpointermotion(int);
@@ -533,7 +540,7 @@ static char *opt_name  = NULL;
 static char *opt_title = NULL;
 static int oldbutton   = 3; /* button event on startup: 3 = release */

-static char *usedfont = NULL;
+static const char *usedfont = NULL;
 static double usedfontsize = 0;
 static double defaultfontsize = 0;

@@ -542,6 +549,9 @@ static uchar utfmask[UTF_SIZ + 1] = {0xC0, 0x80, 0xE0, 
0xF0, 0xF8};
 static Rune utfmin[UTF_SIZ + 1] = {   0,0,  0x80,  0x800,  0x1};
 static Rune utfmax[UTF_SIZ + 1] = {0x10, 0x7F, 0x7FF, 0x, 0x10};

+static FontFamily fontfamilies[16];
+static int fontfamiliescount = 0;
+
 /* Font Ring Cache */
 enum {
FRC_NORMAL,
@@ -3307,11 +3317,16 @@ xloadfont(Font *f, FcPattern *pattern)
 }

 void
-xloadfonts(char *fontstr, double fontsize)
+xloadfonts(const char *fontstr, double fontsize)
 {
FcPattern *pattern;
double fontval;
float ceilf(float);
+   FontFamily fontfamily;
+
+   if (fontfamiliescount >= LEN(fontfamilies)) {
+   die("Font family array is full.\n");
+   }

if (fontstr[0] == '-') {
pattern = XftXlfdParse(fontstr, False, False);
@@ -3345,37 +3360,43 @@ xloadfonts(char *fontstr, double fontsize)
defaultfontsize = usedfontsize;
}

-   if (xloadfont(, pattern))
+   if (xloadfont(, pattern))
die("st: can't open font %s\n", fontstr);

if (usedfontsize < 0) {
-   FcPatternGetDouble(dc.font.match->pattern,
+   FcPatternGetDouble(fontfamily.font.match->pattern,
   FC_PIXEL_SIZE, 0, );
usedfontsize = fontval;
if (fontsize == 0)
defaultfontsize = fontval;
}

-   /* Setting character width and height. */
-   xw.cw = ceilf(dc.font.width * cwscale);
-   xw.ch = ceilf(dc.font.height * chscale);
-
FcPatternDel(pattern, FC_SLANT);
FcPatternAddInteger(pattern, FC_SLANT, FC_SLANT_ITALIC);
-   if (xloadfont(, pattern))
+   if (xloadfont(, pattern))
die("st: can't open font %s\n", fontstr);

FcPatternDel(pattern, FC_WEIGHT);
FcPatternAddInteger(pattern, FC_WEIGHT, FC_WEIGHT_BOLD);
-   if (xloadfont(, pattern))
+   if (xloadfont(, pattern))
die("st: can't open font %s\n", fontstr);

FcPatternDel(pattern, FC_SLANT);
FcPatternAddInteger(pattern, FC_SLANT, FC_SLANT_ROMAN);
-   if (xloadfont(, pattern))
+   if (xloadfont(, pattern))
die("st: can't open font %s\n", fontstr);

FcPatternDestroy(pattern);
+
+   /* Setting character width and height. */
+   if (!fontfamiliescount) {
+   xw.cw = ceilf(fontfamily.font.width * cwscale);
+   xw.ch = ceilf(fontfamily.font.height * chscale);
+   dc.fontfamily = fontfamily;
+

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Tue, Jul 26, 2016 at 06:16:15PM +0200, Kajetan Jasztal wrote:
> Hash masking [0] password gives you more insight in mistakes you made
> while you are typing since you can remember sequence of changing
> hashes while you type and correct them on the fly. 

I've seen that before, and although I think it's a neat idea, I feel
like it's way too leaky to use in public.

Eric

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Tue, Jul 26, 2016 at 06:09:18PM +0200, Jan Christoph Ebersbach wrote:
> If dmenu could easily be used as a replacement for pinentry my desktop
> would suck a little less.  I'm not aware of many other use cases for
> entering passwords.  Is that possible with your patch?

The pinentry programs for GPG do more than pipe passwords. This patch
could probably be used to create a pinentry program or script that uses
dmenu, but I'm not sure exactly how to do that off the top of my head.
If you just want to use dmenu to enter passphrases and you have control
over how gpg is invoked (i.e. you're not using an inflexible front-end),
you could use "--passphrase-fd 0".

Eric


signature.asc
Description: Digital signature

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Mon, Jul 25, 2016 at 11:33:18PM +0200, FRIGN wrote:
> my suggestion prints as many asterisks as there are runes. try it
> out! :D

I see; I misread "curpos" as "cursor" when I glanced over it the first
time. However, it still looks wrong to me, so I tested it to verify -- I
believe the problem is that the characters aren't guaranteed to have a
width of 8 or even be constant for every character, so if you type (or
paste) something like "Blah blah Բարի գալուստ Վիքիպեդիա Blah Blah", the
cursor position and the number of asterisks is not properly
synchronized.

Eric

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Mon, Jul 25, 2016 at 11:10:26PM +0200, FRIGN wrote:
> I looked more closely at the patch and I've found potential to simplify
> it. Why not go with a [...]

Personally, I like having the asterisks reflect the actual number of
runes typed and think the cosmetics are worth the extra lines. Even if
you're typing Latin characters, I think only getting feedback every 8
key presses kind of defeats the point of having asterisks at all. You
might as well just make the flag not show any text at all which is a
pretty common alternative for Unix password prompts anyway.

In general, I find showing the asterisks useful because if I
accidentally press two keys at once or something, I have the opportunity
to correct it rather than typing something then, hitting Enter and
wondering what I did wrong. On a couple of occasions, I have also had a
key break on my keyboard, and the password prompts I dealt with most
often provided no feedback until after submission. It took me a bit to
finally figure out what was going on, and having visual feedback
would've made my life a little easier.

Perhaps the patch could support a different flag (maybe -g vs -G) for
people that do and do not want asterisks, but that makes the change even
more complex (although negligibly IMO), so I understand you don't like
that idea.

Eric

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Mon, Jul 25, 2016 at 10:21:09PM +0200, FRIGN wrote:
> On Mon, 25 Jul 2016 13:07:23 -0700
> Eric Pruitt <eric.pru...@gmail.com> wrote:
>
> > Again, no one is saying passwords should be sent via the command line.
> > Look at the patch. It uses stdout just like vanialla dmenu.
>
> Ah I see, thanks for clearing up that part. Now, what do the other
> people think about it?

If you put as much effort into looking at the patch as you did being
hostile, it would've been clear a lot sooner.

Eric

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Mon, Jul 25, 2016 at 11:14:28PM -1100, mikan wrote:
> I was working on a similar thing but decided that password entry doesn't make
> sense in dmenu context (since it's a menu!) and made a separate tool instead
> and glue pinentry code to it.

I don't agree with this sentiment -- dmenu happily supports arbitrary
text entry when the thing you want to enter isn't in the list of
presented items. I already use dmenu, so I would much rather maintain my
~40 line patch than introduce a new tool to my workflow that may
eventually diverge from dmenu in ways I consider undesirable or be
abandoned by its sole maintainer.

Eric

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Mon, Jul 25, 2016 at 01:10:01PM -0700, Eric Pruitt wrote:
> On Mon, Jul 25, 2016 at 10:06:47PM +0200, FRIGN wrote:
> > I really would like to see if "example" actually exists. Does it
> > really make sense to do that and is it even safe?
>
> Off the top of my head. both GPG and luks accept passwords and keyfiles
> via arbitrary files which can be regular files or pipes.

Just remembered another -- sudo will accept passwords from a pipe using
-S or --stdin.

Eric

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Mon, Jul 25, 2016 at 10:06:47PM +0200, FRIGN wrote:
> I really would like to see if "example" actually exists. Does it
> really make sense to do that and is it even safe?

Off the top of my head. both GPG and luks accept passwords and keyfiles
via arbitrary files which can be regular files or pipes.

Define "safe."

Eric

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Mon, Jul 25, 2016 at 10:03:34PM +0200, FRIGN wrote:
> So you pass passwords on the command line? Again, an example is really
> overdue.

I have no clue what you're talking about. What makes you think I'm
sending passwords over the command line? Dmenu sends the selection to
stdout, not argv, and many applications will gladly accept passwords via
stdin or arbitrary file descriptor; GPG, for example, allows you to
specify your own password entry application.

> In the end, with this talk, you only humour yourself. And give a bloody
> answer to my question already. I want to see a real example, a real
> program that actually _exists_ which takes passwords on the command
> line, or an example where you use dmenu to enter passwords in some
> "dynamic" context not observable to me at the moment.

Again, no one is saying passwords should be sent via the command line.
Look at the patch. It uses stdout just like vanialla dmenu.

Eric

Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Mon, Jul 25, 2016 at 09:45:16PM +0200, FRIGN wrote:
> On Mon, 25 Jul 2016 11:39:55 -0700
> > The attached patch adds a "-g" flag to dmenu so it can be used for
> > password entry. Typed text is replaced with asterisks.
>
> Why would you need that? Can you give an example?

There's an example in the description: entering passwords. I don't think
any thing else needs to be said, but I will humor you:

> For me, this doesn't make any bloody sense and gives a false sense of
> security.

"For you?" Maybe you never use a computer in the presence of other
people, but I (like many people) do and occasionally need to respond to
password prompts.

Eric

[dev] Re: [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

On Mon, Jul 25, 2016 at 11:39:55AM -0700, Eric Pruitt wrote:
> The attached patch adds a "-g" flag to dmenu so it can be used for
> password entry. Typed text is replaced with asterisks.

I've attached a slightly revised version of the patch which uses "sizeof
text" instead of BUFSIZ for the length of the asterisk array.

Eric
>From 1f60a9ee7bab3176243a22f3a4037379957b1b99 Mon Sep 17 00:00:00 2001
From: Eric Pruitt <eric.pru...@gmail.com>
Date: Mon, 25 Jul 2016 12:23:49 -0700
Subject: [PATCH] Added option to prompt for passwords

---
 dmenu.1 |  3 +++
 dmenu.c | 42 --
 2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/dmenu.1 b/dmenu.1
index d3ab805..91b5a5b 100644
--- a/dmenu.1
+++ b/dmenu.1
@@ -45,6 +45,9 @@ dmenu appears at the bottom of the screen.
 dmenu grabs the keyboard before reading stdin.  This is faster, but will lock up
 X until stdin reaches end\-of\-file.
 .TP
+.B \-g
+prompt for password.  Typed text is displayed as asterisks and stdin is ignored.
+.TP
 .B \-i
 dmenu matches menu items case insensitively.
 .TP
diff --git a/dmenu.c b/dmenu.c
index 8e84fbd..0659fe3 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -34,6 +34,8 @@ struct item {
 };
 
 static char text[BUFSIZ] = "";
+static char asterisks[sizeof text] = "";
+static char passwordentry = 0;
 static int bh, mw, mh;
 static int sw, sh; /* X display screen geometry width, height */
 static int inputw = 0, promptw;
@@ -56,6 +58,7 @@ static Clr *scheme[SchemeLast];
 
 static int (*fstrncmp)(const char *, const char *, size_t) = strncmp;
 static char *(*fstrstr)(const char *, const char *) = strstr;
+static size_t nextrune(int inc);
 
 static void
 appenditem(struct item *item, struct item **list, struct item **last)
@@ -128,9 +131,30 @@ drawitem(struct item *item, int x, int y, int w)
 static void
 drawmenu(void)
 {
+	char *textbuf = text;
 	unsigned int curpos;
+	size_t visualcursor = cursor;
+	size_t oldcursor, runecount;
 	struct item *item;
-	int x = 0, y = 0, w;
+	int visualcursorset = 0, x = 0, y = 0, w;
+
+	if (passwordentry) {
+		oldcursor = cursor;
+		for (cursor = runecount = 0; text[cursor] != '\0'; runecount++) {
+			asterisks[runecount] = '*';
+			if (cursor >= oldcursor && !visualcursorset) {
+visualcursorset = 1;
+visualcursor = runecount;
+			}
+			cursor = nextrune(+1);
+		}
+		if (!visualcursorset) {
+			visualcursor = runecount;
+		}
+		cursor = oldcursor;
+		asterisks[runecount] = '\0';
+		textbuf = asterisks;
+	}
 
 	drw_setscheme(drw, scheme[SchemeNorm]);
 	drw_rect(drw, 0, 0, mw, mh, 1, 1);
@@ -142,9 +166,9 @@ drawmenu(void)
 	/* draw input field */
 	w = (lines > 0 || !matches) ? mw - x : inputw;
 	drw_setscheme(drw, scheme[SchemeNorm]);
-	drw_text(drw, x, 0, w, bh, lrpad / 2, text, 0);
+	drw_text(drw, x, 0, w, bh, lrpad / 2, textbuf, 0);
 
-	drw_font_getexts(drw->fonts, text, cursor, , NULL);
+	drw_font_getexts(drw->fonts, textbuf, visualcursor, , NULL);
 	if ((curpos += lrpad / 2 - 1) < w) {
 		drw_setscheme(drw, scheme[SchemeNorm]);
 		drw_rect(drw, x + curpos, 2, 2, bh - 4, 1, 0);
@@ -600,7 +624,7 @@ setup(void)
 static void
 usage(void)
 {
-	fputs("usage: dmenu [-b] [-f] [-i] [-l lines] [-p prompt] [-fn font] [-m monitor]\n"
+	fputs("usage: dmenu [-b] [-f] [-g] [-i] [-l lines] [-p prompt] [-fn font] [-m monitor]\n"
 	  " [-nb color] [-nf color] [-sb color] [-sf color] [-v]\n", stderr);
 	exit(1);
 }
@@ -619,6 +643,8 @@ main(int argc, char *argv[])
 			topbar = 0;
 		else if (!strcmp(argv[i], "-f"))   /* grabs keyboard before reading stdin */
 			fast = 1;
+		else if (!strcmp(argv[i], "-g"))   /* get password*/
+			passwordentry = 1;
 		else if (!strcmp(argv[i], "-i")) { /* case-insensitive item matching */
 			fstrncmp = strncasecmp;
 			fstrstr = cistrstr;
@@ -659,9 +685,13 @@ main(int argc, char *argv[])
 
 	if (fast) {
 		grabkeyboard();
-		readstdin();
+		if (!passwordentry) {
+			readstdin();
+		}
 	} else {
-		readstdin();
+		if (!passwordentry) {
+			readstdin();
+		}
 		grabkeyboard();
 	}
 	setup();
-- 
2.1.4

[dev] [dmenu] [PATCH] Added option to prompt for passwords

[Eric Pruitt]

The attached patch adds a "-g" flag to dmenu so it can be used for
password entry. Typed text is replaced with asterisks.

Eric
>From 2014b6757b153df67b2213fe9ded6f34087275be Mon Sep 17 00:00:00 2001
From: Eric Pruitt <eric.pru...@gmail.com>
Date: Mon, 25 Jul 2016 11:38:19 -0700
Subject: [PATCH] Added option to prompt for passwords

---
 dmenu.1 |  3 +++
 dmenu.c | 42 --
 2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/dmenu.1 b/dmenu.1
index d3ab805..91b5a5b 100644
--- a/dmenu.1
+++ b/dmenu.1
@@ -45,6 +45,9 @@ dmenu appears at the bottom of the screen.
 dmenu grabs the keyboard before reading stdin.  This is faster, but will lock up
 X until stdin reaches end\-of\-file.
 .TP
+.B \-g
+prompt for password.  Typed text is displayed as asterisks and stdin is ignored.
+.TP
 .B \-i
 dmenu matches menu items case insensitively.
 .TP
diff --git a/dmenu.c b/dmenu.c
index 8e84fbd..d28e656 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -33,7 +33,9 @@ struct item {
 	int out;
 };
 
+static char asterisks[BUFSIZ] = "";
 static char text[BUFSIZ] = "";
+static char passwordentry = 0;
 static int bh, mw, mh;
 static int sw, sh; /* X display screen geometry width, height */
 static int inputw = 0, promptw;
@@ -56,6 +58,7 @@ static Clr *scheme[SchemeLast];
 
 static int (*fstrncmp)(const char *, const char *, size_t) = strncmp;
 static char *(*fstrstr)(const char *, const char *) = strstr;
+static size_t nextrune(int inc);
 
 static void
 appenditem(struct item *item, struct item **list, struct item **last)
@@ -128,9 +131,30 @@ drawitem(struct item *item, int x, int y, int w)
 static void
 drawmenu(void)
 {
+	char *textbuf = text;
 	unsigned int curpos;
+	size_t visualcursor = cursor;
+	size_t oldcursor, runecount;
 	struct item *item;
-	int x = 0, y = 0, w;
+	int visualcursorset = 0, x = 0, y = 0, w;
+
+	if (passwordentry) {
+		oldcursor = cursor;
+		for (cursor = runecount = 0; text[cursor] != '\0'; runecount++) {
+			asterisks[runecount] = '*';
+			if (cursor >= oldcursor && !visualcursorset) {
+visualcursorset = 1;
+visualcursor = runecount;
+			}
+			cursor = nextrune(+1);
+		}
+		if (!visualcursorset) {
+			visualcursor = runecount;
+		}
+		cursor = oldcursor;
+		asterisks[runecount] = '\0';
+		textbuf = asterisks;
+	}
 
 	drw_setscheme(drw, scheme[SchemeNorm]);
 	drw_rect(drw, 0, 0, mw, mh, 1, 1);
@@ -142,9 +166,9 @@ drawmenu(void)
 	/* draw input field */
 	w = (lines > 0 || !matches) ? mw - x : inputw;
 	drw_setscheme(drw, scheme[SchemeNorm]);
-	drw_text(drw, x, 0, w, bh, lrpad / 2, text, 0);
+	drw_text(drw, x, 0, w, bh, lrpad / 2, textbuf, 0);
 
-	drw_font_getexts(drw->fonts, text, cursor, , NULL);
+	drw_font_getexts(drw->fonts, textbuf, visualcursor, , NULL);
 	if ((curpos += lrpad / 2 - 1) < w) {
 		drw_setscheme(drw, scheme[SchemeNorm]);
 		drw_rect(drw, x + curpos, 2, 2, bh - 4, 1, 0);
@@ -600,7 +624,7 @@ setup(void)
 static void
 usage(void)
 {
-	fputs("usage: dmenu [-b] [-f] [-i] [-l lines] [-p prompt] [-fn font] [-m monitor]\n"
+	fputs("usage: dmenu [-b] [-f] [-g] [-i] [-l lines] [-p prompt] [-fn font] [-m monitor]\n"
 	  " [-nb color] [-nf color] [-sb color] [-sf color] [-v]\n", stderr);
 	exit(1);
 }
@@ -619,6 +643,8 @@ main(int argc, char *argv[])
 			topbar = 0;
 		else if (!strcmp(argv[i], "-f"))   /* grabs keyboard before reading stdin */
 			fast = 1;
+		else if (!strcmp(argv[i], "-g"))   /* get password*/
+			passwordentry = 1;
 		else if (!strcmp(argv[i], "-i")) { /* case-insensitive item matching */
 			fstrncmp = strncasecmp;
 			fstrstr = cistrstr;
@@ -659,9 +685,13 @@ main(int argc, char *argv[])
 
 	if (fast) {
 		grabkeyboard();
-		readstdin();
+		if (!passwordentry) {
+			readstdin();
+		}
 	} else {
-		readstdin();
+		if (!passwordentry) {
+			readstdin();
+		}
 		grabkeyboard();
 	}
 	setup();
-- 
2.1.4

Re: [dev] new pre-patched version of dwm available

[Eric Pruitt]

On Sat, Jul 23, 2016 at 05:21:42PM +0200, FRIGN wrote:
> It's a difficult matter because patches interfere. I know of no way to
> make multiple patches inclusive to each other, in many cases it is not
> possible.

Something I do with my patches to make them easier manually edit the
resulting diffs to reduce lines of context for certain chunks. As a
result, rebasing some of changes on newer versions of dwm becomes a
little less painful. I will also sometimes write code in a less
efficient manner if it means I can produce a patch that won't conflict
with any of my other patches while still applying cleanly to dwm.

Up until about a month ago, I kept a copy of the dwm repo that I
periodically merged with the suckless master tree, but I now keep a
repository of patches alone that get applied to dwm using a Makefile
(https://github.com/ericpruitt/mydwm). More recently, I decided to
combine all of my suckless configurations and GUI-related programs into
a single repo that is yet unpublished but works similarly to the
aforementioned link. Here's what the Makefile for that currently looks
like: https://gist.github.com/ericpruitt/32f3f8b6c3df903d03f5e95ed8ba3428
I'm using GNU make and taking advantage of the numerous features it
provides. I know that monstrosity is far from suckless, but it works
well, and I've learned a lot about GNU make.

Eric

Re: [dev] [dwm] Current window issue

[Eric Pruitt]

On Sat, Jul 23, 2016 at 01:58:53PM -0400, Donald Allen wrote:
> I am running dwm 6.1 on a FreeBSD 10.3 system. dwm I have applied the
> pertag, better-borders, and status-colors patches.
>
> [...]
>
> Unfortunately, I am very busy right now and cannot devote time to
> trying to debug this. But if and when things settle down, I will have
> a look and report.

You should really verify whether or not this still happens with a
vanilla version of dwm because I doubt many (if any) of the people
reading this list are going to want to try to replicate your personal
version of dwm just to debug an issue of unknown origin. If you narrow
down the issue to one patch in particular, reach out to the patch's
author; I wrote better-borders, and if you discover that there is a
problem with it, I would be happy to debug it for you **if the issue is
caused by my patch.** What I am not willing to do is debug your entire
configuration just to verify whether or not my patch is at fault.

Eric

Re: [dev] Kilo - small, simple text editor with syntax highlighting in ~1K lines of code

[Eric Pruitt]

On Tue, Jul 19, 2016 at 07:51:49PM +0200, lukáš Hozda wrote:
> Oh, this looks pretty neat. How does the syntax highlighting work? Is
> it hardcoded or are the some configuration files somewhere?

It's hardcoded: https://github.com/antirez/kilo/blob/master/kilo.c#L350

Eric

Re: [dev] [st] Latest git - Nano with syntax highlighting strange bug

[Eric Pruitt]

On Mon, Jul 18, 2016 at 12:30:45AM +0200, hadrien.lac...@openmailbox.org wrote:
> The problem might be hard to reproduce, so here's a simpler one
> https://a.cocaine.ninja/jihcdl.gif

I tried that, and it also didn't give my any issues. I don't have any
other ideas of what it could be; sorry. If you haven't tried this
already, consider pulling the git repo and compile st yourself without
using the ebuild at all.

Eric

Re: [dev] [st] Latest git - Nano with syntax highlighting strange bug

[Eric Pruitt]

On Sun, Jul 17, 2016 at 10:45:10PM +0200, hadrien.lac...@openmailbox.org wrote:
> I've recently changed from urxvt to st and noticed a bug when using nano
> which will be easier to describe with a short gif:
> https://a.cocaine.ninja/xtlajf.gif
> This issue happens ONLY when I change "static unsigned int tabspaces" from 8
> to 4 in the config file.

I wasn't able to reproduce this. Did you compile the st termcap file,
are you overriding the TERM environment variable, and are you using a
multiplexer like tmux, screen or dvtm?

Eric

Re: [dev] what are these diffs meant to apply to?

[Eric Pruitt]

On Wed, Jul 13, 2016 at 04:22:51PM -0800, Britton Kerin wrote:
> There are some diffs like this one from columns patch:
>
>  dwm-r1580-col.diff
>
> What are these r1580-style things supposed to refer to?

Some of the suckless projects were previously managed using Mercurial,
and the "r1580" probably refers to Mercurial revision #1580.

Eric

Re: [dev] [st] inconsistent backspace and alt+backspace behavior

[Eric Pruitt]

On Mon, Jul 04, 2016 at 08:49:05PM +, Alive 4ever wrote:
> How can I get rid of this inconsistent backspace behavior and get the
> right backspace behavior (^?) even with alt (meta) pressed?

Mod1Mask typically represents Alt, so try adding this to config.h:

{ XK_BackSpace, Mod1Mask,   "\177",  0,0,0},

Eric

Re: [dev] [dwm] Unnecessary scoping blocks

[Eric Pruitt]

On Sun, Jul 03, 2016 at 06:55:40PM +0200, Markus Teich wrote:
> you should shift the declarations above the updatenumlockmask() call acording 
> to
> "Do not mix declarations and code" from http://suckless.org/coding_style. The
> same for the second removed pair of braces.

An updated patch is attached.

Eric
>From 9b9e01d11ac134b15f24cb59d125d106be7bbdf2 Mon Sep 17 00:00:00 2001
From: Eric Pruitt <eric.pru...@gmail.com>
Date: Sun, 3 Jul 2016 10:10:30 -0700
Subject: [PATCH] Removed unnecessary scope blocks

---
 dwm.c | 60 
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/dwm.c b/dwm.c
index b2bc9bd..9901737 100644
--- a/dwm.c
+++ b/dwm.c
@@ -943,41 +943,45 @@ gettextprop(Window w, Atom atom, char *text, unsigned int size)
 void
 grabbuttons(Client *c, int focused)
 {
+	unsigned int i, j;
+	unsigned int modifiers[4];
 	updatenumlockmask();
-	{
-		unsigned int i, j;
-		unsigned int modifiers[] = { 0, LockMask, numlockmask, numlockmask|LockMask };
-		XUngrabButton(dpy, AnyButton, AnyModifier, c->win);
-		if (focused) {
-			for (i = 0; i < LENGTH(buttons); i++)
-if (buttons[i].click == ClkClientWin)
-	for (j = 0; j < LENGTH(modifiers); j++)
-		XGrabButton(dpy, buttons[i].button,
-		buttons[i].mask | modifiers[j],
-		c->win, False, BUTTONMASK,
-		GrabModeAsync, GrabModeSync, None, None);
-		} else
-			XGrabButton(dpy, AnyButton, AnyModifier, c->win, False,
-			BUTTONMASK, GrabModeAsync, GrabModeSync, None, None);
-	}
+	modifiers[0] = 0;
+	modifiers[1] = LockMask;
+	modifiers[2] = numlockmask;
+	modifiers[3] = numlockmask|LockMask;
+	XUngrabButton(dpy, AnyButton, AnyModifier, c->win);
+	if (focused) {
+		for (i = 0; i < LENGTH(buttons); i++)
+			if (buttons[i].click == ClkClientWin)
+for (j = 0; j < LENGTH(modifiers); j++)
+	XGrabButton(dpy, buttons[i].button,
+buttons[i].mask | modifiers[j],
+c->win, False, BUTTONMASK,
+GrabModeAsync, GrabModeSync, None, None);
+	} else
+		XGrabButton(dpy, AnyButton, AnyModifier, c->win, False,
+	BUTTONMASK, GrabModeAsync, GrabModeSync, None, None);
 }
 
 void
 grabkeys(void)
 {
-	updatenumlockmask();
-	{
-		unsigned int i, j;
-		unsigned int modifiers[] = { 0, LockMask, numlockmask, numlockmask|LockMask };
-		KeyCode code;
+	unsigned int i, j;
+	unsigned int modifiers[4];
+	KeyCode code;
 
-		XUngrabKey(dpy, AnyKey, AnyModifier, root);
-		for (i = 0; i < LENGTH(keys); i++)
-			if ((code = XKeysymToKeycode(dpy, keys[i].keysym)))
-for (j = 0; j < LENGTH(modifiers); j++)
-	XGrabKey(dpy, code, keys[i].mod | modifiers[j], root,
-		 True, GrabModeAsync, GrabModeAsync);
-	}
+	updatenumlockmask();
+	modifiers[0] = 0;
+	modifiers[1] = LockMask;
+	modifiers[2] = numlockmask;
+	modifiers[3] = numlockmask|LockMask;
+	XUngrabKey(dpy, AnyKey, AnyModifier, root);
+	for (i = 0; i < LENGTH(keys); i++)
+		if ((code = XKeysymToKeycode(dpy, keys[i].keysym)))
+			for (j = 0; j < LENGTH(modifiers); j++)
+XGrabKey(dpy, code, keys[i].mod | modifiers[j], root,
+	 True, GrabModeAsync, GrabModeAsync);
 }
 
 void
-- 
2.1.4

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[Eric Pruitt]

On Sat, Jul 02, 2016 at 01:19:45PM -0700, Ben Woolley wrote:
> My main issue with having to search patches only is that it is far easier on
> a remote headless server to install git than a web browser,

The suckless site is perfectly usable with elinks, w3m and, if I were to
guess, probably links and lynx, too. Regardless, I think you're
optimizing for a use case that is an extreme minority; I'm pretty sure
most people use a browser to review patches on suckless.org. All this
seems like a large amount of complexity and inconvenience when it comes
to how most people interact with the site.

Maybe I don't understand exactly what you're doing, but if you are
regularly building dwm on various machines, you should probably automate
the process instead of manually searching for and re-downloading the
patches every time.

Eric

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[Eric Pruitt]

On Sat, Jul 02, 2016 at 09:13:05AM -0700, Ben Woolley wrote:
> For releases, you could expose patches for only the branches ahead of the
> release, and that might encourage authors to maintain their branches, and
> patches could automatically be organized by release. A daily run could update
> the website automatically.
>
> That way, releases posted as a tarball will have patches, while revisions
> requiring git would have branches in git. No new dependencies, and a simple
> way to organize all patches without needing to mess with dates or revisions.
> There would only need to be release version and patch name. Each release
> could have its own folder with release-specific patches.

I don't like this idea because it adds a lot of extra work if I need a
patch that doesn't apply cleanly to the current release of dwm. Right
now, I can just navigate to the website, click the patch name and see a
list of them. Unless I'm missing something, I would have to use Git to
clone the sites repo, then cd into the repo, run "git branch" to see
what branches are available, "git checkout $BRANCH", figure out what the
name of the patch is then apply it. If it turns out $BRANCH doesn't have
the patch, I have to search some more.

Eric

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[Eric Pruitt]

On Wed, Jun 29, 2016 at 01:54:13PM -0800, Britton Kerin wrote:
> I'm not going to try to fix patches I don't use myself, it's possible
> to screw up and testing is a hassle since it involves the wm.

I wonder what the odds are of a patch applying cleanly, compilation of
of dwm succeeding but actually breaking dwm in the process. I'm thinking
this could be automated by attempting to apply the patches to HEAD,
renaming the ones that succeed and still allow dwm to build then doing
"git reset --hard HEAD^" and repeating the process. Maybe stop at the
dwm commit that comes before the oldest patch's commit date. Maybe
something like this:

while ...; do
git_version="$(git log -1 --format=%h)"

for patch in *.diff; do
# Getting the name part might be a little tricky, but maybe
# it could be done by grepping for the patch path in the
# markdown files e.g.:
name="$(fgrep -m1 -l -w "$patch" *.md)"
name="${name%.md}"

if patch < "$patch" && make dwm; then
git mv "$patch" "dwm-$name-$git_version.diff"
fi

make clean
git reset --hard
done

git reset --hard HEAD^
done

Note that this is an example and doesn't take into account that the
"sites" repo and dwm wouldn't be in the same folder.

Eric

Re: [dev] [dwm] [PATCH] Configure geometry before applying rules

[Eric Pruitt]

On Thu, Jun 23, 2016 at 10:14:54AM +0200, Anselm R Garbe wrote:
> Sorry I missed to reply sooner. Please re-create the patch against git
> HEAD so that it cleanly applies and I will apply it.
> Alternatively I can apply it as a new commit which wouldn't take your name.
>
> Hence I suggest create a clean patch ;)

That patch already applies cleanly:

dwm$ head -n10 0001-Configure-geometry-before-applying-rules.patch
From da2a02dd23befc0ff89d08c990a360c048f0adfd Mon Sep 17 00:00:00 2001
From: Eric Pruitt <eric.pru...@gmail.com>
Date: Wed, 25 May 2016 16:33:11 -0700
Subject: [PATCH] Configure geometry before applying rules

Configuring geometry before applying rules makes it possible to have
more complex constraints in applyrules that depend on the initial window
dimensions and location.
---
 dwm.c | 13 +++--
dwm$ git reset --hard 3465bed290abc62cb2e69a8096084ba6b8eb4956
HEAD is now at 3465bed fix fullscreen clients not resized on X display
resolution change
dwm$ git apply 0001-Configure-geometry-before-applying-rules.patch
dwm$

Does your repo have changes you haven't pushed to the public repo?

Eric

[dev] [dwm] [PATCH] Configure geometry before applying rules

[Eric Pruitt]

Since dwm doesn't expose enough of the X11 properties to use Devil's
Pie, I am using changes inside of applyrules to modify window locations
and geometry. As part of my changes, I needed client geometry properties
to be set before the applyrules function is called because I need to
know where a window is initially located to determine if it needs to be
modified. I don't see anything that indicates the geometry assignments
**must** occur before calling applyrules, so I think it would be a good
to move the geometry assignments permanently in the suckless repo; most
people "configure" dwm by patching it, and this change would make it
easier to add more complex constraints to applyrules. I've attached a
patch with this change to my email.

Eric
>From da2a02dd23befc0ff89d08c990a360c048f0adfd Mon Sep 17 00:00:00 2001
From: Eric Pruitt <eric.pru...@gmail.com>
Date: Wed, 25 May 2016 16:33:11 -0700
Subject: [PATCH] Configure geometry before applying rules

Configuring geometry before applying rules makes it possible to have
more complex constraints in applyrules that depend on the initial window
dimensions and location.
---
 dwm.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/dwm.c b/dwm.c
index ff7e096..9585683 100644
--- a/dwm.c
+++ b/dwm.c
@@ -1043,6 +1043,13 @@ manage(Window w, XWindowAttributes *wa)
 
 	c = ecalloc(1, sizeof(Client));
 	c->win = w;
+	/* geometry */
+	c->x = c->oldx = wa->x;
+	c->y = c->oldy = wa->y;
+	c->w = c->oldw = wa->width;
+	c->h = c->oldh = wa->height;
+	c->oldbw = wa->border_width;
+
 	updatetitle(c);
 	if (XGetTransientForHint(dpy, w, ) && (t = wintoclient(trans))) {
 		c->mon = t->mon;
@@ -1051,12 +1058,6 @@ manage(Window w, XWindowAttributes *wa)
 		c->mon = selmon;
 		applyrules(c);
 	}
-	/* geometry */
-	c->x = c->oldx = wa->x;
-	c->y = c->oldy = wa->y;
-	c->w = c->oldw = wa->width;
-	c->h = c->oldh = wa->height;
-	c->oldbw = wa->border_width;
 
 	if (c->x + WIDTH(c) > c->mon->mx + c->mon->mw)
 		c->x = c->mon->mx + c->mon->mw - WIDTH(c);
-- 
2.1.4

Re: [dev] [query] A tool for filtering lists of filenames with return codes

[Eric Pruitt]

On Fri, May 20, 2016 at 07:29:28AM -0700, Evan Gates wrote:
> This ability is already built in to find using the -exec primary. And
> newline delimited lists of files are not safe. If the program you are
> piping to supports nul delimited lists you can print them in POSIX
> find by doing

I know using newlines isn't safe, and that's why the tool supports a -0
flag for null-delimited fields. Newline mode is the default since most
other *nix tools assume line or whitespace delimation; principle of
least surprise.

>
> For your first example
>
> find . -type f -exec sh -c 'ldd "$1" >/dev/null 2>&1' sh {} \; -print
>
> or better, yet, fewer instances of sh
>
> find . -type f -exec sh -c 'for f do ldd "$f" >/dev/null 2>&1 &&
> printf %s\\n "$f"; done;:' sh {} +
>
> These examples do just print the filenames, so they are for visual
> inspection only. If you want to do something with those filenames, do
> so in exec, or print them with nul delimiters (but really... just
> -exec).

Yes, it is certainly possible to achieve what this tool does by other
means. This program actually started out as a shell script that looked
something like this:

while read line; do
if cat -- "$line" | "$@" > /dev/null; then
echo "$line"
fi
done

I wanted something more robust, and I opted to write the tool in C
because it's fast and my C skills have been getting pretty rusty.

Thanks for the feedback,
Eric

Re: [dev] [query] A tool for filtering lists of filenames with return codes

[Eric Pruitt]

On Fri, May 20, 2016 at 10:56:03AM +0200, Hiltjo Posthuma wrote:
> Briefly tested on OpenBSD and found a small issue (patch attached).

Thanks. I also saw that warning on OS X, but the include didn't make it
back into the repo. This has been fixed.

Eric

[dev] [query] A tool for filtering lists of filenames with return codes

[Eric Pruitt]

I wrote a tool for filtering lists of files based on return codes of
subprocesses called "query:" https://github.com/ericpruitt/query .

Find all dynamically linked executables:

find -type f | query sh -c 'ldd "$QUERY_FILENAME"'

Find all files ending in ".json" that are malformed:

find -type f -iname '*.json' | query -s ! python -m json.tool

The tool should pretty portable. I haven't tested it on FreeBSD or
OpenBSD yet, but I was able to compile it on Mac OS X. I am using
signal(2) whose behavior varies across platforms, but I don't think that
will be a problem in practice since the handler only calls exit(3).
Please let me know what you think of the idea and code.

Thanks,
Eric

Re: [dev] [slock] PAM support

[Eric Pruitt]

On Mon, May 16, 2016 at 03:58:02PM -0700, Eric Pruitt wrote:
> On Mon, May 16, 2016 at 09:51:08PM +0200, Jan Christoph Ebersbach wrote:
> > > On the system I'm using that relies on PAM, my account doesn't have an
> > > entry in the local /etc/passwd file. Disabling getpw and related bits
> > > makes the patch work for me.
> >
> > I fixed the issue and moved the getpw code to an ifdef.
>
> I see you moved the HAVE_BSD_AUTH check, but I don't understand how this
> is supposed to resolve the issue I had -- the machine I'm using is a
> Linux machine. The getuid(3) and getpwuid(3) functions work fine because
> they're implemented in glibc which supports NSS. The problem is the
> "getpw" (which calls getspnam(3)) function which fails with "cannot
> retrieve shadow entry."

I intend to modify your code so that it handles systems relying on NSS
for authentication later today. Would you be willing to merge my changes
into your patch?

Eric

Re: [dev] running dwm from/with gnome

[Eric Pruitt]

On Tue, May 17, 2016 at 10:45:19AM +1000, Timothy Rice wrote:
> There seems to be some confusion around xsessions etc, resulting in some
> factual errors in one or two recent emails. The following might be useful:
> [...]
> I can't speak one way or the other for the .xsession file, but it is not
> necessary for .xinitrc to be set executable. I use the TTY/startx approach
> and my .xinitrc has mode 0600.

Thanks for the information. On Debian, it turns out the executable bit
is in fact not required at least when using LightDM. On RHEL, however,
you have to set the executable bit on the xsession when using the
package xorg-x11-xinit-session. From the source:

for session in ~/.xsession ~/.Xclients /etc/X11/xinit/Xclients ;
do
if [ -f ${session} ] ; then
  exec ${session}
fi
done

I'm not sure my other "factual error(s?)" was, but I would be happy to
be enlightened. I always use a login manager and have always used
xsession as a result, and I'm pretty sure the original poster is also
still using a login manager.

Eric

Re: [dev] running dwm from/with gnome

[Eric Pruitt]

On Mon, May 16, 2016 at 03:00:16PM -0800, Britton Kerin wrote:
> I just made .xinit:
>
> $ ls -l .xinitrc
> -rw-r--r-- 1 bkerin bkerin 9 May 16 14:50 .xinitrc
> $ cat .xinitrc
> exec dwm
> $
>
> I slightly remember doing that 20 years ago or so, fun.  But it doesn't
> seem to work nowadays at least on debian 8.4.  I still get gnome
> even after a reboot.  Perhaps the tutorial Launching section should
> be removed since wrong stuff is worse than nothing.  I wouldn't ask
> dwm to cover how to avoid gnome under all circumstances, maybe
> just a pointer a good source on the gruesome details would be good.

X11 session initialization varies between distros, so it's hard to write
something that applies to everyone. For example, when I used an RHEL
desktop for the very first time a few months ago, I discovered you have
to install an additional package to have the startup process read a
local X11 session file.

My personal desktop and laptop run on Debian 8, and I have a ~/.xsession
file (attached to this message) that contains my startup script. Using
~/.xinitrc _might_ work on Debian, but I don't know for sure. At the
very least, you need to make sure the script is executable, which is not
the case above.

I also have the following in the Makefile I use for configuration new
machines:

# The default XFCE4 session in Debian will always attempt to launch
# orage, xfdesktop and xfce4-panel regardless of the local session.
# Since the init script is executed as the user, and I never use
# these programs, simply symlinking them to /bin/true somewhere in
# the PATH effectively disables them.
$(HOME)/bin/orage:
ln -s /bin/true $@

$(HOME)/bin/xfdesktop:
ln -s /bin/true $@

$(HOME)/bin/xfce4-panel:
ln -s /bin/true $@

Eric
#!/usr/bin/env bash
test -z "$PROFILE_LOADED" && source ~/.profile

export XDG_CACHE_HOME="/tmp/"
export _JAVA_AWT_WM_NONREPARENTING="1"

window_manager="dwm"

async_startup_commands=(
"gpick"
"pidgin"
"st"
"volti"
"wmname LG3D"
"xcompmgr -n"
"xfce4-session"
"xmodmap ~/.xmodmaprc"
"xset s off -dpms"
"xsetroot -solid #00"
)

if command -v slock; then
export DISPLAY_LOCKER="slock"
else
export DISPLAY_LOCKER="xscreensaver-command -l"
async_startup_commands+=("xscreensaver -no-splash")
fi

# On my personal machines, I use Firefox and Chromium while I use exclusively
# use Google Chrome at work.
if [[ "$(hostname -f)" = *.codevat.com ]]; then
async_startup_commands+=(
"chromium"
"firefox"
)
else
async_startup_commands+=(
"google-chrome"
)
fi

for command in "${async_startup_commands[@]}"; do
eval " $command" &
done

# Automatically relaunch the window manger if its exits with a non-zero exit
# code with a short delay between each launch.
while ! $window_manager; do
sleep 1
done

Re: [dev] [slock] PAM support

[Eric Pruitt]

On Mon, May 16, 2016 at 09:51:08PM +0200, Jan Christoph Ebersbach wrote:
> > On the system I'm using that relies on PAM, my account doesn't have an
> > entry in the local /etc/passwd file. Disabling getpw and related bits
> > makes the patch work for me.
>
> I fixed the issue and moved the getpw code to an ifdef.

I see you moved the HAVE_BSD_AUTH check, but I don't understand how this
is supposed to resolve the issue I had -- the machine I'm using is a
Linux machine. The getuid(3) and getpwuid(3) functions work fine because
they're implemented in glibc which supports NSS. The problem is the
"getpw" (which calls getspnam(3)) function which fails with "cannot
retrieve shadow entry."

Eric


signature.asc
Description: Digital signature

Re: [dev] [slock] PAM support

[Eric Pruitt]

On Mon, May 16, 2016 at 10:38:00PM +0200, Jan Christoph Ebersbach wrote:
> On Mon 16-05-2016 11:54 -0700, Eric Pruitt wrote:
> > Since PAM configurations typically enforce a delay before you can
> > reauthenticate after an incorrect password is entered, it would be
> > nice if there was another color to indicate that slock is waiting
> > for the PAM functions to return.
>
> As far as my test go, only if the password was entered incorrectly, PAM
> waits for a moment.

Yes, that's the scenario I described in my earlier message.

> In this case it would be nice to have a different color that indicates
> that the password has been handed to PAM.  However, when the password
> is correct, PAM immediately returns.  In this case, the screen would
> quickly change colors.  Not sure if this desirable.

It's mildly annoying, but I don't consider it a deal breaker and think
the behavior is fine. The added complexity to work around it wouldn't be
worth it in my opinion. It can be made a little less jarring by
selecting a color that's in between the "password being typed" and
"password is incorrect" colors.

> Attached you find the patch that adds this feature.  What do you think?

I think this patch works well.

Thank you,
Eric

Re: [dev] running dwm from/with gnome

[Eric Pruitt]

On Mon, May 16, 2016 at 02:05:58PM -0800, Britton Kerin wrote:
> Is it possible to run dwm and keep my desktop icons somehow?  I have
> most of my projects sort of geographically organized there which sucks
> I know but I'd rather not lose it right now.  I found lots of ancient
> pages about this I'm wondering if there's a particular known-good
> modern way.

Desktops are typically essentially just fancy windows. Nautilus provides
a desktop, and you can launch it by running "nautilus" with no
arguments. The desktop will appear on whatever tag(s) is currently
active. It will also obscure the dwm bar, but you can still navigate
between tags using keyboard shortcuts.

> I'm on debian 4.9

I'm assuming 4.9 is a typo. Even if it's not, I think Nautilus has
provided a desktop for a very long time if not since it was created.

Eric

Re: [dev] [slock] PAM support

[Eric Pruitt]

On Mon, May 16, 2016 at 11:47:38AM -0700, Eric Pruitt wrote:
> On Mon, May 16, 2016 at 08:07:54PM +0200, Jan Christoph Ebersbach wrote:
> > I guess this issue can still happen.  I didn't remove most of the getpw*
> > code in order to keep the patch small.  I'm using sssd and so the getpw
> > calls still work.  The only issue is that the password hash can't be
> > retrieved.  This problem I solved with this patch by passing everything
> > through PAM.
>
> On the system I'm using that relies on PAM, my account doesn't have an
> entry in the local /etc/passwd file. Disabling getpw and related bits
> makes the patch work for me.

I have a suggestion -- I think you should add another color option to
the configuration. Since PAM configurations typically enforce a delay
before you can reauthenticate after an incorrect password is entered, it
would be nice if there was another color to indicate that slock is
waiting for the PAM functions to return.

Eric

Re: [dev] [slock] PAM support

[Eric Pruitt]

On Mon, May 16, 2016 at 08:07:54PM +0200, Jan Christoph Ebersbach wrote:
> I guess this issue can still happen.  I didn't remove most of the getpw*
> code in order to keep the patch small.  I'm using sssd and so the getpw
> calls still work.  The only issue is that the password hash can't be
> retrieved.  This problem I solved with this patch by passing everything
> through PAM.

On the system I'm using that relies on PAM, my account doesn't have an
entry in the local /etc/passwd file. Disabling getpw and related bits
makes the patch work for me.

Thanks,
Eric

Re: [dev] [slock] PAM support

[Eric Pruitt]

On Mon, May 16, 2016 at 06:32:54PM +0200, Jan Christoph Ebersbach wrote:
> Yes, it's there in git but it takes a while till the web pages have be
> regenerated, I guess.

I could be wrong, but I'm fairly certain the website is manually
regenerated. Otherwise, it would be pretty easy to do malicious things.

I downloaded and applied the patch directly from the sites repo, but I
get "cannot retrieve shadow entry" when running it. I don't have time to
debug the issue right now, so I'll follow-up later.

Eric

Re: [dev] [slock] PAM support

[Eric Pruitt]

On Mon, May 16, 2016 at 05:59:37PM +0200, Kamil Cholewiński wrote:
> On Mon, 16 May 2016, Jan Christoph Ebersbach  wrote:
> > What auth system are you using if it's neither PAM nor shadow/passwd?
>
> Kumbaya auth, or cowboy auth, according to personal preference

I vote for Stallman auth -- passwords restrict freedom, so there's no
point in having them in the first place.

Eric

Re: [dev] [slock] PAM support

[Eric Pruitt]

On Mon, May 16, 2016 at 05:21:01PM +0200, Jan Christoph Ebersbach wrote:
> I've added support for PAM authentication to slock.  When you try it,
> I'd very happy about feedback because I haven't really done any serious
> work with PAM yet:
>
> http://tools.suckless.org/slock/patches/pam_auth

When I try to access the URL, I get "The requested document at
'http://tools.suckless.org/slock/patches/pam_auth' doesn't exist," and
the patch also does not appear in the sidebar. Are you sure your patch
has been committed to the HTTP serving tree?

Eric