Re: [dev] curses samterm

2010-08-04 Thread markus schnalke
[2010-08-03 16:30] Joe joebsulli...@gmail.com
 [08/03/10] @11:28AM PDT, mei...@marmaro.de wrote: 
  [2010-08-03 10:14] Joe joebsulli...@gmail.com
   NAME
  ed - text editor
   
   SYNOPSIS
  ed [-] [-sx] [-p string] [file]
  
  It should be: ed [-] [file]
 
 I concur. fwd: sj...@apple.com.  
 My only other choice is 9 man ed:
  SYNOPSIS
   ed [ - ] [ -o ] [ file ]
 or Google:
  ed [-] [-Gs] [-p string] [file]
  ed [ - ] [ -x ] [ name ]
  ed [-] [-Esx] [-p string] [file]
  ed [-s | -] [-p string] [-x] [-C] [file]

You see, the dash is the only options provided by all implementations,
except First Editon.


meillo



Re: [dev] curses samterm

2010-08-03 Thread Wolf Tivy
  Luxuries like syntax coloring would be nice but really not critical.
 Would you like reading a book with all adjectives bolded and 
 nouns italicized?
 You may want to take a look at ALGOL 68.

I hadn't thought of it like that before. Good point.
Excuse me while I also remove indentation from my my code.
Would you indent your prose? What nonsense have
I been practicing?

Thanks.



Re: [dev] curses samterm

2010-08-03 Thread Robert Ransom
On Tue, 03 Aug 2010 00:20:39 -0700
Wolf Tivy wti...@my.bcit.ca wrote:

 Excuse me while I also remove indentation from my my code.
 Would you indent your prose?

http://google.com/search?q=sense-lining

Robert Ransom


signature.asc
Description: PGP signature


Re: [dev] curses samterm

2010-08-03 Thread Joseph Xu

On 8/3/2010 12:41 AM, Wolf Tivy wrote:

I find it useful to be able to edit files using my regular editor
after I break X, or if I don't feel like starting it up.


X doesn't break that often for me.


I like curses stuff even in X because it is nice to open up an editor
and have it tempoarily reuse the terminal window without spawning
another and thrashing my layout. Furthermore, as a bit of an


Usually I'll have acme always running and just plumb stuff to it. 
Actually you can almost live inside acme like you can live inside emacs.



aesthetic concern, curses editors inherit the color configuration of
the terminal, which is convienient if you are into making things look
nice.

It was suggested before that a curses interface would be a good
idea, so I am assuming that I am not the only person who would
appreciate it.


Very few people use sam to begin with, even fewer would like the curses 
interface. I'm guessing no more than 20 people.




I might be happy with the p9p samterm, but I can't figure out how
to get it standalone from the rest of p9p, or what kind of


Not sure you can. Why don't you want p9p? It's got a lot of cool stuff 
in it.



aesthetic variations are possible (font?, color?). These issues are


I think you can change the font by setting the font environment 
variable, but there's no syntax highlighting because Pike doesn't like 
it. I used to think that was an important feature also, but after using 
acme for a while I don't miss it at all. I also don't miss wasting a lot 
of time obsessively trying to write highlighting scripts for custom 
languages in vim.



not that big on thier own, but combined with the whole X-dependant
thing, it just doesn't seem worth it.

So that's my view on why a curses samterm is a good idea.
If noone is interested, I will survive with nano, but if people are


Why don't you just use vim? It meets all your requirements and like sam 
has ed-style commands.



interested or if someone has started, I'm willing to throw some
time at it.

- Original Message -
From: Joseph Xujoseph...@gmail.com
Date: Monday, August 2, 2010 5:30 pm
Subject: Re: [dev] curses samterm
To: dev@suckless.org


Under what circumstance would you not be able to run sam's gui
and have
to resort to a curses interface? sam already provides a way to
connect
the gui to a remote host via ssh to edit files over a slow
connection.
I've even done this with an old Windows port of sam running
locally and
a remote linux host with p9p sam. So the only reason is if you
don't
want to run X on your local computer, which seems ridiculous
nowadays.
Rob Pike wrote sam in part because he didn't like having to
cursor
around in vi.







Re: [dev] curses samterm

2010-08-03 Thread hiro
Fortune worthy:

X doesn't break that often for me.
--Joseph Xu, 8/3/10



Re: [dev] curses samterm

