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 ano
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
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 st
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.
There is also sponge from http://kitenet.net/~joey/code/moreutils/
-Truls
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
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
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' foll
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 quadrat
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
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
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
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 c
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 tha
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
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
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 Pan
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
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
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
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 switc
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'
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?
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
24 matches
Mail list logo
