Re: [9fans] I prefer cropping images in Plan 9
On Sat, Jul 21, 2018, at 4:20 PM, Ryan Gonzalez wrote: > On July 21, 2018 8:21:10 AM "Ethan A. Gardener" wrote: > > > I just had to crop a bunch of images in the Gimp, and recalled how much I > > prefer doing it in Plan 9; it's so much less frustrating. In the Gimp, it's > > either a matter of estimating numbers (for a quick, casual job on visual > > media), or select, copy, paste into new window. In the latter case, when > > you save it, you have to find the directory and the file8749832710473name; > > not fun. Also, I'm not practised at this; I'm no good at cropping with my > > brain, so I had to zoom, resize the window, and select very carefully so > > selecting didn't move the image in the window. > > > > In Plan 9, which isn't even made for the job, it's not without its > > frustrations, but it's got fewer of them than the Gimp. Open the image in > > page; use the plumber or otherwise enter the full path so you can > > copy/paste it later. Zoom and adjust the window as you like. In another > > window, grep for the filename (or the directory, or whatever,) in > > /dev/wsys/*/label, and type cd and send the directory part. (Of course, > > copy/paste or send the file name.) Then: > > crop -i 4 window | topng > path/filename.png > > This is the part where you'll likely want to copy the full original path. > > That's one done. On to the next image, which presumably is open in the same > > instance of page so you don't have to cd or anything. `cat label` to get > > its full name and path. (It's possible only 9front's page puts the path in > > the label, I don't know.) > > To be fair, if you're using a command line, you might as well be using > ImageMagick (not criticizing your points or anything, just playing devil's > advocate). `crop -i 4` is just to get rid of the window border. The actual selection of the region of image to crop to, in Plan 9, has nothing to do with the command line.
Re: [9fans] I prefer cropping images in Plan 9
On Sat, Jul 21, 2018, at 5:17 PM, hiro wrote: > > do this, I think one thing that could maybe be interesting would be for the > > files to potentially contain rich data, not just plain text? Kind of like > > TempleOS or systemd's journal does. > > Rich data? You mean like... images? > Ha ha! :) Images in the terminal would be fun, but would have to wait until we have more than vt220/char cell display. That means it's going to get implemented under Plan 9 first, most likely. Forgot to say in other mail: Nothing wrong with storing structured pipe data in a file, but I'd like the data to be mostly utf-8 text to ease debugging and byte ordering. -- The lyf so short, the craft so long to lerne. -- Chaucer
Re: [9fans] I prefer cropping images in Plan 9
On Sat, Jul 21, 2018, at 4:20 PM, Ryan Gonzalez wrote: > > While I'm replying here, might as well point out that, if you're going to > do this, I think one thing that could maybe be interesting would be for the > files to potentially contain rich data, not just plain text? Kind of like > TempleOS or systemd's journal does. I had some idea of structured pipes, but that idea's been on the shelf so long it's synapse-rotted. I was thinking of ls ps and others outputting key-value pairs, fields of which could then be selected by name. I suppose that would make for a relatively complex terminal, but it could also mean you could select different fields in the terminal after a slow job completes. This is somewhere in the top 5 things to work on, after the text editor and portability. > Google Groups and Freelist are the best. Google Groups has a terrible UI > but also has better spam filters IME. Thanks -- The lyf so short, the craft so long to lerne. -- Chaucer
[9fans] I prefer cropping images in Plan 9
I just had to crop a bunch of images in the Gimp, and recalled how much I prefer doing it in Plan 9; it's so much less frustrating. In the Gimp, it's either a matter of estimating numbers (for a quick, casual job on visual media), or select, copy, paste into new window. In the latter case, when you save it, you have to find the directory and the file8749832710473name; not fun. Also, I'm not practised at this; I'm no good at cropping with my brain, so I had to zoom, resize the window, and select very carefully so selecting didn't move the image in the window. In Plan 9, which isn't even made for the job, it's not without its frustrations, but it's got fewer of them than the Gimp. Open the image in page; use the plumber or otherwise enter the full path so you can copy/paste it later. Zoom and adjust the window as you like. In another window, grep for the filename (or the directory, or whatever,) in /dev/wsys/*/label, and type cd and send the directory part. (Of course, copy/paste or send the file name.) Then: crop -i 4 window | topng > path/filename.png This is the part where you'll likely want to copy the full original path. That's one done. On to the next image, which presumably is open in the same instance of page so you don't have to cd or anything. `cat label` to get its full name and path. (It's possible only 9front's page puts the path in the label, I don't know.) It's an operating system with few pretensions and only clunky image editing tools, versus a powerful two-decade-mature image editing suite. Loading and saving the files is no worse in Plan 9 than it is in the Gimp with its oh-so-modern file selector, and the actual cropping part is easier in Plan 9! If anyone's waiting for news of my OS where everything is done from an interpreter prompt, I got distracted for a while but I'm on it again now. I'm staying with Forth but looking at alternatives to swap drop and roll -- I mean stack manipulation primitives. Not to start a discussion here, but I've decided it will have a single tree of names for all permanent storage despite supporting architectures without a filesystem. Disk blocks could be a directory of numbers under /b0, /b1 etc. OFW's non-volatile environment variables could be a single-level directory under /nv. Actual local filesystems, including the host's, could go under /f. Perhaps other resources could go in the same tree as virtual files, but I'm not building that bridge until I see the river. It's off topic for this list, so perhaps mail replies to me privately? Any suggestions for a mailing list provider? My primary requirement is low maintenance. I see many projects use Google Groups, but would like suggestions for others if you have them. -- The lyf so short, the craft so long to lerne. -- Chaucer
Re: [9fans] What are you using Plan 9 for?
On Tue, Jun 26, 2018, at 7:36 AM, Tyga wrote: > Re: your comment about trackpad / vertical mouse. > > I had a similar RSI problem a couple of years ago. I solved it by using a > Logitech trackball with my right hand - but only to move the cursor and I > used a MS optical mouse with the tracking window taped over so that I would > only use it to click or scroll with the left hand. I had to tape over the > window so that moving the mouse wouldn't actually move the pointer which I > had carefully positioned with the trackball. Cured the RSI and now able to > even use a normal trackpad on a notebook for short periods of time. But I do > prefer to use my desktop for serious amounts of work. Good to know! I have a Twiddler one-handed keyboard with a poor pointer control stick, but at least it has 3 buttons. I should try using it with a mouse like this. I've also enjoyed playing Minecraft with the mouse buttons remapped to keys. It's basically the same thing: movement right-handed, buttons left-handed. My major problem with mouse or keyboard is arm support. I'm "tall sitting down", so I need armrests and a desk much higher than average. I remember a normal mouse being fine so long as the desk was high enough.
Re: [9fans] What are you using Plan 9 for?
On Tue, Jun 26, 2018, at 6:17 AM, 刘宇宝 wrote: > > > > On Jun 25, 2018, at 5:33 PM, Ethan A. Gardener wrote: > > > > > > I picked up an idea from microapl.com, workspaces. Saving system > > state is one of my goals for my OS, and the concept of workspaces > > pertaining to separate tasks keeps popping up when I get ideas. For > > those who don't know, it's this: > > > > Lisp and Smalltalk both have similar thing, dump whole image (or > "world") to disk and load to memory next time. I was sure something else saved the world ( :) ) too, but I couldn't remember. Of course Lisp and Smalltalk do it. It is a bit of a risk doing it in Forth because memory corruption is more likely, but I think it can work with careful, not-too-simple saving code -- checksums perhaps. > > The GUI of Lisp Machine and Squeak looks elegant, of course Rio is very > elegant too :-) > > * https://static.loomcom.com/genera/genera-install.html > * https://squeak.org/ Squeak is another thing I "should have" properly tried. It was the basis for this 3D environment where, instead of sending all the data to all clients, code snippets were sent instead. The clients were synchronized so they all rendered the same. Moving around made me dizzy, though. > > Regards, > Yubao Liu > -- The lyf so short, the craft so long to lerne. -- Chaucer
Re: [9fans] What are you using Plan 9 for?
On Tue, Jun 26, 2018, at 4:24 AM, 刘宇宝 wrote: > > Recently I read Rob Pike's "Systems Software Research is Irrelevant", I > felt pity, and I was wondering what the operating system would look like > in the future, here is my stupid optimistic predication: I felt sad when I read it too, but like you, I hope the prevalence of KVM will bring a new wave of OS development. :) > > • Server hardware will become extreme powerful, TB DRAM, non-volatile > memory, NVMe disk, 100Gb ethernet, the paradigm of separate cpu server, > file server, (a little fat) terminals will come back to be mainstream, > network of piles of cheap PCs will go away. > • Linux，even BSD，became the underlying device driver and "BIOS", this > is almost the current situation, Linux KVM, Xen + Linux dom0 hide > details of hardware. This layer takes care maximum hardware support and > raw performance. > • *Distributed* operating systems above KVM/Xen will step into a period > of great development, hardware support and maximum raw performance are > not top priorities, *OS native* fault tolerance, simple and clear > distributed process scheduling, easy and consistent IPC/RPC API will > win, Google Kubernetes will die. Many ideas of Plan 9 will revive, just > like memory garbage collecting revived after about 30 years. > > Regards, > Yubao Liu >
Re: [9fans] What are you using Plan 9 for?
On Thu, Jun 21, 2018, at 7:03 PM, Bakul Shah wrote: > On Jun 21, 2018, at 8:23 AM, Ethan A. Gardener wrote: > > > > Thanks! I don't know APL at all, beyond the fact that its need for a > > graphical (or at least sophisticated) display held it back in the past. I > > should probably look into it now, I'm sure it would save me from making > > some mistakes in my design. > > Languages j, k & q are ascii only. K is > quite minimalist (compared to APL & j). > I quite like Scheme, k and plan9 for > their minimalist aesthetics. I have briefly used q and pure, but I remember nothing practical about them, only that pure is a verbose q. I've looked into APL a little now, got an introduction from a 1975 video which was interesting and a little amusing, and had a look at aiju's k pages -- http://aiju.de/code/k/ . I think the idea of combining operators is really cool, but I'm certain I'd get mixed up with both APL and k in the same way I struggle with regexps. Pure would be better, but I haven't heard mention of it since that one time I tried it. This amuses me because its documentation stated in true Gnu style, "q is unmaintained, new projects should use pure." I picked up an idea from microapl.com, workspaces. Saving system state is one of my goals for my OS, and the concept of workspaces pertaining to separate tasks keeps popping up when I get ideas. For those who don't know, it's this: Quoting from http://www.microapl.com/apl/introduction_chapter1.html > In addition, it has a very useful concept called the > workspace. This is basically a collection of the data > items, functions, and classes which you set up in the course > of doing a particular job. > > The workspace is in computer memory while you work, making > everything you want immediately accessible. It can be saved > (i.e. copied on to a disc) in its entirety when you stop, > and loaded back into memory next time you want to use it. I'm finding other relevant ideas in that introduction, too. > > Arthur Whitney, k’s designer, had told > me he was making it run on bare metal. > He was muttering about how Linux just > gets in the way! Though I don’t know if > he actually did that. Bare metal dreams! I have similar ambitions for my Forth OS, of course. :) This is where things like OpenFirmware are good, because you get a bunch of drivers for free. They may not offer the highest performance, but when developing an OS on your own, I'm sure they'd save a lot of time and frustration. And you may get things which might be last on your list to implement, like the webcam in an OLPC. > > Another crazy bare metal tale: A few > years before Eben Upton came up with > Raspberry Pi, he had ported cpython to > run on the videocore on a GPU only > chip (bcm2707) using custom software > hackery. Using python like BASIC is a great idea! Wild! :) It's better than, but reminds me of the time I compiled Python to run alone on the Linux kernel. I was lazy, I didn't want to reimplement utilities like mount, and so I left it. Now, I think I should have pushed myself to implement those and a text editor too. It would have boosted my skills over a decade ago. > > Personally I’d prefer something like k, Scheme, python or lua (and not > forth) to boot into. I am admire forth but I’m > not a fan of *programming* in stack languages! Python and Tcl were on my list for my OS. I don't recall thinking of lisps except elisp for some reason. Anyway, I had high hopes for Forth's sequential nature. It is quite good, especially for the wide range of tasks I want to apply it to; the syntax is so flexible! As I said, I have trouble with regexps, and printf isn't far behind. Here's example usage for a sprintf-like system from Swift Forth: <% S" This is a test " %s DPL @ %d S" finally" %s %cr %> Literal strings, variable references, and escapes go in their logical order. There's no need for escapes to be just one character. These are features I want. As I write this, I realize that this all could be done in other languages with minor syntax variations. I can imagine it in Python as a tuple containing literal strings and the names of members of a class. In Lisp, a list with strings and symbols. (Do symbols work the same way in Scheme?) I'm thinking it over, but I may stick with Forth for other reasons. I haven't ruled out implementing some of my project in another language to see how it compares. Other reasons I like Forth are its efficiency (relative to Python and maybe Lisp), the fact that very low level work is natural, and especially the great simplicity of Forth interpreters. The stack can be a bit of a pain, but not as much as I expected, and it's what enables that flexible syntax. It helps to break code up into very small definitions, although it's not al
Re: [9fans] What are you using Plan 9 for?
On Thu, Jun 21, 2018, at 6:39 AM, Kurt H Maier wrote: > On Wed, Jun 20, 2018 at 10:35:42PM +0100, Ethan A. Gardener wrote: > > > > a sort of operating system where the primary interface to all tasks is > > a Forth interpreter. > > I think we've talked about this in another venue some years back, but I > often thing of the OpenFirmware implementation used by the OLPC XO-1 > laptop. Instead of a BIOS or UEFI or linux trash in their stead, the > system was managed by an OpenFirmware installation, much of which was > written in Forth, and whose primary interface was a Forth shell. This > environment had complete access to the hardware of the system, which > was used by the project to create really comprehensive hardware > diagnostics tools. I do too. My Mac just boots to OpenFirmware now. It's a bit broken, being early Apple OFw, but that was what prompted me to start work -- it needs a text editor. OFw is an ANS Forth, and I'm working with the goal of running on multiple such ANS Forth platforms. > > I mostly used it for screwing around, but it was fairly complete; it > supported the wifi hardware and the webcam, and I often thought I'd like > a computer that just booted into this environment and stayed there. I'm > glad to hear you're still experimenting along these lines. Thanks! > There's a > lot of value in a system whose primary interface is the programming > environment. I work with computers because of the Commodore VIC-20... > and I wonder if I'd have ever given a damn about the field if my first > exposure to computers involved a Modern User Experience. I haven't stopped to wonder exactly that, but I think I would have hated them. I was brought up on the idea that computers existed to be programmed, so I wasn't happy when Windows shipped without a programming language outside the DOS prompt, or later at all. I might have gone hunting for "a real computer"! :) It also took me years to get used to the mouse, and longer to get used to menus. It probably didn't help that I didn't have a decent desk for my first Atari ST, and GEM is *terrible!* Anyway, I love this quote: > Then I discovered girls and cars and didn't get back into computers until the > early 90s only to discover that there was no longer a computer that was > READY> in 1.2 seconds and would only do exactly what it was told exactly when > it was told as fast as it could...Nope, by then the spinning hourglass had > been invented and the world has been riveted to their not-as-big-as-a-tv > screen, the scowl lines of struggle on their foreheads, one hand tied to a > mouse, the other fingers tapping...but conflict obviously was what America > needed [...] It's in the comments here: https://www.classic-computers.org.nz/collection/atari-400.htm That 1.2 seconds was the time it took an Atari 400 to check for a disk drive. Windows 7 takes about 50 times as long to 'install' a USB keyboard! It's not even like Atari's peripheral bus was overly simple; it supported almost all peripherals with a common protocol, so I think of it as an early USB. -- The lyf so short, the craft so long to lerne. -- Chaucer
Re: [9fans] What are you using Plan 9 for?
On Thu, Jun 21, 2018, at 5:49 AM, Bakul Shah wrote: > On Thu, 21 Jun 2018 05:58:42 +0200 Lucio De Re wrote: > Lucio De Re writes: > > On 6/20/18, Ethan A. Gardener wrote: > > > [ ... ] Most of it is going into game scripting at the moment, but on the > > > b > > ack > > > burner is a Forth-based project; a sort of operating system where the > > > primary interface to all tasks is a Forth interpreter. [ ... ] > > > > Bakul may not agree, but that sounds like a novel take on APL. > > Different underlying syntax, but conceptually quite similar. Forth is > > one of those things that happened while I wasn't watching, so I'm not > > at all familiar with it, so it makes sense for me to use the model I > > know, but this sounds quite intriguing. > > As a matter of fact some APLers are quite fascinated with > "concatenative" languages like Forth, Joy, Factor etc.! Interesting! > > > Do you know APL and/or any of its derivatives? You'd bit a better > > judge. The idea of the full interpreter at the command line is a > > powerful one and APL's one liners handle much better the shortcomings > > of any Unix shell's regarding multi-line constructs. > > There are some conceptual similarities between stream > programming using shell pipelines and array programing using > APL/j/k/q. Array programming is richer as you can pass many > different things, not just character streams. It's very much what I've been hoping to achieve, then. I'll definitely look into it. -- The lyf so short, the craft so long to lerne. -- Chaucer
Re: [9fans] What are you using Plan 9 for?
On Thu, Jun 21, 2018, at 4:58 AM, Lucio De Re wrote: > On 6/20/18, Ethan A. Gardener wrote: > > [ ... ] Most of it is going into game scripting at the moment, but on the > > back > > burner is a Forth-based project; a sort of operating system where the > > primary interface to all tasks is a Forth interpreter. [ ... ] > > Bakul may not agree, but that sounds like a novel take on APL. > Different underlying syntax, but conceptually quite similar. I knew it must have been done before, but APL is one of the many things I never got around to looking into. > Forth is > one of those things that happened while I wasn't watching, so I'm not > at all familiar with it, so it makes sense for me to use the model I > know, but this sounds quite intriguing. > > Do you know APL and/or any of its derivatives? You'd bit a better > judge. The idea of the full interpreter at the command line is a > powerful one and APL's one liners handle much better the shortcomings > of any Unix shell's regarding multi-line constructs. > > It would interesting to explore your particular take on this and place > it in a broader context. Thanks! I don't know APL at all, beyond the fact that its need for a graphical (or at least sophisticated) display held it back in the past. I should probably look into it now, I'm sure it would save me from making some mistakes in my design. > > Lucio. > -- The lyf so short, the craft so long to lerne. -- Chaucer
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 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 > 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.
Re: [9fans] What are you using Plan 9 for?
On Mon, Jun 11, 2018, at 7:14 AM, 刘宇宝 wrote:
> this makes me wondering
> whether anybody still seriously uses(or used?) Plan 9 for serious work,
> what software they frequently use, what software is most lack of.
For many years I used it and especially Acme to try to organise my life,
including every area of interest I had. Plan 9 and Acme played their parts
quite well. I even had multiple Acme sessions running, each with its own
plumber. Some windows held sub-instances of Rio, again with their own plumber
instances, for projects requiring graphics or PDFs.
Another use I had for it was playing MUDs, MUSHes, MU* -- telnet-based
multi-player games. I particularly liked Rio's "noscroll" feature in this case,
as I could catch up with all the messages at my own pace. In fact, I very much
like noscroll in general. On the other hand, the lack of color meant I could
miss things sometimes, such as a clue in a room description or a private
message while travelling -- noscroll isn't really feasible when you're
following someone rapidly through a dozen rooms, each with their own
description. I never got around to filtering different kinds of messages into
different windows. I should have.
Overall, I asked Plan 9 to do quite a lot of things it wasn't really designed
for, without writing a bit of C code, and for the most part it proved
remarkably convenient. Frustration eventually built up over some things,
particularly all the string manipulation -- converting data between the
different programs' needs -- when, even after all these years of practice, I am
_still_ bad at regular expressions! I developed ideas about another operating
system with structured pipes, but around this time I learned to relax. I
dropped most of my projects, stopped trying to play so many games so hard, and
no longer needed Plan 9 to help me organize it all.
Ironically perhaps, relaxing has freed my creativity so that I'm now
programming more than at any time since before I started using Plan 9 full
time. Most of it is going into game scripting at the moment, but on the back
burner is a Forth-based project; a sort of operating system where the primary
interface to all tasks is a Forth interpreter. So far, I've written the basics
of a text editor. It's *very* little code! Plan 9 is a very expressive system
for how little code it has, but this seems to be a major step beyond that. It's
a bit too early to really tell.
It offers the full power of a systems programming language at the editor
prompt. If that sounds like a problem, it's not yet. If it ever becomes a
problem for common tasks, I can write safer, higher-level, and probably more
convenient words (=functions, =commands,) to handle those tasks. That's
arguably how the text editor's basics already work. For instance, change-dotlen
performs safety checks before calling the (dangerous, powerful,) move word to
adjust the contents of the buffer for inserted or deleted text. rdot ("replace
dot") is a user command which calls change-dotlen to do most of the work, then
calls move again to copy the string into the buffer. change-dotlen is well
tested, rdot is so simple there are obviously no faults. :) (That's not
something I really believe in, I tested it too.) None of the other user
commands call move, they adjust dot and then call rdot. Adjusting dot means a
call to dot! (dot-store), which also has safety checks.
When all the necessary tools are written, there's just no need to use the
unsafe features, but neither is there a need to partition those features off
into compiled program space. There's no need to learn five different languages
for one task, and if you want to point out that a Forth system may well include
lots of mini-languages, there's no need for the mini-languages to have -- or
LACK -- their own loops, conditionals, variables, or function definitions, not
to mention jammed-into-a-string terse syntaxes.
I'd better stop here because I'm getting enthusiastic. :) It is early days yet,
I may have to retract some of my beliefs in the future. I still have a Plan 9
system which is almost always on, but now 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.
--
The lyf so short, the craft so long to lerne. -- Chaucer
Re: [9fans] how to undo in Rio shell window and Acme editor?
As a small extra hint if you ever need to work outside Acme, any delete of selected text is effectively a cut. You can paste it back in. I used to use that like undo all the time. On Wed, May 9, 2018, at 7:32 AM, 刘宇宝 wrote: > Hi all, > > Recently I started an adventure to 9front and found Plan 9 very > interesting. I have thoroughly read the FQA and manual pages at > 9front.org, and searched the web, but still don't know how to undo wrong > typing in Rio shell window and Acme editor's tag line, I'm surprised > and not so used to the facts that: > > * I can edit the output of a command in shell window, no way to undo > > * I can change or delete the tags for Acme editor and its column, no way > to undo, although the tags for Acme window can't be edited. > > I miss much the *universal* shortcut Ctrl-z on Window and Command-z on > macOS, does Rio and Acme have the equivalent? > > > And one more question about Acme: how to quickly enter command? In VIM, > I can enter ...comand, in Acme I have to move cursor to > command area and click, input command, press , click middle mouse > button on the highlighted command, is this the fastest way to input > command in Acme? > > > Thanks, > > Yubao Liu > > -- The lyf so short, the craft so long to lerne. -- Chaucer
[9fans] looking for tcl/tk sam clone
i had a copy of sam clone written entirely in tcl/tk, "tsam" or something, but I've lost it. where can i download it from, please? -- The lyf so short, the craft so long to lerne. -- Chaucer
Re: [9fans] simple rc problem in p9p (on OpenBSD)
On Thu, Apr 26, 2018, at 8:01 PM, Costin Chirvasuta wrote: > I lot of the messages on this list end up being marked as spam. I > believe there was a previous discussion about this. I've had no trouble with this list on fastmail.fm , for what it's worth.