2010-08-03 Thread Uriel
On Tue, Aug 3, 2010 at 6:41 AM, Wolf Tivy wti...@my.bcit.ca wrote:
 I find it useful to be able to edit files using my regular editor
 after I break X, or if I don't feel like starting it up.
 I like curses stuff even in X because it is nice to open up an editor
 and have it tempoarily reuse the terminal window without spawning
 another and thrashing my layout. Furthermore, as a bit of an
 aesthetic concern, curses editors inherit the color configuration of
 the terminal, which is convienient if you are into making things look
 nice.

 It was suggested before that a curses interface would be a good
 idea, so I am assuming that I am not the only person who would
 appreciate it.

 I might be happy with the p9p samterm, but I can't figure out how
 to get it standalone from the rest of p9p, or what kind of

Sam has run on lunix since long before p9p existed. apt-get install
sam should work, it is a somewhat old version of sam, but all the
functionality should be there.

 aesthetic variations are possible (font?, color?). These issues are
 not that big on thier own, but combined with the whole X-dependant
 thing, it just doesn't seem worth it.

 So that's my view on why a curses samterm is a good idea.
 If noone is interested, I will survive with nano, but if people are
 interested or if someone has started, I'm willing to throw some
 time at it.

Anyone that considers for even one second to use nano should be taken
out and shot on the spot.

uriel

 - Original Message -
 From: Joseph Xu joseph...@gmail.com
 Date: Monday, August 2, 2010 5:30 pm
 Subject: Re: [dev] curses samterm
 To: dev@suckless.org

 Under what circumstance would you not be able to run sam's gui
 and have
 to resort to a curses interface? sam already provides a way to
 connect
 the gui to a remote host via ssh to edit files over a slow
 connection.
 I've even done this with an old Windows port of sam running
 locally and
 a remote linux host with p9p sam. So the only reason is if you
 don't
 want to run X on your local computer, which seems ridiculous
 nowadays.
 Rob Pike wrote sam in part because he didn't like having to
 cursor
 around in vi.






Re: [dev] curses samterm

2010-08-03 Thread Robert Ransom
On Tue, 3 Aug 2010 12:01:24 +0200
Uriel ur...@berlinblue.org wrote:

 Anyone that considers for even one second to use nano should be taken
 out and shot on the spot.

It's not so bad if you build it with the --disable-wrapping-as-root
configure option and only use it as root.



In case you're wondering why I know *that*, nano is the least bad
editor on the standard Arch Linux install CD image (the others are joe
and traditional, breaks-if-you-push-a-cursor-key-in-insert-mode vi;
I'd be happy with ed, but they didn't provide it), and I just peeked at
the PKGBUILD to see if the Arch folks had needed to patch /etc/nanorc
to make it stop mangling long lines.  Apparently not...

Robert Ransom


signature.asc
Description: PGP signature


Re: [dev] curses samterm

2010-08-03 Thread Uriel
On Tue, Aug 3, 2010 at 12:26 PM, Robert Ransom rransom.8...@gmail.com wrote:
 On Tue, 3 Aug 2010 12:01:24 +0200
 Uriel ur...@berlinblue.org wrote:

 Anyone that considers for even one second to use nano should be taken
 out and shot on the spot.

 It's not so bad if you build it with the --disable-wrapping-as-root
 configure option and only use it as root.



 In case you're wondering why I know *that*, nano is the least bad
 editor on the standard Arch Linux install CD image (the others are joe
 and traditional, breaks-if-you-push-a-cursor-key-in-insert-mode vi;
 I'd be happy with ed, but they didn't provide it),

What the fuck?!?!? Everyone involved in the development of lunix
distributions that don't include ed as one of its most core programs
should have their liver devoured by harpies and their testicles
infested by maggots for the rest of eternity, Prometheus-style.

uriel

 and I just peeked at
 the PKGBUILD to see if the Arch folks had needed to patch /etc/nanorc
 to make it stop mangling long lines.  Apparently not...

 Robert Ransom




Re: [dev] curses samterm

2010-08-03 Thread Jacob Todd
On Tue, Aug 03, 2010 at 12:20:39AM -0700, Wolf Tivy wrote:
 I hadn't thought of it like that before. Good point.
 Excuse me while I also remove indentation from my my code.
 Would you indent your prose? What nonsense have
 I been practicing?
I do indent my prose, by using paragraphs.
 
 Thanks.
 


pgp7kfhqHzmtE.pgp
Description: PGP signature


Re: [dev] curses samterm

