Hello,
Here is an interesting and relevant talk on suckless design:
"Making Apps That Don't Suck" by Mike Lee on May 20, 2011 (~1hr)
http://www.infoq.com/presentations/Making-Apps-That-Dont-Suck
Cheers.
--
In less than a century, computers will be making substantial
progress on ... the overrid
The input box should handle binary streams, buffered input, file contents and
editing line with special program.
All this can be done by running another st with vim f.ex
This sounds to me like replicating work.. A microwm.. 2 terminals.. Keyboard
handling for switching modes.. We will make then
On 20 May 2011 23:42, Connor Lane Smith wrote:
> > Another feature which would be nice would be stripping of leading /
> > and .. from path names when creating and extracting archives.
Oh, I didn't do the '..' bit though. I couldn't be bothered,
basically. Shouldn't be too difficult, though, with
On 20 May 2011 21:51, Nick wrote:
> One thing which could be considered would be allowing specifying
> file / directory names on argv.
> Another feature which would be nice would be stripping of leading /
> and .. from path names when creating and extracting archives.
Attached!
I also fixed a b
Quoth Connor Lane Smith:
> I've written a quick patch for sltar which lets you create archives as
> well as extract and list them. (It reads the files' paths in through
> stdin.) I've not tested it extensively, but it seems to work well.
> Maybe Enno could apply it to the sltar repo?
Well really,
On Fri, 20 May 2011, Connor Lane Smith wrote:
On 20 May 2011 19:58, Benjamin R. Haskell wrote:
dwm's focus rules still surprise me sometimes (mainly in monocle mode
where urxvt doesn't occupy the entire screen, due to the screen not
being evenly divisible by character cells).
static const Bo
On 20 May 2011 19:58, Benjamin R. Haskell wrote:
> dwm's focus rules still surprise me sometimes (mainly in monocle mode where
> urxvt doesn't occupy the entire screen, due to the screen not being evenly
> divisible by character cells).
static const Bool resizehints = False;
;)
cls
Subject: Re: [dwm] TermKitjkjkjn
dwm's focus rules still surprise me sometimes (mainly in monocle mode
where urxvt doesn't occupy the entire screen, due to the screen not
being evenly divisible by character cells). The jkjkjn tacked on to the
subject there was me trying to 'shake' an apparen
On Fri, May 20, 2011 at 2:46 PM, Benjamin R. Haskell
wrote:
> Why would you escape the asterisks here? It's not looking for literal
> asterisks.
Oops, you wouldn't. But, knowing the output format of history, I'd
change the asterisks to \+, which does require escaping in sed, which
is the half of
On Fri, 20 May 2011, Andrew Hills wrote:
On Fri, May 20, 2011 at 2:06 PM, Kurt H Maier wrote:
> [...] wouldn't something akin to
>
> history | sort -r | sed '1d; s/^[ \t]*[0-9]*[ \t]*//'
>
> work just as well?
Didn't realize `sed` didn't have \d, but why [ \t] instead of \s?
[...] (Don't
On Fri, 20 May 2011, Andrew Hills wrote:
On Fri, May 20, 2011 at 2:06 PM, Kurt H Maier wrote:
[...] wouldn't something akin to
history | sort -r | sed '1d; s/^[ \t]*[0-9]*[ \t]*//'
work just as well?
Didn't realize `sed` didn't have \d, but why [ \t] instead of \s?
[...] (Don't forget to
On Fri, May 20, 2011 at 2:22 PM, Kurt H Maier wrote:
> I just pasted the output of TermKit.
Something tells me to suspect that this is untrue.
--Andrew Hills
On Fri, May 20, 2011 at 2:21 PM, Andrew Hills wrote:
> (Don't forget to escape your asterisks in sed.)
I just pasted the output of TermKit.
--
# Kurt H Maier
On Fri, May 20, 2011 at 2:06 PM, Kurt H Maier wrote:
> Any reason not to sort(1) them before you feed them to perl? And
> don't get me wrong: perl is my favorite language, but wouldn't
> something akin to
>
> history | sort -r | sed '1d; s/^[ \t]*[0-9]*[ \t]*//'
>
> work just as well?
Yes. When
On Fri, 20 May 2011, Kurt H Maier wrote:
Any reason not to sort(1) them before you feed them to perl? And
don't get me wrong: perl is my favorite language, but wouldn't
something akin to
history | sort -r | sed '1d; s/^[ \t]*[0-9]*[ \t]*//'
work just as well?
I would've changed it to use
On Fri, May 20, 2011 at 1:42 PM, Andrew Hills wrote:
> Not supported by default on Solaris 5.8, Solaris 5.10, RHEL 4(NU7),
> RHEL 5.6, or Arch Linux (updated an hour ago). According to [0], only
> BSD tail has the reverse option.
Any reason not to sort(1) them before you feed them to perl? And
On Fri, May 20, 2011 at 1:23 PM, Benjamin R. Haskell
wrote:
> Anyone know what `tail`s support '-r' ( == reverse? )?
Not supported by default on Solaris 5.8, Solaris 5.10, RHEL 4(NU7),
RHEL 5.6, or Arch Linux (updated an hour ago). According to [0], only
BSD tail has the reverse option.
0. http:
On Fri, 20 May 2011, Andrew Hills wrote:
Thanks for the Perl-readability tip.
No prob.
On Fri, May 20, 2011 at 12:58 PM, Benjamin R. Haskell wrote:
Don't have `tac` installed? (I think it's in linux-utils or
core-utils, but maybe it's linux- and/or GNU-centric.)
I do most of my work on
Thanks for the Perl-readability tip.
On Fri, May 20, 2011 at 12:58 PM, Benjamin R. Haskell
wrote:
> Don't have `tac` installed? (I think it's in linux-utils or core-utils, but
> maybe it's linux- and/or GNU-centric.)
I do most of my work on Solaris, and it's not really worth the effort
to insta
On Fri, 20 May 2011, Andrew Hills wrote:
On Fri, May 20, 2011 at 12:16 PM, Suraj N. Kurapati wrote:
history | xmessage -file - &
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i>=0;$i--){print $o[$i];}' | dmenu -b
On Fri, May 20, 2011 at 12:47 PM, Bjartur Thorlacius
wrote:
> I'm sorry for my total lack of 1337ness, but what does the perl part do?
Strips the numbers off the start of each line, reverses the order (for
most recent first), and skips the first (last) entry (which is the
command you typed to bri
On 5/20/11, Andrew Hills wrote:
> I keep this ugly mess around in for convenience:
>
> h()
> {
> `history | perl -e 'while(){s/\s+\d+\s+//;push
> @o,$_;}for($i=$#o-1;$i>=0;$i--){print $o[$i];}' | dmenu -b`
> }
I'm sorry for my total lack of 1337ness, but what does the perl part do?
On 20 May 2011 17:24, Suraj N. Kurapati wrote:
> Use /dev/tty to "draw" to the terminal independently of std streams:
>
> date | sh -c 'read; echo "$REPLY" > /dev/tty' >/dev/null
Your graphics look suspiciously like text.
(I think you missed the point.)
cls
On Fri, May 20, 2011 at 12:16 PM, Suraj N. Kurapati wrote:
> history | xmessage -file - &
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i>=0;$i--){print $o[$i];}' | dmenu -b`
}
--Andrew Hills
On Fri 20 May 2011 01:26:56 PM PDT, Connor Lane Smith wrote:
> allow commands to draw directly to the terminal if they wanted. So
> the standard input / output piping system would remain unchanged,
Use /dev/tty to "draw" to the terminal independently of std streams:
date | sh -c 'read; echo "$R
On Fri 20 May 2011 12:51:35 PM PDT, David Tweed wrote:
> At the very least, it would be very productive to [... have] the
> _option_ for shell history to pop up in another window, rather
> than _only_ being available as a command output, so that it
> scrolls other stuff you've been doing off the sc
Hi all,
In the current version of st, when invoked with the -t option, it
would map the window before setting its title, which would prevent dwm
(or any other dynamic wm) from matching its rules against it. Here's a
patch that fixed the thing for me:
diff -r 1eb3e1b6a8d0 st.c
--- a/st.c Sat
That font encoding is pretty arbitrary - I chose the encoding that
Tamsyn already carried. I don't require too much more than ASCII
due to my locale (en_US), so I stuck with en_US.ISO8859-1. If
you needed to, you could copy the glyphs over into another font,
say Terminus, that has better support fo
2011/5/20 Hadrian Węgrzynowski :
> Sometimes I would like to display some graphics inside terminal window.
> We could draw directly in terminal's window or place graphics inline
> with text. I would prefer second method.
I think the way I described it in my first email was a little
confusing. As I
On Fri, May 20, 2011 at 03:19:00PM +0100, Connor Lane Smith wrote:
> On 20 May 2011 14:54, Kurt H Maier wrote:
> > I don't understand why. If you want stderr to be combined into
> > stdout, suffix 2>&1 to your command. By default, I think different
> > filehandles should land in different output
On Fri, May 20, 2011 at 5:55 PM, Bryan Bennett wrote:
> Eckehard is right - rehash your font library to see the changes.
>
> rehash is done via .xinitrc, I think that utf-8 locale is the reason, if I
switch to en_US.ISO-8859-1, I can echo Bryan font icons, when UTF-8 gives me
empty output or (?)
Eckehard is right - rehash your font library to see the changes.
Sometimes I would like to display some graphics inside terminal window.
We could draw directly in terminal's window or place graphics inline
with text. I would prefer second method.
One of the key features of text terminals is monospaced font - that
makes everything easier to align and easier to co
On Fri, May 20, 2011 at 10:19 AM, Connor Lane Smith wrote:
> I just think the stdout and stderr ought to be visible at the same
> time. Or perhaps it would suffice to show stderr above stdout, or
> automatically switch, or something.
I agree stderr ought to be visible. I picture either a smaller
On Fri, 20 May 2011 15:19:00 +0100
Connor Lane Smith wrote:
> On 20 May 2011 14:54, Kurt H Maier wrote:
> > I don't understand why. If you want stderr to be combined into
> > stdout, suffix 2>&1 to your command. By default, I think different
> > filehandles should land in different outputs.
>
On 20 May 2011 14:54, Kurt H Maier wrote:
> I don't understand why. If you want stderr to be combined into
> stdout, suffix 2>&1 to your command. By default, I think different
> filehandles should land in different outputs.
I just think the stdout and stderr ought to be visible at the same
time
On Fri, May 20, 2011 at 9:40 AM, Connor Lane Smith wrote:
> I suppose that could be a useful interface, so long as it was clear
> which commands are associated with which output. Otherwise stdout
> could get a little messy. Also, by default stdout and stderr ought to
> be combined, perhaps with st
On Fri, 20 May 2011 14:40:39 +0100
Connor Lane Smith wrote:
> On 20 May 2011 14:27, Dieter Plaetinck wrote:
> > I think a fd to write something to like "here's an image, please
> > render it somewhere" is better than cls's suggestion of having apps
> > directly write to the terminal. I think
On 20 May 2011 14:17, Kurt H Maier wrote:
> I've never understood why there isn't a terminal with one window per
> filehandle. Something like sam's interface, but the top window would
> just hold stdin and the bottom window should toggle between stdout and
> stderr.
I suppose that could be a use
How hard would it be to have fd 3 or 4 be a mmap'able image of the
window (like /dev/fb) && would this suck less?
On 20 May 2011 09:27, Dieter Plaetinck wrote:
> [...]
> 6)non sucky rendering. I think applications should be able to have
> pixel-precise control of what the output should be (othe
On Fri, 20 May 2011 12:51:35 +0100
David Tweed wrote:
> it always depresses me that it's
> kind of taken as a virtue that the interactive shell and the terminal
> are know almost nothing about each other (at least for almost all
> modern computing devices, I can see if you genuinely are using a
>
+ Connor Lane Smith ---+
>
> However, if the command would like it could communicate directly to
> the term and say "show this diagram", or whatever. The term would
> basically be an ever-downward-scrolling canvas, which shows mostly
> text but may o
On Thu, May 19, 2011 at 09:10:36PM +0200, Christian Neukirchen wrote:
> anonymous writes:
>
> > On Wed, May 18, 2011 at 04:45:24PM +0100, Connor Lane Smith wrote:
> >> I've just released dmenu-4.3, which is basically smaller and faster.
> >
> >> smaller and faster
> >
> >> faster
> >
> > For me i
It's on my working copy. Looks very promising, thank you ;)
Am 19.05.2011 um 20:15 schrieb Connor Lane Smith:
> Hey all,
>
> I've written a quick patch for sltar which lets you create archives as
> well as extract and list them. (It reads the files' paths in through
> stdin.) I've not tested it e
On Fri, May 20, 2011 at 1:26 PM, Connor Lane Smith wrote:
> fwiw, I agree. TermKit appears to be a very glossy turd, but there are
> certainly outstanding issues in our terminals, which is why in Plan 9
> they tried to fix them by pairing a plaintext-only Rio term with
> graphical windows which a
On Fri, May 20, 2011 at 9:01 AM, Aurélien Aptel
wrote:
> rxvt implements basic drawing primitives via escape codes[1]. It's
> disabled at compile time by default but you can find some poc in the
> source distribution that plots stuff. I think it has been dropped in
> urxvt. It's ok for very simple
On Fri, May 20, 2011 at 2:26 PM, Connor Lane Smith wrote:
> I think the way to solve this problem is not to add structure to pipes
> (which tend to be simple to use *because* they have no real
> structure), but to allow commands to draw directly to the terminal if
> they wanted. So the standard in
Hey,
On 20 May 2011 12:51, David Tweed wrote:
> Certainly the general implementation, the language and the
> architecture do seem nasty. OTOH, it always depresses me that it's
> kind of taken as a virtue that the interactive shell and the terminal
> are know almost nothing about each other
fwiw,
On Fri, May 20, 2011 at 10:06 AM, Nick wrote:
> On Fri, May 20, 2011 at 12:23:39AM +0200, hiro wrote:
>> https://github.com/unconed/TermKit
>>
>> no comment, only sorry.
>
> indeed. i read about it yesterday. makes me want to vomit.
>
>
Certainly the general implementation, the language and the
ar
> Thanks Bryan, your icons work, but only in my "terminal" not "xterm" when I
> choose Tamsyn2 font and echo -e "\xC1", however when I edited your font with
> my gbdfed, saved, reconverted, and put it into /usr/share/fonts/local/, ran
> my terminal and echo -e "\xA1"(my added icon) didn't show up,
On Fri, May 20, 2011 at 12:23:39AM +0200, hiro wrote:
> https://github.com/unconed/TermKit
>
> no comment, only sorry.
indeed. i read about it yesterday. makes me want to vomit.
On Fri, May 20, 2011 at 1:01 AM, Bryan Bennett wrote:
> I've done this previously (I have modified Tamsyn's 15pt version
> and released it on the arch forums as 'Tamsyn2') and it works
> very well - particularly in locales where you rarely use anything
> outside of the ASCII charset. The basic id
52 matches
Mail list logo
