Previous version of the patch incorrectly set sel.primary, issue fixed.
The original implementation of this patch copied the URL to the PRIMARY
clipboard. st has since changed its behaviour to align with the freedesktop
standard [0] on the issue such that, in general, explicit copy+paste actions
u
On 02/15/2016 02:55 AM, Sylvain BERTRAND wrote:
> On Sat, Feb 13, 2016 at 08:03:13PM +0100, Leo Gaspard wrote:
>> https://git.ekleog.org/dtext/
>
> Hi,
>
> What is the scope of dtext in perspective of harfbuzz? Do you plan to support
> unicode for a maximum of languages? (heard thai and indi
On Sun, Feb 14, 2016 at 03:17:35PM +, Maxime Coste wrote:
> On Sat, Feb 13, 2016 at 02:11:28PM +0100, Marc André Tanner wrote:
> > On Mon, Jan 18, 2016 at 08:24:14AM +0100, Jan Christoph Ebersbach wrote:
> > > - I miss that I can't align multiple cursors in insert mode, i.e. to
> > > align al
On Sun, Feb 14, 2016 at 12:49:10AM -0500, Random832 wrote:
>
> Recently, the question of the correctness of vim's behavior of 2dw on
> the first of three lines of one word each came up on the vim mailing
> list (it turns out that it's not correct according to POSIX, but is
> shared with traditiona
yes, even though i disagree with the abolition of files (in this case
just as a matter of convention over need), it's at least simpler than
the current mess. would serve my use case all right.
On 2/15/16, Anselm R Garbe wrote:
> On 15 February 2016 at 11:13, Kamil Cholewiński
> wrote:
>>> slock
On 15 February 2016 at 11:13, Kamil Cholewiński wrote:
>> slock < password-file
>
> You now have a password in cleartext, which we know is a bad idea. It
> would be better to hash it. Congrats, /etc/passwd & friends reinvented.
Just adopt hmac_sha256[1] into slock.c and put your pw hash into
conf
The original implementation of this patch copied the URL to the PRIMARY
clipboard. st has since changed its behaviour to align with the freedesktop
standard [0] on the issue such that, in general, explicit copy+paste actions
use CLIPBOARD while implicit (eg selection-based) copying will use PRIMARY
#!/bin/sh
capture-all-keyboard-shit-and-show-stupid-rainbows |
while read line
do
if [ "$line" = `cat pass` ]
then
killall capture-all-keyboard-shit-and-show-stupid-rainbows
else
mpg123 fart.mp3
fi
done
Tried to fit passwd hashing in there, but it would need something that
ensures sha1su
On Mon, Feb 15, 2016 at 11:40:07AM +0100, FRIGN wrote:
> On Mon, 15 Feb 2016 10:55:45 +0100
> Markus Teich wrote:
>
> Hey Markus,
>
> > This is an interesting idea. I would not use it for mainline (users don't
> > want
> > to change their password in many places), but you can push a patch to th
On Mon, 15 Feb 2016 10:55:45 +0100
Markus Teich wrote:
Hey Markus,
> This is an interesting idea. I would not use it for mainline (users don't want
> to change their password in many places), but you can push a patch to the
> wiki.
Dimitris talked about a "third" way to handle passwords on a s
On Mon, Feb 15, 2016 at 10:55 AM, Markus Teich
wrote:
>> slock < password-file
>
> This is an interesting idea. I would not use it for mainline (users don't want
> to change their password in many places), but you can push a patch to the
> wiki.
>
Essentially, password hashing is a thing that c
> slock < password-file
You now have a password in cleartext, which we know is a bad idea. It
would be better to hash it. Congrats, /etc/passwd & friends reinvented.
Thanks! I've applied the patch.
hiro wrote:
> Anyway, it would be more useful to concentrate on the password checking part,
> it segfaults commonly (which is fucking ridiculous!!) because ldap, linux,
> etc. suck.
Heyho hiro,
Same argument as for surf applies here: If you can't fix the suckyness, you have
to build a nice interf
Martin Kühne wrote:
> stdout could print an api secret "[locked]" and the calling script could act
> upon that.
>
> slock | {
> read
> if [[ "$REPLY" = "[locked]" ]]; then
> suspend
> else
> yell at user or power off for added security
> fi
> }
Heyho Martin,
thats basically the
15 matches
Mail list logo