2010-08-03 Thread Connor Lane Smith
Hey,

On 3 August 2010 09:50, Joseph Xu joseph...@gmail.com wrote:
 Very few people use sam to begin with, even fewer would like the curses
 interface. I'm guessing no more than 20 people.

The best reason not to write a program ever: nobody is using it yet.

 Usually I'll have acme always running and just plumb stuff to it. Actually
 you can almost live inside acme like you can live inside emacs.

Yes, indeed. Both acme and samterm ship with their very own window
manager, so you can fullscreen acme in rio and pretend you're using
wmii. And samterm is even worse: a stacking window manager within a
stacking window manager (so you can stack while you stack).

There is a good reason why a curses samterm would be useful: the
standard one is a joke. I have not found any program in which it is
slower to do work. With dwm and vim you can manage development tasks
using nothing but muscle memory. With sam you have to move term,
resize term, move flayer, resize flayer, position cursor, insert some
text, move the cursor horizontally but never vertically...

But I'd much prefer a sane curses samterm to vim, since (as I
mentioned during one of our many flame wars) I dislike its modality
and its tendency to work completely differently on each machine. And
sam, after all, has lovely things like structural regular expressions.

(But let's not have another flame war.)

I have looked into making a curses samterm before, but it's
complicated by the fact that the standard samterm is coded in a
ridiculously cryptic way. Sorry Rob, but what on earth. I'm sure there
must be internal Bell Labs documentation on that thing. I think step
one in writing a new samterm is to work out exactly how the sam
protocol works (I have a fair idea), and to write a new client
implementation from scratch, not just borrowing from samterm/mesg.c.

Thanks,
cls



Re: [dev] curses samterm

2010-08-03 Thread Connor Lane Smith
Hey,

On 3 August 2010 17:43, Joseph Xu joseph...@gmail.com wrote:
 I said I'm guessing no more than 20 people will find it useful if it was
 written.

I think in this case samterm is more important than sam itself when it
comes to attracting users. Few will convert to using sam if it is ugly
and tedious to use. An improved curses samterm could encourage people
to use sam who otherwise wouldn't because unlike us they aren't
backwards 9fans. No more than 20 of the current 20 people using sam
would find a new interface useful, certainly. ;)

 I agree the sam internal window manager is kind of ridiculous. Pike must
 have thought so too, since he made acme very differently.

True, though he made acme manage windows too, so he clearly didn't
change his mind about that. A possibility could be to make the command
window set up a socket to which other windows can connect, so then you
can manage windows with ^Z / screen / xterms / tabbed, without having
to build it into samterm itself.

 The inability to
 move the cursor up and down lines is weird too, I think that has to do with
 the fact that internally both sam and acme represent buffers as streams of
 characters rather than lines. At least that's my understanding.

I believe you're right. I think this is also why the rio scrollbars
act strangely. Storing the buffer as a linked list of lines would make
it quite a bit simpler.

Thanks,
cls



Re: [dev] curses samterm

2010-08-03 Thread Wolf Tivy
 Yes, indeed. Both acme and samterm ship with their very own window
 manager, so you can fullscreen acme in rio and pretend you're using
 wmii. And samterm is even worse: a stacking window manager 
 within a
 stacking window manager (so you can stack while you stack).
 
 There is a good reason why a curses samterm would be useful: the
 standard one is a joke. I have not found any program in which it is
 slower to do work. With dwm and vim you can manage development tasks
 using nothing but muscle memory. With sam you have to move term,
 resize term, move flayer, resize flayer, position cursor, insert some
 text, move the cursor horizontally but never vertically...
 
 But I'd much prefer a sane curses samterm to vim, since (as I
 mentioned during one of our many flame wars) I dislike its modality
 and its tendency to work completely differently on each machine. And
 sam, after all, has lovely things like structural regular expressions.

I'm glad that I'm not the only one who feels this way. I find vi(m) to be
totally incomprehensible, though. I find even sam -d to be easier than
vi(m). Mostly because the command set in sam is so good.

 I have looked into making a curses samterm before, but it's
 complicated by the fact that the standard samterm is coded in a
 ridiculously cryptic way. Sorry Rob, but what on earth. I'm sure there
 must be internal Bell Labs documentation on that thing. I think step
 one in writing a new samterm is to work out exactly how the sam
 protocol works (I have a fair idea), and to write a new client
 implementation from scratch, not just borrowing from samterm/mesg.c.

