Re: [dev] st utf8 printing

[Petr Šabata]

On Thu, Apr 12, 2012 at 12:10:47PM -0500, Stephen Paul Weber wrote:
> Somebody claiming to be Nick wrote:
> >Quoth Stephen Paul Weber:
> >>My st install prints some utf8 chars fine (like ©) but others (like …) itt
> >>has trouble with.
> >
> >I *think* that would be because rxvt-unicode falls back to another
> >font if the one you specify doesn't have a glyph it wants. So the
> >characters st isn't printing aren't actually in terminus. I'm
> >guessing, though.
> 
> Huh, weird.  What st does print (!D, and it sort of messes up
> formatting of characters right after it) makes very little sense to
> me, but that could be it.  I'm not super-attached to Terminus, I
> just don't know any other X fixed fonts with big font sizes
> available.

I'm quite happy with -misc-fixed-*.

-P

> 
> -- 
> Stephen Paul Weber, @singpolyma
> See  for how I prefer to be contacted
> edition right joseph




pgpoI6oIfY8EY.pgp
Description: PGP signature

[dev] fix numlock bug

[Nikolay G. Petrov]

Hi guys!

When my "numlock" is active, I can't switching under different workspace 
or start the terminal,or by press on mouse button, nothings works! When 
I switch off "numlock", all is ok.

Where in source code I can fix that?

[dev] situ — change files in situ

[Strake]

Hello all.

I wrote a program to mutate files in situ by a given shell program,
available here:
http://strake.zanity.net:1104/situ/

I thought that it might be useful for some other folks here, ergo this mail.
I wrote it to gain the functionality of GNU sed's -i switch in 9base sed.
Unlike GNU sed's -i switch, it ought to work with any program.

Cheers,
strake

Re: [dev] situ — change files in situ

[Troels Henriksen]

Strake  writes:

> Hello all.
>
> I wrote a program to mutate files in situ by a given shell program,
> available here:
> http://strake.zanity.net:1104/situ/
>
> I thought that it might be useful for some other folks here, ergo this mail.
> I wrote it to gain the functionality of GNU sed's -i switch in 9base sed.
> Unlike GNU sed's -i switch, it ought to work with any program.

I wrote a similar program in C: http://sigkill.dk/projects/insitu/ It
also does actual in-replace replacement (which is sometimes not what you
want).  Note that you can also exploit shell evaluation order:

(rm foo && cmd... > foo) < foo

This will do an (almost) in-place replacement of foo.


-- 
\  Troels
/\ Henriksen

Re: [dev] st utf8 printing

[Stephen Paul Weber]

Somebody signing messages as Petr Šabata wrote:

I'm quite happy with -misc-fixed-*.


Huh, for somereason I thought it didn't get that big, but I see that it will 
go to almost the size I run my terminal at.  I tried this with xterm:


-misc-fixed-medium-r-*-*-*-200-*-*-*-*-*-*

and it worked and was the right size.  I then tried it in st, and the size 
is still fine, but the spacing is all messed up and every time I type it 
shows duplicates of the character.  Some sort of really weird paiting bug.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature

Re: [dev] situ — change files in situ

[Connor Lane Smith]

Hey,

On 13 April 2012 14:14, Troels Henriksen  wrote:
> Note that you can also exploit shell evaluation order

Of course, that doesn't wait to see whether cmd succeeds.

I wonder whether a situ-like could be used to produce a diff of the
original file, rather than a complete second copy. Programs like sed
don't generally make that many changes, so if we were to connect situ
to the file and the cmd's stdout we could compute the diff and then
patch the original file once cmd exits 0. If someone could get that
working it would be pretty sweet.

Thanks,
cls

Re: [dev] st utf8 printing

[Andrew Hills]

On Fri, Apr 13, 2012 at 2:32 AM, Eckehard Berns  wrote:
> Vim draws placeholder chars for anything it can't display. But nobody
> uses the pure X11 GUI of Vim anyway. You either use Vim in a terminal
> or the GTK+ GUI (which - as far as I can tell - uses Pango to draw
> text).

