Re: [dev] [ANNOUNCE] slock-1.3

[Markus Teich]

hiro wrote:
> How does your integrated execution of s2ram change that?  Your slock can still
> fail in just the same way.

Heyho hiro,

with the patch first the cover window is created and the keyboard and mouse are
grabbed. I consider this setup. If it fails, slock exits and does *not* execute
s2ram. If it succeeded, s2ram is executed and the loop handling user input is
entered. Of course there could be a crash inside that loop, but we cannot know
that in advance and we also cannot fork-exec s2ram at any later stage.

The most common case for slock failing was that the grabbing of input devices
failed when some other application still had a grab active. This failure is
fixed by the patch.

--Markus

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

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 all "=" over multiple lines.  The editor kakoune supports this
>   nicely

I just implemented basic support for this with Shift-Tab in insert/replace
mode. It is most likely not (yet?) as powerful as kakoune (it has been
a while since I last played around with kak).

For example it won't work as expected when multiple cursors are on the
same line.

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [surf][bug] segmentation fault

[robin]

On Tue, Feb 09, 2016 at 10:01:30PM +0100, FRIGN wrote:
> On Tue, 09 Feb 2016 21:49:17 +0100
> Christoph Lohmann <2...@r-36.net> wrote:
> 
> > Which OS are you using?
> > Which distribution of this OS are you using?
> > Which webkit version are you using?
> > Have you compiled webkit on your own?
> > If not: Why not?
> 
> Most importantly: Which version of surf is he running?
> 
> Cheers
> 
> FRIGN
> 
> -- 
> FRIGN 
> 

Allright! Thanks guys.
I tried the webkit2 branch and there's no problem there.

In case you are still curious:
Debian testing.
Did not compile wekkit myself because last time i did, it was tedious.

Re: [dev] [ANNOUNCE] slock-1.3

[Martin Kühne]

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
}

cheers!
mar77i

Re: [dev] [ANNOUNCE] slock-1.3

[hiro]

Oh god no.

You guys must have some strange use cases.

When I run slock there's no way for me to miss whether it ran or not
(It is pretty visible all over my screen). So I have like 1 second to
notice this before my display shuts off for standby. In the unlikely
event of catastrophic X-Bullshit I can just wake up my computer or
throw it out the window and by this clear the RAM before the police
arrives.

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.

As I'm lazy I've developed a habit of using this to my advantage. When
I get into my office I just press enter, every second time the network
is broken (because of networkmanager) and slock segfaults while trying
to check the password via ldap, thus i save a lot of time I'd
otherwise waste typing my super-secure password.

I would even do without *any* password, but it's company policy to screenlock.

I suggest this very platform-independent alternative interface (you
can remove special-casing for linux,bsd and such bullshit):

slock < password-file

Re: [dev] [ANNOUNCE] slock-1.3

[Carlos Torres]

you can already use xssstate to monitor the state of the screen and
the screensaver, why not use that to do both slock, and eventually
sleep?

--Carlos

On Sat, Feb 13, 2016 at 3:57 PM, hiro <23h...@gmail.com> wrote:
> Oh god no.
>
> You guys must have some strange use cases.
>
> When I run slock there's no way for me to miss whether it ran or not
> (It is pretty visible all over my screen). So I have like 1 second to
> notice this before my display shuts off for standby. In the unlikely
> event of catastrophic X-Bullshit I can just wake up my computer or
> throw it out the window and by this clear the RAM before the police
> arrives.
>
> 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.
>
> As I'm lazy I've developed a habit of using this to my advantage. When
> I get into my office I just press enter, every second time the network
> is broken (because of networkmanager) and slock segfaults while trying
> to check the password via ldap, thus i save a lot of time I'd
> otherwise waste typing my super-secure password.
>
> I would even do without *any* password, but it's company policy to screenlock.
>
> I suggest this very platform-independent alternative interface (you
> can remove special-casing for linux,bsd and such bullshit):
>
> slock < password-file
>

Re: [dev] [ANNOUNCE] slock-1.3

[FRIGN]

On Sat, 13 Feb 2016 21:57:14 +0100
hiro <23h...@gmail.com> wrote:

Hey hiro,

> When I run slock there's no way for me to miss whether it ran or not
> (It is pretty visible all over my screen). So I have like 1 second to
> notice this before my display shuts off for standby. In the unlikely
> event of catastrophic X-Bullshit I can just wake up my computer or
> throw it out the window and by this clear the RAM before the police
> arrives.

If not for the help of slock, I would be getting 15 years to life for
all the illegal stuff I have on my computer.
Thanks to the slock-safety, the police has _nothing_! *evil_laugh* /s

> 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.

Can you elaborate on that a bit more? :) If you desire more error-checking,
I could put it on my TODO.

Cheers

FRIGN

-- 
FRIGN 

Re: [dev] [ANNOUNCE] slock-1.3

[hiro]

i.e. throw out all this platform dependent bullshit password checking
code and replace it with simple string comparison (string from text
file).

[dev] [vis] dw near the end of the line

[Random832]

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 traditional vi).

At that time, I wasn't able to build vis to see what it does. I've since
figured out my build problem, and tested vis's behavior in this
situation.

When you delete the last word of a line in vis with the dw command, it
always deletes the newline and all following spaces and newlines
(i.e. placing the content of the next non-blank line on the current
one). This behavior differs from most other vi clones, matching only
elvis-tiny. Is this behavior intended?