Re: [9fans] problem with acme on 9front

[Mark Lee Smith]

Thanks for the heads up Sairhei! I ended up backporting 9front's ^ and _ to
my copy of plan9port. It's not as flexible as having the named pipe around
but it answers the immediate question.

On Sun, 22 May 2016 at 09:38 Siarhei Zirukin  wrote:

> In 9front's version of sam there are two additional commands that could
> help you with "complex" commands, perhaps.
>
> ^ Plan 9-command
>Send the standard output of the Plan 9 command to the
>command window.
>
> _ Plan 9-command
>Send the range to the standard input, and send the
>standard output of the Plan 9 command to the command
>window.
>
> On Sat, May 21, 2016 at 11:52 PM, Mark Lee Smith 
> wrote:
>
>> Thanks for the interesting comments.
>>
>> I've been making an effort to use Sam, in the interest of my own
>> understanding. One of the biggest barriers I've hit is that there doesn't
>> appear to be a good way to save complex edit commands for later. The man
>> page suggests that it's possible to send commands to Sam from shell scripts.
>>
>> External communication
>>   Sam listens to the edit plumb port.  If plumbing is not
>>   active, on invocation sam creates a named pipe /srv/sam.user
>>   which acts as an additional source of commands.  Characters
>>   written to the named pipe are treated as if they had been
>>   typed in the command window.
>>
>>   B is a shell-level command that causes an instance of sam
>>   running on the same terminal to load the named files. B uses
>>   either plumbing or the named pipe, whichever service is
>>   available.  If plumbing is not enabled, the option allows a
>>   line number to be specified for the initial position to dis-
>>   play in the last named file (plumbing provides a more gen-
>>   eral mechanism for this ability).
>>
>>   E is a shell-level command that can be used as $EDITOR in a
>>   Unix environment.  It runs B on file and then does not exit
>>   until file is changed, which is taken as a signal that file
>>   is done being edited.
>>
>> I use Plan9Port on OpenBSD and typically use the plumber with Acme. I've
>> changed "editor" to sam, and read the B and E scripts. As I understand it
>> the plumbing approach doesn't allows sending arbitrary commands, so I've
>> stopped the plumber. I'm unable to find the named pipe and looking at the
>> sam source code it's not obvious to me how or whether such a pipe is
>> created. Is this capability still present in Sam? Perhaps the plumber has
>> completely subsumed this by now? Ultimately what I'd like to know is how
>> you go about reusing common commands? Do you snarf and paste them? I was
>> thinking that it would be useful to create scripts like "ap" which select
>> the current paragraph (name inspired by Vim.) What's the typical workflow
>> when using Sam? I don't deny that it's a great editor. Writing several
>> thousand words in Sam yesterday was a pleasure.
>>
>> Maybe I'm completely off base here?
>>
>> All the best,
>>
>> Mark
>>
>>
>>
>>
>>
>> On Fri, 20 May 2016 at 22:05 Steve Simon  wrote:
>>
>>>
>>> I started with Sam a sit ran on all the different unixes I used an vi an
>>> emacs just felt clunky.
>>>
>>> I never got into help and when acme replaced that I just never made the
>>> transition.
>>>
>>> I love Sam, though it is because I know it so well.
>>>
>>> btw, anyone written scripts to allow the plan9 wiki to be edited from
>>> Sam? maybe the wiki is outmoded these days?
>>>
>>> -Steve
>>>
>>>
>>>
>>>
>

Re: [9fans] problem with acme on 9front

[Siarhei Zirukin]

In 9front's version of sam there are two additional commands that could
help you with "complex" commands, perhaps.

^ Plan 9-command
   Send the standard output of the Plan 9 command to the
   command window.

_ Plan 9-command
   Send the range to the standard input, and send the
   standard output of the Plan 9 command to the command
   window.

On Sat, May 21, 2016 at 11:52 PM, Mark Lee Smith  wrote:

> Thanks for the interesting comments.
>
> I've been making an effort to use Sam, in the interest of my own
> understanding. One of the biggest barriers I've hit is that there doesn't
> appear to be a good way to save complex edit commands for later. The man
> page suggests that it's possible to send commands to Sam from shell scripts.
>
> External communication
>   Sam listens to the edit plumb port.  If plumbing is not
>   active, on invocation sam creates a named pipe /srv/sam.user
>   which acts as an additional source of commands.  Characters
>   written to the named pipe are treated as if they had been
>   typed in the command window.
>
>   B is a shell-level command that causes an instance of sam
>   running on the same terminal to load the named files. B uses
>   either plumbing or the named pipe, whichever service is
>   available.  If plumbing is not enabled, the option allows a
>   line number to be specified for the initial position to dis-
>   play in the last named file (plumbing provides a more gen-
>   eral mechanism for this ability).
>
>   E is a shell-level command that can be used as $EDITOR in a
>   Unix environment.  It runs B on file and then does not exit
>   until file is changed, which is taken as a signal that file
>   is done being edited.
>
> I use Plan9Port on OpenBSD and typically use the plumber with Acme. I've
> changed "editor" to sam, and read the B and E scripts. As I understand it
> the plumbing approach doesn't allows sending arbitrary commands, so I've
> stopped the plumber. I'm unable to find the named pipe and looking at the
> sam source code it's not obvious to me how or whether such a pipe is
> created. Is this capability still present in Sam? Perhaps the plumber has
> completely subsumed this by now? Ultimately what I'd like to know is how
> you go about reusing common commands? Do you snarf and paste them? I was
> thinking that it would be useful to create scripts like "ap" which select
> the current paragraph (name inspired by Vim.) What's the typical workflow
> when using Sam? I don't deny that it's a great editor. Writing several
> thousand words in Sam yesterday was a pleasure.
>
> Maybe I'm completely off base here?
>
> All the best,
>
> Mark
>
>
>
>
>
> On Fri, 20 May 2016 at 22:05 Steve Simon  wrote:
>
>>
>> I started with Sam a sit ran on all the different unixes I used an vi an
>> emacs just felt clunky.
>>
>> I never got into help and when acme replaced that I just never made the
>> transition.
>>
>> I love Sam, though it is because I know it so well.
>>
>> btw, anyone written scripts to allow the plan9 wiki to be edited from
>> Sam? maybe the wiki is outmoded these days?
>>
>> -Steve
>>
>>
>>
>>

Re: [9fans] problem with acme on 9front

[erik quanstrom]

unfortunately, sam has hardcoded B into the command channel.
see /sys/src/cmd/samterm/plan9.c:/^plumbformat

- erik

Re: [9fans] problem with acme on 9front

[Lyndon Nerenberg]

> I've never seen it happen, and I don't really expect to.  I do maintain
> that calling acme an editor is akin to calling New York a shopping
> center.
> 
> khm

That deserves an entry in the fortunes file.

Re: [9fans] problem with acme on 9front

[Mark Lee Smith]

Thanks for the interesting comments.

I've been making an effort to use Sam, in the interest of my own
understanding. One of the biggest barriers I've hit is that there doesn't
appear to be a good way to save complex edit commands for later. The man
page suggests that it's possible to send commands to Sam from shell scripts.

External communication
  Sam listens to the edit plumb port.  If plumbing is not
  active, on invocation sam creates a named pipe /srv/sam.user
  which acts as an additional source of commands.  Characters
  written to the named pipe are treated as if they had been
  typed in the command window.

  B is a shell-level command that causes an instance of sam
  running on the same terminal to load the named files. B uses
  either plumbing or the named pipe, whichever service is
  available.  If plumbing is not enabled, the option allows a
  line number to be specified for the initial position to dis-
  play in the last named file (plumbing provides a more gen-
  eral mechanism for this ability).

  E is a shell-level command that can be used as $EDITOR in a
  Unix environment.  It runs B on file and then does not exit
  until file is changed, which is taken as a signal that file
  is done being edited.