You couldn't pay me to use the GTK+ GUI. I use the pure X11 GUI. So
does everyone else here at work.

--Andrew Hills

Re: [dev] st utf8 printing

[Stephen Paul Weber]

Somebody claiming to be Andrew Hills wrote:

On Fri, Apr 13, 2012 at 2:32 AM, Eckehard Berns  wrote:

Vim draws placeholder chars for anything it can't display. But nobody
uses the pure X11 GUI of Vim anyway. You either use Vim in a terminal
or the GTK+ GUI (which - as far as I can tell - uses Pango to draw
text).


You couldn't pay me to use the GTK+ GUI. I use the pure X11 GUI. So
does everyone else here at work.


People use vim from a GUI?
/me confused

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature

Re: [dev] st utf8 printing

[Connor Lane Smith]

On 13 April 2012 15:07, Stephen Paul Weber  wrote:
> People use vim from a GUI?

vim *is* a GUI. It's not a line editor, is it? libcurses is a GUI
toolkit too, it just happens to abstract over the hack that is ANSI
escapes.

cls

Re: [dev] st utf8 printing

[Andrew Hills]

On Fri, Apr 13, 2012 at 10:07 AM, Stephen Paul Weber
 wrote:
> Somebody claiming to be Andrew Hills wrote:
>> You couldn't pay me to use the GTK+ GUI. I use the pure X11 GUI. So
>> does everyone else here at work.
>
>
> People use vim from a GUI?
> /me confused

Vim works better when it's not stuck in a terminal fighting for
breath. I know, X11 spoils me.

--Andrew Hills

Re: [dev] situ — change files in situ

[Strake]

On 13/04/2012, Troels Henriksen  wrote:
> I wrote a similar program in C: http://sigkill.dk/projects/insitu/ It
> also does actual in-replace replacement (which is sometimes not what you
> want).

I actually found this prior, but wanted a program that would not harm
the file on failure.

> Note that you can also exploit shell evaluation order:

What cls said.

Re: [dev] situ — change files in situ

[Strake]

On 13/04/2012, Connor Lane Smith  wrote:
> I wonder whether a situ-like could be used to produce a diff of the
> original file, rather than a complete second copy. Programs like sed
> don't generally make that many changes, so if we were to connect situ
> to the file and the cmd's stdout we could compute the diff and then
> patch the original file once cmd exits 0. If someone could get that
> working it would be pretty sweet.

I'm not sure why — this method seems ultimately functionally equivalent to mine.
Perhaps I fail to ken your logic here.

Cheers,
strake

Re: [dev] st utf8 printing

[Kurt H Maier]

On Fri, Apr 13, 2012 at 03:12:26PM +0100, Connor Lane Smith wrote:
> 
> vim *is* a GUI. It's not a line editor, is it? libcurses is a GUI
> toolkit too, it just happens to abstract over the hack that is ANSI
> escapes.

libcurses is a hack that abstracts over every single
character-addressing hack ever devised.

Re: [dev] situ — change files in situ

[Connor Lane Smith]

On 13 April 2012 16:04, Strake  wrote:
> I'm not sure why — this method seems ultimately functionally equivalent to 
> mine.
> Perhaps I fail to ken your logic here.

Your method, while simpler, requires 2n space to 'situ' a length n
file. A suitable patch format would require only enough space to store
the changes to the original file. The outcome would be identical, but
if we're trying to sed only a few changes in a large file it would be
more efficient in terms of storage.

cls

Re: [dev] situ — change files in situ

[Strake]

On 13/04/2012, Connor Lane Smith  wrote:
> Your method, while simpler, requires 2n space to 'situ' a length n
> file. A suitable patch format would require only enough space to store
> the changes to the original file. The outcome would be identical, but
> if we're trying to sed only a few changes in a large file it would be
> more efficient in terms of storage.

True, if we trim the start and finish lazily, but worst-case diff
algorithm space usage is worse — quadratic, if I'm not mistaken.