Then the totally new samterm is the way to go. Especially
considering that the interface should be totally different
(like I mentioned earlier).

How different is the protocol from sam -d? I will have to do
some reading. Now that I know there is at least one other
person interested, I might do some more serious thinking
and see what I can code up.



Re: [dev] curses samterm

2010-08-03 Thread markus schnalke
[2010-08-03 10:14] Joe joebsulli...@gmail.com
 
 ED(1)ED(1)
 NAME
ed - text editor
 
 SYNOPSIS
ed [-] [-sx] [-p string] [file]

It should be: ed [-] [file]


meillo



Re: [dev] curses samterm

2010-08-03 Thread hiro
 ED(1)
 ED(1)
 NAME
ed - text editor

 SYNOPSIS
ed [-] [-sx] [-p string] [file]

 DESCRIPTION
ed is a line-oriented text editor.  It is used to create, display,
 mod-
ify and otherwise manipulate text files.

 WARNING
   Everyone involved in the development of lunix distributions that don't
   include ed as one of its most core programs should have their liver
   devoured by harpies and their testicles infested by maggots for the
   rest of eternity, Prometheus-style.



Pathetic synopsis



Re: [dev] curses samterm

2010-08-03 Thread Evan Gates
 So on that note, it looks like curses is the way to go (as has been
 previously suggested). Then the issue is how closely our curses
 samterm would resemble bitmap samterm. Considering all the clicky
 menus and scrollbars and such, it may be best for the curses interface
 to be a totally different design.

Curses does support mouse use at this point, and seeing as the use of
the mouse to select text is one of the big features of sam, I think
it'd be important to keep that. Instead of using the menu, the options
from it could all be mapped to single or chorded keystrokes of the
left hand (user defined mappings so lefties, righties, and users of
any keyboard would be happy...). The biggest question I feel is what
to do about the command window vs file windows. My first thought is
that we're headed towards a modal editor like vi, but then you can no
longer select and edit text from the command window or paste into
different files unless you have separate windows open in curses or
use a clipboard outside of sam. Which brings my second thought of
actually having a separate command window in the curses interface
instead of being modal. Problem is, neither of these sound like a good
way of going about it. Any ideas?

-emg



Re: [dev] curses samterm

2010-08-03 Thread Joe
[08/03/10] @11:28AM PDT, mei...@marmaro.de wrote: 
 [2010-08-03 10:14] Joe joebsulli...@gmail.com
  NAME
 ed - text editor
  
  SYNOPSIS
 ed [-] [-sx] [-p string] [file]
 
 It should be: ed [-] [file]

I concur. fwd: sj...@apple.com.  
My only other choice is 9 man ed:
 SYNOPSIS
  ed [ - ] [ -o ] [ file ]
or Google:
 ed [-] [-Gs] [-p string] [file]
 ed [ - ] [ -x ] [ name ]
 ed [-] [-Esx] [-p string] [file]
 ed [-s | -] [-p string] [-x] [-C] [file]

It's the *standard* text editor.

Sanity, alas:
http://man.cat-v.org/unix-1st/1/ed



Re: [dev] curses samterm

2010-08-03 Thread Jacob Todd
On Tue, Aug 03, 2010 at 04:29:34PM -0700, Wolf Tivy wrote:
 My current idea is just to have the screen displaying the file (where?)
 with dot highlighted. A few lines at the bottom would have
 the command line, maybe it would dynamically adjust for multiline
 commands, I dunno. You could cursor around using arrows or
 mouse (how do we scroll with mouse) or whatever to select the
 dot.
Sounds like vi.


pgpAgKcRuQeoS.pgp
Description: PGP signature


Re: [dev] curses samterm

2010-08-03 Thread Wolf Tivy
 Sounds like vi.

except with a clean command set and less legacy baggage.




[dev] curses samterm

2010-08-02 Thread Wolf Tivy
I noticed there is a project for a samterm on the project ideas page.
Has anyone started on this? It seems like a really good idea.

I guess ideally it would be usable without X (in text mode) but would
still keep the nice view and selection interface.
Luxuries like syntax coloring would be nice but really not critical.

So on that note, it looks like curses is the way to go (as has been
previously suggested). Then the issue is how closely our curses
samterm would resemble bitmap samterm. Considering all the clicky
menus and scrollbars and such, it may be best for the curses interface
to be a totally different design.

With that in mind, does anyone have good ideas for a curses samterm
interface?

