Re: [9fans] What are you using Plan 9 for?

[刘宇宝 <liuyubao@yingmi.cn>]

[-- Attachment #1: Type: text/plain, Size: 6034 bytes --]

> I'd also add ctrl-x/c/v, and perhaps a prefix key to enter control codes.

> (I guess alt-x nnnn works already, but I know the keys.)

Some days ago I wanted to input "\r" in Rio term window, spent about half an hour to figure out what the prefix key was, or some special syntax in rc,  finally I gave up,  used "Ctrl-m" instead.

Regards,
Yubao Liu

________________________________
From: 9fans-bounces@9fans.net <9fans-bounces@9fans.net> on behalf of Ethan A. Gardener <eekee57@fastmail.fm>
Sent: Thursday, June 21, 2018 11:11 PM
To: 9fans@9fans.net
Subject: Re: [9fans] What are you using Plan 9 for?

On Thu, Jun 21, 2018, at 8:20 AM, Mart Zirnask wrote:
> On 21/06/2018, Ethan A. Gardener <eekee57@fastmail.fm> wrote:
> >... I no longer have a desk of
> > the right proportions to make mouse use comfortable, and can no longer bend
> > over a laptop for hours on end, (a Thinkpad with 3 buttons,) text editing in
> > Plan 9 has become unpleasant. I could patch Samterm and Rio to make it more
> > comfortable, but it's not worth it.
>
> Would you mind elaborating on these ideas?

Not at all. The first thing I would do is make it so Samterm keeps Sam's snarf buffer in sync with Rio's. I know it's sometimes useful to have the two separate buffers, but I so often want to copy between the editor and other windows that for me, it's an immense pain. An alternate, possibly better idea would be to add commands to Sam, equivalent to >cat>/dev/snarf and <cat</dev/snarf . I've only just thought of those commands, I think I'd try to implement them first, because synchronizing the snarf buffers is not entirely straightforward (if I remember right,) and menus...

Menus! Grarrr I hate you, go away! Not entirely, I like them when they remind me of stuff, but every time I use one I have to Stop. And. Look. At. It. Not wonderful when wanting to get on with the job, or to not lose my focus. It matters less now I'm trying to relax, but I have experienced pie menus and found them a brilliant solution to exactly this problem, up to a point.

I would not want to jam window lists (Sam's or Rio's) into an infinite series of pie menus because, speaking from experience, nesting pie menus beyond two levels more than negates the benefits. Given that I'd normally have pie menus with 8 elements, for the button-3 menus of both programs I'd have 5 elements in a semi-circle attached to the side of a normal vertical menu containing the window list. (It would have to warp the pointer so it comes up in the center of the pie (or half-pie), there's no point making a pie if it doesn't do that.)

I'd also add ctrl-x/c/v, and perhaps a prefix key to enter control codes. (I guess alt-x nnnn works already, but I know the keys.)

I think that's all my actual requirements for making Sam comfortable. It's window management is a little fussy, but it doesn't annoy me the way Acme's can. Acme makes assumptions about workflow which are only rarely valid in my usage, and I can't see how to improve it without scrapping its entire window system premise, and starting again. Sam might be improved with a simple paned arrangement, but not like acme in that the panes are relatively fixed. Still, I prefer overlapping windows on a small screen, despite the extra fuss of managing them. With the way my eyesight is going, that might soon be any screen. (That reminds me, I never did get around to porting ESpeak to Plan 9. It's supposedly C++, but IIRC the only actual C++ was in the RiscOS-specific parts. I remember very C-like code, anyway.)

Almost forgot: I also had an idea for a second control window for Sam. The idea is that you enter commands into it, but they're not executed immediately. Instead, when you button-2 click, the entire line is executed. In Acme, I found myself frequently re-using commands. This would make that easy in Sam too -- or easier, rather. You can already snarf and send, but snarfing isn't so quick -- see above. 9front added chording to Samterm, but it's not reliable when I use it; needs a bit of fixing.


Speaking of menus reminding me of stuff, sometimes I lc /bin/games to remind me what games exist, which was my primary use for a launcher menu in Linux. I don't play many of them often. I like Plan 9's hierarchical /bin. It's a shame it's not very simple to union mount more than one level in Plan 9.

>
> Something I've been thinking along the same lines:
> Inferno's shell allows one to add custom buttons to a shell window.
> See more here:
> http://debu.gs/entries/interlude-inferno-at-work

A fun idea. :) Acme is similarly flexible, of course, and my Forth junk definitely will be.

Remarking on parts of that article:

"After that, starting up Inferno and hitting command-F (to run Inferno full-screen) makes the Mac look like an Inferno terminal. Perfect! I can lie to myself about what’s actually running on the computer."
This is what I did with my Mac. :) I don't hate its native interface but it is a bit dumb. Before I ever started using Plan 9 on it, I tried Linux but it was more hassle than necessary, and some hardware didn't work. I put OS X back on, (10.4, one of the best versions,) used its control panel, wifi setup, and nothing else except the X server full-screen. It was the best of both worlds, I loved it! :) Later, I variously ran Inferno, P9P Acme, and drawterm full-screen, usually with an external mouse. (It doesn't do multi-touch.)

>
> This could be used to add shortcuts to common/more complicated text
> editing tasks in Inferno's sh + sam -d.
> I'm not sure if this would free one from using a 3-button mouse, though.

Didn't someone praise modern trackpads in this thread? In the dim and distant past, (at least a whole year ago,) I recall a multitouch patch appearing for P9P. I think it entirely eliminated the need for a 3-button mouse. I'm sure it could be reasonably applied to Inferno, and to Drawterm if it hasn't already.

--
I regret nothing except my new-found capitalization policies.


[-- Attachment #2: Type: text/html, Size: 9494 bytes --]