Re: [dev] situ — change files in situ

[Connor Lane Smith]

On 13 April 2012 16:37, Strake  wrote:
> True, if we trim the start and finish lazily

That depends on the diff format. diff -e, for example, could work well.

> but worst-case diff
> algorithm space usage is worse — quadratic, if I'm not mistaken.

That's true. Although, diff is worst-case quadratic in the number of
lines, not bytes. And the fact is the worst-case can be avoided: we
don't really *need* the longest common subsequence, only an
approximation to it. If we exceed some threshold we can simply
'plump'.

To be clear, I don't mean to dismiss either existing situ, this would
just be nice to have as well.

cls

Re: [dev] [dwm] dual screen issue - windows not starting in current monitor

[Martti Kühne]

On Wed, Apr 04, 2012 at 07:48:16PM -0400, Lee Fallat wrote:
>I have been recently using dwm with two screens, and it doesn't allow
>me to start programs on another screen other than the one that is
>claimed to be 'primary' (which I specified in nvidia-settings). The
>'blue bar' follows what screen my mouse is on, and dmenu starts on the
>current screen too, but programs spawned with alt+shift+enter or dmenu
>are spawned in the 'primary window' .
>Here is the irc log for further details:
>[1]http://pastebin.com/raw.php?i=WV2LqwQp
>If there are any questions, please ask!
> 
> References
> 
>1. http://pastebin.com/raw.php?i=WV2LqwQp

cleaning up my own dwm patches here, I have patched dwm to take the current
monitor index, because the software does not keep track of these things
anywhere else.

dmenu patch [1] against current tip 487 -- makes dmenu take a cli argument
about what screen it is supposed to use. said screen will be inherited by the
started application unless otherwise specified by a rule.
dwm launcher function [2] against current tip 1599 that passes the current
monitor accordingly. I hooked it up with a key combo.

patches to your terminal emulator would be possible likewise.

cheers!
mar77i

[1] http://ix.io/2iR
[2] http://ix.io/2iS

Re: [dev] situ — change files in situ

[Strake]

On 13/04/2012, Connor Lane Smith  wrote:
> On 13 April 2012 16:37, Strake  wrote:
>> True, if we trim the start and finish lazily
>
> That depends on the diff format. diff -e, for example, could work well.

I meant to trim pre-diff, so it would be quadratic in a lesser argument.

>> but worst-case diff
>> algorithm space usage is worse — quadratic, if I'm not mistaken.
>
> That's true. Although, diff is worst-case quadratic in the number of
> lines, not bytes.

True for line-by-line diff, e.g. Unix diff, though the algorithm is
more general.

> And the fact is the worst-case can be avoided: we
> don't really *need* the longest common subsequence, only an
> approximation to it. If we exceed some threshold we can simply
> 'plump'.

You mean, to terminate the subsequence, and start afresh?

> To be clear, I don't mean to dismiss either existing situ, this would
> just be nice to have as well.

Noted.

Cheers,
strake

[dev] [dwm] strange issue with gedit and multiple screens

[Martti Kühne]

hello there

after whining earlier on irc, I've got to put things straight here.
I have two monitors and most of the time I don't really care where the mouse
pointer is. using dwm with multiple monitors works great, as there is the
focusmon function, which I have assigned to a key to switch between monitors.

The issue I was having with gedit was this: every now and then, gedit would
refuse to display a text cursor when I use the mouse to point, click and, at
the same time, get focus from a different screen. The only way of knowing where
in the text the cursor was, was to blindly type something or press the focusmon
key twice, which worked as a workaround for the issue.

In the course of debugging this I also noticed the same can be achieved when
the focusmon key is used to switch to a window on the other screen and follow
with the mouse and come back again, returning focus to the screen where gedit
runs. Again, input is taken, blue border is drawn, but no text cursor is shown.

Well, I can imagine that it's easy to blame gedit for that inconsistency,
apparently qt applications do not suffer from this.