I use Plan9Port on OpenBSD and typically use the plumber with Acme. I've
changed "editor" to sam, and read the B and E scripts. As I understand it
the plumbing approach doesn't allows sending arbitrary commands, so I've
stopped the plumber. I'm unable to find the named pipe and looking at the
sam source code it's not obvious to me how or whether such a pipe is
created. Is this capability still present in Sam? Perhaps the plumber has
completely subsumed this by now? Ultimately what I'd like to know is how
you go about reusing common commands? Do you snarf and paste them? I was
thinking that it would be useful to create scripts like "ap" which select
the current paragraph (name inspired by Vim.) What's the typical workflow
when using Sam? I don't deny that it's a great editor. Writing several
thousand words in Sam yesterday was a pleasure.

Maybe I'm completely off base here?

All the best,

Mark





On Fri, 20 May 2016 at 22:05 Steve Simon  wrote:

>
> I started with Sam a sit ran on all the different unixes I used an vi an
> emacs just felt clunky.
>
> I never got into help and when acme replaced that I just never made the
> transition.
>
> I love Sam, though it is because I know it so well.
>
> btw, anyone written scripts to allow the plan9 wiki to be edited from Sam?
> maybe the wiki is outmoded these days?
>
> -Steve
>
>
>
>

Re: [9fans] problem with acme on 9front

[trebol55555]

#define chording 0  /* code here for reference but it causes deadlocks */

I suppose the bug is still messing around.
I'll give it a try to the 9front version.

Thanks for the info!

Re: [9fans] problem with acme on 9front

[Kurt H Maier]

On Sat, May 21, 2016 at 11:28:09AM -0700, Rob Pike wrote:
> If that was meant as a dis, you obviously haven't been to New York lately.
> 

Merely an observation that editing text is a minor subset of acme's
functionality.  When I dis things, you will not be confused about my
intent.

khm

Re: [9fans] problem with acme on 9front

[Mark van Atten]