I am enthusiastic about this project and I'd be willing to help, but I have
never touched any curses code and my only familiarity with sam is
the papers and an occasional sam -d.



Re: [dev] curses samterm

2010-08-02 Thread Joseph Xu
Under what circumstance would you not be able to run sam's gui and have 
to resort to a curses interface? sam already provides a way to connect 
the gui to a remote host via ssh to edit files over a slow connection. 
I've even done this with an old Windows port of sam running locally and 
a remote linux host with p9p sam. So the only reason is if you don't 
want to run X on your local computer, which seems ridiculous nowadays. 
Rob Pike wrote sam in part because he didn't like having to cursor 
around in vi.


On 8/2/2010 6:15 PM, Wolf Tivy wrote:

I noticed there is a project for a samterm on the project ideas page.
Has anyone started on this? It seems like a really good idea.

I guess ideally it would be usable without X (in text mode) but would
still keep the nice view and selection interface.
Luxuries like syntax coloring would be nice but really not critical.

So on that note, it looks like curses is the way to go (as has been
previously suggested). Then the issue is how closely our curses
samterm would resemble bitmap samterm. Considering all the clicky
menus and scrollbars and such, it may be best for the curses interface
to be a totally different design.

With that in mind, does anyone have good ideas for a curses samterm
interface?

I am enthusiastic about this project and I'd be willing to help, but I have
never touched any curses code and my only familiarity with sam is
the papers and an occasional sam -d.





Re: [dev] curses samterm

2010-08-02 Thread Joseph Xu

On 8/2/2010 6:15 PM, Wolf Tivy wrote:

I noticed there is a project for a samterm on the project ideas page.
Has anyone started on this? It seems like a really good idea.

I guess ideally it would be usable without X (in text mode) but would
still keep the nice view and selection interface.
Luxuries like syntax coloring would be nice but really not critical.

So on that note, it looks like curses is the way to go (as has been
previously suggested). Then the issue is how closely our curses
samterm would resemble bitmap samterm. Considering all the clicky
menus and scrollbars and such, it may be best for the curses interface
to be a totally different design.

With that in mind, does anyone have good ideas for a curses samterm
interface?

I am enthusiastic about this project and I'd be willing to help, but I have
never touched any curses code and my only familiarity with sam is
the papers and an occasional sam -d.



Under what circumstance would you not be able to run sam's gui and have 
to resort to a curses interface? sam already provides a way to connect 
the gui to a remote host via ssh to edit files over a slow connection. 
I've even done this with an old Windows port of sam running locally and 
a remote linux host with p9p sam. So the only reason is if you don't 
want to run X on your local computer, which seems ridiculous nowadays. 
Rob Pike wrote sam in part because he didn't like having to cursor 
around in vi.




Re: [dev] curses samterm

2010-08-02 Thread Wolf Tivy
I find it useful to be able to edit files using my regular editor
after I break X, or if I don't feel like starting it up.
I like curses stuff even in X because it is nice to open up an editor
and have it tempoarily reuse the terminal window without spawning
another and thrashing my layout. Furthermore, as a bit of an
aesthetic concern, curses editors inherit the color configuration of
the terminal, which is convienient if you are into making things look
nice.

It was suggested before that a curses interface would be a good
idea, so I am assuming that I am not the only person who would
appreciate it.

I might be happy with the p9p samterm, but I can't figure out how
to get it standalone from the rest of p9p, or what kind of
aesthetic variations are possible (font?, color?). These issues are
not that big on thier own, but combined with the whole X-dependant
thing, it just doesn't seem worth it.

So that's my view on why a curses samterm is a good idea.
If noone is interested, I will survive with nano, but if people are
interested or if someone has started, I'm willing to throw some
time at it.

- Original Message -
From: Joseph Xu joseph...@gmail.com
Date: Monday, August 2, 2010 5:30 pm
Subject: Re: [dev] curses samterm
To: dev@suckless.org

 Under what circumstance would you not be able to run sam's gui 
 and have 
 to resort to a curses interface? sam already provides a way to 
 connect 
 the gui to a remote host via ssh to edit files over a slow 
 connection. 
 I've even done this with an old Windows port of sam running 
 locally and 
 a remote linux host with p9p sam. So the only reason is if you 
 don't 
 want to run X on your local computer, which seems ridiculous 
 nowadays. 
 Rob Pike wrote sam in part because he didn't like having to 
 cursor 
 around in vi.