From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <4028526.kJK0hItHXD@coil> References: <20120928112857.GA29306@software-lab.de> <4028526.kJK0hItHXD@coil> Date: Sun, 30 Sep 2012 20:20:50 -0400 Message-ID: From: Joseph Stewart To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=bcaec553feb6cdf53904caf46092 Subject: Re: [9fans] Running PicoLisp in Acme Topicbox-Message-UUID: bc442df6-ead7-11e9-9d60-3106f5b1d025 --bcaec553feb6cdf53904caf46092 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm far from an expert here, but I believe the underlying model here is that a line at a time in/out of the subordinate command (in this case picolisp) is the smallest unit of exchange to Acme. Tell me some details about the environment where you're running picolisp/acme (OS/architecture/versions of picolisp and acme) and I can try this out on my side. -joe On Fri, Sep 28, 2012 at 9:09 AM, dexen deVries wro= te: > Hi lists, > > On Friday 28 of September 2012 13:28:57 you wrote: > > > Acme does not emulate anything resembling ANSI terminal. As far as I > know, > > > it only treats TAB and LF characters in special way. In particular, n= o > > > cursor addressing resembling anything of ANSI terminal. > > > > Yes, but this is on a level higher. The picolisp line editor avoids any > > dependence on terminal control sequences (termcap or terminfo), by > > relying solely on spaces and backspaces to format the line. > > > I see now. I have similar annoyance with Git -- which uses ^H (or was it > CR?) > to over-write line of text when indicating pull progress (1% ^H^H2% ^H^H^= 3% > etc.etc.). > > > > In any way, instead of completely disabling 'led', you might change the > > function 'chgLine' in "lib/led.l", and replace "^H" ((prin "^H") in > > three places) with some other character which is suitable for acme. > > > I believe there's no direct replacement, but let's ask the nice folks on > 9fans@9fans.net -- I'm cross-posting this message. > > -- > dexen deVries > > [[[=E2=86=93][=E2=86=92]]] > > > --bcaec553feb6cdf53904caf46092 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm far from an expert here, but I believe the underlying model he= re is that a line at a time in/out of the subordinate command (in this case= picolisp) is the smallest unit of exchange to Acme.

Tell me some details about the environment where you're running pi= colisp/acme (OS/architecture/versions of picolisp and acme) and I can try t= his out on my side.

-joe

On Fri, Sep 28, 2012 at 9:09 AM, dexen deVries <dexen.devries@gmail.= com> wrote:
Hi lists,

On Friday 28 of September 2012 13:28:57 you wrote:
> > Acme does not emulate anything resembling ANSI terminal. As far a= s I know,
> > it only treats TAB and LF characters in special way. In particula= r, no
> > cursor addressing resembling anything of ANSI terminal.
>
> Yes, but this is on a level higher. The picolisp line editor avoids an= y
> dependence on terminal control sequences (termcap or terminfo), by
> relying solely on spaces and backspaces to format the line.


I see now. I have similar annoyance with Git -- which uses ^H (or was it CR= ?)
to over-write line of text when indicating pull progress (1% ^H^H2% ^H^H^3%=
etc.etc.).


> In any way, instead of completely disabling 'led', you might c= hange the
> function 'chgLine' in "lib/led.l", and replace "= ;^H" ((prin "^H") in
> three places) with some other character which is suitable for acme.

I believe there's no direct replacement, but let's ask the nice fol= ks on
9fans@9fans.net -- I'm cross-pos= ting this message.

--
dexen deVries

[[[=E2=86=93][=E2=86=92]]]



--bcaec553feb6cdf53904caf46092--