Anyway, looking at dwm's codebase it isn't really clear when focus() is called,
selmon is set and unfocus is called, and, focus() itself calls unfocus and sets
selmon just in case. Needless to say, it made debugging a horrible task here.

I have tried quite a lot of things which ultimately lead to the desired
behavior, and then tested things hunkwise to find the culprit after all;
turns out it's my regular use of focusmon() which actually triggers the bug in
the first place; the change that solved my issues can be found in [1].

tl:dr; improve focus behavior of at least anjuta and gedit [1]

cheers!
mar77i

[1] http://ix.io/2iT

Re: [dev] situ — change files in situ

[Truls Becken]

There is also sponge from http://kitenet.net/~joey/code/moreutils/

-Truls

Re: [dev] situ — change files in situ

[Strake]

On 13/04/2012, Truls Becken  wrote:
> There is also sponge from http://kitenet.net/~joey/code/moreutils/

which would also corrupt file on failure, by what little documentation
I can read through the markup.

Re: [dev] situ — change files in situ

[Truls Becken]

On Fri, Apr 13, 2012 at 19:50, Strake wrote:

>> There is also sponge from http://kitenet.net/~joey/code/moreutils/
>
> which would also corrupt file on failure, by what little documentation
> I can read through the markup.

You are right. I thought that since it only opens the output file
after stdin is fully consumed, it would not touch the file on failure.
The test below reveals that sponge leaves the file alone if the
process is interrupted before end of stdin, but not if a program
before it in the pipe returns non-zero.

I guess I should test programs before suggesting them to others.

-Truls

$ echo TEST > tst
$ (sed s/ES/se tst; sleep 10) | sponge tst
sed: -e expression #1, char 7: unterminated `s' command
^C
$ cat tst
TEST
$ sed s/ES/se tst | sponge tst
sed: -e expression #1, char 7: unterminated `s' command
$ wc tst
0 0 0 tst
$

Re: [dev] situ — change files in situ

[Strake]

On 13/04/2012, Truls Becken  wrote:
> You are right. I thought that since it only opens the output file
> after stdin is fully consumed, it would not touch the file on failure.
> The test below reveals that sponge leaves the file alone if the
> process is interrupted before end of stdin, but not if a program
> before it in the pipe returns non-zero.
>
> I guess I should test programs before suggesting them to others.

(^_^)

Actually, it's not wrong — it would do the job, i.e. to mutate file in
situ — it's just not quite sure enough.

Cheers,
strake

Re: [dev] [dwm] dual screen issue - windows not starting in current monitor

[Lee Fallat]

Wow, thank you! I will apply this later tonight and get back to you.

On Fri, Apr 13, 2012 at 12:28 PM, Martti Kühne  wrote:

> On Wed, Apr 04, 2012 at 07:48:16PM -0400, Lee Fallat wrote:
> >I have been recently using dwm with two screens, and it doesn't allow
> >me to start programs on another screen other than the one that is
> >claimed to be 'primary' (which I specified in nvidia-settings). The
> >'blue bar' follows what screen my mouse is on, and dmenu starts on the
> >current screen too, but programs spawned with alt+shift+enter or dmenu
> >are spawned in the 'primary window' .
> >Here is the irc log for further details:
> >[1]http://pastebin.com/raw.php?i=WV2LqwQp
> >If there are any questions, please ask!
> >
> > References
> >
> >1. http://pastebin.com/raw.php?i=WV2LqwQp
>
> cleaning up my own dwm patches here, I have patched dwm to take the current
> monitor index, because the software does not keep track of these things
> anywhere else.
>
> dmenu patch [1] against current tip 487 -- makes dmenu take a cli argument
> about what screen it is supposed to use. said screen will be inherited by
> the
> started application unless otherwise specified by a rule.
> dwm launcher function [2] against current tip 1599 that passes the current
> monitor accordingly. I hooked it up with a key combo.
>
> patches to your terminal emulator would be possible likewise.
>
> cheers!
> mar77i
>
> [1] http://ix.io/2iR
> [2] http://ix.io/2iS
>
>