On Thu, May 19, 2016 at 11:18 PM, Lee Fallat  wrote:
> You can copy code from Acme and "backport" it. I've done it before and
> it was trivial (and it's long gone too).

That's most interesting.

The following had made me think it would not be easy:

http://thread.gmane.org/gmane.os.plan9.general/8889/focus=8920

Mark.

Re: [9fans] problem with acme on 9front

[Rob Pike]

If that was meant as a dis, you obviously haven't been to New York lately.

-rob


On Sat, May 21, 2016 at 11:16 AM, Kurt H Maier  wrote:

> On Sat, May 21, 2016 at 10:36:44AM -0700, erik quanstrom wrote:
> > > This is tantamount to saying acme is superior because you are better at
> > > acme.  [...]
> >
> > c'mon man.  you follow this with several paragraphs of opinion which
> appear
> > to say that acme is not better because you don't like it.
>
> Yes, having explicitly set the dimensions of the field, I proceeded to
> stay in bounds.
>
> > but then again, editors don't tend to lead to logical arguments.  :-)
>
> I've never seen it happen, and I don't really expect to.  I do maintain
> that calling acme an editor is akin to calling New York a shopping
> center.
>
> khm
>
>

Re: [9fans] problem with acme on 9front

[Kurt H Maier]

On Sat, May 21, 2016 at 10:36:44AM -0700, erik quanstrom wrote:
> > This is tantamount to saying acme is superior because you are better at
> > acme.  [...]
> 
> c'mon man.  you follow this with several paragraphs of opinion which appear
> to say that acme is not better because you don't like it.

Yes, having explicitly set the dimensions of the field, I proceeded to
stay in bounds.

> but then again, editors don't tend to lead to logical arguments.  :-)

I've never seen it happen, and I don't really expect to.  I do maintain
that calling acme an editor is akin to calling New York a shopping
center.

khm

Re: [9fans] problem with acme on 9front

[erik quanstrom]

> This is tantamount to saying acme is superior because you are better at
> acme.  [...]

c'mon man.  you follow this with several paragraphs of opinion which appear
to say that acme is not better because you don't like it.

but then again, editors don't tend to lead to logical arguments.  :-)

- erik

Re: [9fans] problem with acme on 9front

[Steve Simon]

I started with Sam a sit ran on all the different unixes I used an vi an emacs 
just felt clunky.

I never got into help and when acme replaced that I just never made the 
transition.

I love Sam, though it is because I know it so well.

btw, anyone written scripts to allow the plan9 wiki to be edited from Sam? 
maybe the wiki is outmoded these days?

-Steve

Re: [9fans] problem with acme on 9front

[Wes Kussmaul]

On 05/20/2016 08:07 AM, Mark van Atten wrote:

This one I like, and it is not difficult to find:

http://www.amazon.com/HP-Optical-Button-Mouse-accessory/dp/B0002Y5LZ8/ref=sr_1_1?ie=UTF8=1463745997=8-1=dy651a+mouse


Sorry folks, it's not my habit to take the last cookie but in this case 
I bought the last one.


--
Wes Kussmaul

The Authenticity Institute
738 Main Street
Waltham, MA 02451

office +1 781 790 1674
mobile +1 781 330 1881

THIS COMMUNICATION IS INTENDED ONLY FOR THE USE OF THE PERSON TO WHOM IT IS 
ADDRESSED. If it was addressed incorrectly there's not much I can do but ask 
you politely to pretend you didn't see it. Any disclaimer suggesting that the 
sender has some kind of recourse is just wishful thinking.

If I had a message from you that was digitally signed using your Osmio VRD™ 
identity credential from the Osmio Vital Records Department (http://osmio.ch), 
we could easily and at no cost exchange encrypted messages and files with each 
other.

Re: [9fans] problem with acme on 9front

[Brantley Coile]

I purchased about a hundred of the IBM mice on Ebay, so I’m good for a while. 

HP has a nice three button mouse currently, seemingly from the European part of 
the company. I’m using one now.

http://www.laserjet.co.uk/hp-usb-optical-3-button-mouse-dy651a

Acme, of course, is based on the Oberon System by Niklaus Wirth, modified to be 
imported into the Plan 9 system, so it does have a different feel from Sam. If 
you haven’t studied Oberon, I would recommend you do. It was an amazing 
tour-de-force by Professor Wirth. 

The use of Sam vs Acme was always pretty evenly distributed. Rob uses Acme and 
Ken uses Sam still.

At SouthSuite, one of the few places still based on Plan 9, use Acme uniformly.

  Brantley Coile

> On May 20, 2016, at 7:58 AM, hiro <23h...@gmail.com> wrote:
> 
> I have bought 5 IBM mice with a real middle finger button. If someone
> needs one tell me.
> http://www.ibmfiles.com/ibmfiles/peripherals/scrollpoint_ice_blue.jpg
> location: Berlin
> 

Re: [9fans] problem with acme on 9front

[Mark van Atten]

This one I like, and it is not difficult to find:

http://www.amazon.com/HP-Optical-Button-Mouse-accessory/dp/B0002Y5LZ8/ref=sr_1_1?ie=UTF8=1463745997=8-1=dy651a+mouse

Mark.

Re: [9fans] problem with acme on 9front

[hiro]

I have bought 5 IBM mice with a real middle finger button. If someone
needs one tell me.
http://www.ibmfiles.com/ibmfiles/peripherals/scrollpoint_ice_blue.jpg
location: Berlin

Re: [9fans] problem with acme on 9front

[Lyndon Nerenberg]

> It's a problem for many people, for sure. On one of my mice, I bound a side 
> button to b2, and it works well enough for me. Other than that, I find 
> clicking the scrollwheel is acceptable with about 50% of mice. 

A consistent way to remap the mouse button bindings would work.  It's a lot 
easier to find an eighty-button gaming mouse than a Logitech ergonomic 
three-button mouse, these days.

Re: [9fans] problem with acme on 9front

[Ethan Grammatikidis]

On Fri, May 20, 2016, at 02:32 AM, Lyndon Nerenberg wrote:
> 
> > On May 19, 2016, at 6:23 PM, Ethan Grammatikidis  
> > wrote:
> > 
> > It's the plumber which does the heavy lifting there, and it will provide 
> > the same in conjunction with rio & sam. Selecting 'plumb' from rio's menu 
> > may seem clunkier, but after the first time it's just a b2click without 
> > reselecting, unless of course you do anything else with the b2 menu in 
> > between.
> 
> B2-anything on any "post-80s" mouse is an exercise in insanity.  Anything 
> requiring B2 these days is looking for trouble.  I stopped using any 
> B2-involving chords years ago, because the potential for fuckup is just too 
> large with the modern crop of scroll wheel mice.
> 
> 

It's a problem for many people, for sure. On one of my mice, I bound a side 
button to b2, and it works well enough for me. Other than that, I find clicking 
the scrollwheel is acceptable with about 50% of mice. 

-- 
Wir mussen wissen, wir werden wissen.

Re: [9fans] problem with acme on 9front

[Lyndon Nerenberg]

> On May 19, 2016, at 6:23 PM, Ethan Grammatikidis  wrote:
> 
> It's the plumber which does the heavy lifting there, and it will provide the 
> same in conjunction with rio & sam. Selecting 'plumb' from rio's menu may 
> seem clunkier, but after the first time it's just a b2click without 
> reselecting, unless of course you do anything else with the b2 menu in 
> between.

B2-anything on any "post-80s" mouse is an exercise in insanity.  Anything 
requiring B2 these days is looking for trouble.  I stopped using any 
B2-involving chords years ago, because the potential for fuckup is just too 
large with the modern crop of scroll wheel mice.

Re: [9fans] problem with acme on 9front

[Ethan Grammatikidis]

On Fri, May 20, 2016, at 01:37 AM, Lyndon Nerenberg wrote:
> To my view, acme is more of an IDE than an editor. the << B3-on-file:linenum 
> >> in the diagnostics window from a compile is the greatest productivity gain 
> I have ever experienced.  

It's the plumber which does the heavy lifting there, and it will provide the 
same in conjunction with rio & sam. Selecting 'plumb' from rio's menu may seem 
clunkier, but after the first time it's just a b2click without reselecting, 
unless of course you do anything else with the b2 menu in between.

Having said that, I prefer Acme anyway. Its window tiling often becomes a 
nuisance, but it's a minor one. Sam's dual clipboard is a far bigger nuisance 
in my many-window environment. Acme's small, mouse-focus tag bars are sometimes 
irritating, but now the tag bars expand you can keep multiple commands handy 
much more simply than in rio or sam. Acme's changing the length of the tag text 
can be quite awful when it jumps between single and multiple lines when 
editing, but again, it doesn't interfere like Sam's dual clipboard. Also, I 
find Sam's menus a good deal worse than rio's; I find myself needing to switch 
menu elements far more often. 9front's addition of chording to Sam helps, but 
it's buggy and (due to the dual clipboards) I haven't used Sam enough to know 
if it's enough.

-- 
Wir mussen wissen, wir werden wissen.

Re: [9fans] problem with acme on 9front

[Lyndon Nerenberg]

> On May 19, 2016, at 2:51 PM, Kurt H Maier  wrote:
> 
> Acme is firmly with X Windows in the "huge programs that don't actually
> *do* anything for you" category.

To my view, acme is more of an IDE than an editor. the << B3-on-file:linenum >> 
in the diagnostics window from a compile is the greatest productivity gain I 
have ever experienced.  I do like how I can use the "window control " 
extensions acme provides to write helper scripts for that environment.  But 
again, these are almost always IDE-oriented things that I only use during 
compile/debug/compile/debug.

I have never been able to get my head around sam's user interface, at least to 
the point where I would be using it as it was intended.  I love it in '-r' mode 
on UNIX when I need to edit something on the other end of a horribly 
inconsistent VPN tunnel.  But really, for most plain text editing needs (troff 
docs, system config files, etc), I'm happy to plod along with ed(1).

Re: [9fans] problem with acme on 9front

[Kurt H Maier]

On Thu, May 19, 2016 at 08:42:54PM +0100, Charles Forsyth wrote:
> 
> Any experienced acme user will quickly start banging the desk in
> frustration if thrown back into sam.
> Incredibly clumsy by comparison; not fluid. sam -d is useful for certain
> types of scripting.

This is tantamount to saying acme is superior because you are better at
acme.  While this is a valid method of choosing the tools you personally
use, it's not much good to people who are trying to figure out how these
sorts of opinions get formed in the first place.

Sam is a legitimate step forward in the world of text editing; its
command language and approach to regex is very powerful and allows
interesting applications.  Samterm has quirks and things that need
fixing -- its scrolling mechanism has been suggested for use as a csprng
-- but there's always the ability to fix or replace the interface.  With
acme, there is nothing *but* the interface.

Acme is not a text editor; it is a second-system dumpster fire
shoehorned into an incompatible interface.  Because it overlaps so
greatly with rio, lots of code requires special-casing the acme
environment.  It's pretty clear from looking at the code that acme was
eventually aiming to replace rio entirely.  I will never know (and am
uninterested in) the reason this was not completed, but the current
state of it is hacky and gross.

In addition, Acme as an interface represents a complete reversal of
previous 'window systems should be transparent' approaches taken.  Acme
does not allow you to do things with your computer so much as it
requires you to do things *to* your computer.  It requires fiddling. 
This approach is fine for some, but others of us just want to edit a damn
text file once in a while.

Acme is firmly with X Windows in the "huge programs that don't actually
*do* anything for you" category.


khm

Re: [9fans] problem with acme on 9front

[Lee Fallat]

You can copy code from Acme and "backport" it. I've done it before and
it was trivial (and it's long gone too).

On Thu, May 19, 2016 at 5:13 PM, Mark van Atten  wrote:
> The one thing I regret about Sam is that it doesn't have scroll-select
> as in Acme. I know the k and ' dance, but that is not nearly as
> convenient.
>
> Mark van Atten.
>

Re: [9fans] problem with acme on 9front

[Mark van Atten]

The one thing I regret about Sam is that it doesn't have scroll-select
as in Acme. I know the k and ' dance, but that is not nearly as
convenient.

Mark van Atten.

Re: [9fans] problem with acme on 9front

[stanley lieber]

>> at the cost of stepping all over the rest of the (Plan 9) system
>
>
>?

To get the best use out of acme you need to arrange for it to capture a lot of 
plumber rules (or arrange to maintain multiple sets of rules for acme and 
not-acme). Because of the way acme manages windows, programs often need to keep 
track of (and handle) whether or not they are running inside acme. Finally, 
acme does not support some common features provided by rio (like hold mode), 
which means even some text-based programs (like upas/marshal) aren't fully 
functional. Everything acme touches requires special hand-holding. 
Conceptually, it is the opposite of the tools approach to software.

As I said, this can be convenient on a UNIX system that otherwise lacks the 
features provided by rio, but on Plan 9, where most of this stuff is otherwise 
already available, it requires a great deal of commitment to the acme 
grab-it-all philosophy. Sometimes, you don't want to carry the kitchen sink on 
your back.

sl

Re: [9fans] problem with acme on 9front

[Aram Hăvărneanu]

One day I will write a samterm that works like acme. I mostly use
acme, but sometimes on Unix I have to use sam because only sam can do
"sam -r".

-- 
Aram Hăvărneanu

Re: [9fans] problem with acme on 9front

[Lee Fallat]

>From experience, Sam's command window provides a more consistent
experience with the rest of the system. Acme on the other hand
pretends to have individual command windows (more like command lines)
for every file open. Sam has some form of "tiling", but not as
automatic as Acme. Sam also has a remote editing protocol, unlike
Acme. I liked Sam not only for those reasons, but also because of what
Charles said - you can script Sam with sam -d, allowing it to
integrate into other parts of the system.

It's too bad there has not been a clean rewrite of Sam, like Rob has
mentioned in his paper.

On Thu, May 19, 2016 at 4:26 PM, Mark Lee Smith  wrote:
> I'm was merely explaining my understanding of the context so that I could be
> corrected if I was wrong on any point. I didn't mean to explain Acme to you.
> While I replied to you (I believe I did), please understand my question in
> the light of the thread, as it were, a whole.
>
> Thanks, everyone, for the answers!
>
>
> On Thu, 19 May 2016 at 21:38  wrote:
>>
>> mark, why do you explain acme to me?
>>
>> --
>> cinap
>>
>

Re: [9fans] problem with acme on 9front

[Mark Lee Smith]

I'm was merely explaining my understanding of the context so that I could
be corrected if I was wrong on any point. I didn't mean to explain Acme to
you. While I replied to you (I believe I did), please understand my
question in the light of the thread, as it were, a whole.

Thanks, everyone, for the answers!

On Thu, 19 May 2016 at 21:38  wrote:

> mark, why do you explain acme to me?
>
> --
> cinap
>
>

Re: [9fans] problem with acme on 9front

[Charles Forsyth]

On 19 May 2016 at 21:11, stanley lieber  wrote:

> at the cost of stepping all over the rest of the (Plan 9) system


?

Re: [9fans] problem with acme on 9front

[cinap_lenrek]

mark, why do you explain acme to me?

--
cinap

Re: [9fans] problem with acme on 9front

[Mark Lee Smith]

Hopefully without stepping into any religious matters, why do you (9front)
favor Sam so much? As I understand it Acme came after Sam, and Acme exposes
Sams edit language through the Edit command, as well as providing "window"
management, the ability to run a terminal inside, and exposing a file
system for control by scripts etc. It seems like a solid improvement on
Sam, which is itself a very nice text editor.

All the best,

Mark

On Thu, 19 May 2016 at 20:43  wrote:

> to be less cryptic, to have the acme working directory update on cd,
> you can put the following code in your $home/lib/profile
>
> fn cd { builtin cd $* && awd }  # for acme
>
> the difference to labs and 9font is just that we dont have that thing
> in our default profiles, because we'r mostly sam users.
>
> --
> cinap
>
>

Re: [9fans] problem with acme on 9front

[cinap_lenrek]

to be less cryptic, to have the acme working directory update on cd,
you can put the following code in your $home/lib/profile

fn cd { builtin cd $* && awd }  # for acme

the difference to labs and 9font is just that we dont have that thing
in our default profiles, because we'r mostly sam users.

--
cinap

Re: [9fans] problem with acme on 9front

[Siarhei Zirukin]

Acme is deprecated. We no longer support it. Please consider upgrading to
sam instead.

On Thu, May 19, 2016 at 8:30 PM, christophe DAMAS <
christophe.da...@gmail.com> wrote:

> Hello
>
> Trying acme on 9front. Got the following problem : the cd command in
> an acme shell window doesn't refresh the directory context of this
> windows, then right click on a file or directory name doesn't open the
> file.
>
> On other implentations I use (windows Acme-SAC, OSX plan9port, and
> plan9 on Pi) it works fine.
>
> On plan9port the same problem happens with bash shell in acme windows,
> but not with rc shell.
>
> Can't figure out where is the problem on 9front ?
>
>
>