Re: [9fans] Setting acme to a GoMono or DejavuSansMono font

[Mark van Atten]

> then acme starts, but the font is not GoMono.

9 man fontsrv
(EXAMPLES)

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T24f3cf01c959c542-M6bd7d4b766df7cdfd0a27ee1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme & sam text selection and delete deletes extra character

[Mark van Atten]

>Just curious, is this by design, or is this a bug?  I'm inclined to think 
> it's by design as it occurs within sam as well.

https://9fans.topicbox.com/groups/9fans/Tf778565df277dd77-M396229d3fd3befcd0bcc95df/re2-9fans-home-end-hjkl

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T06d3bdd208f5a90b-Ma87ed015ed75722f36cb8ba9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[Mark van Atten]

HP DY651A, e.g. https://www.ebay.com/itm/234392830458

I bought three of them some ten years ago, and they are still working
perfectly. It seems the model is no longer in production. The original
price was very low. I seem to recall it was also sold as an IBM mouse.

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-Mc93adb0e55fe39931ae344cb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Searching sam for text

[Mark van Atten]

On Mon, 2 Aug 2021, 9:00 pm ,  wrote:

> On Monday, 2 August 2021, at 7:48 PM, Mark van Atten wrote:
>
> man sam
>
> I have read the man page several times. It speaks of display commands not
> of their combinations.
>

Look for the part about 'grouping'.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T6d4564e82d943342-M2c6a25dda5ee5e0e5c9ba32d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Searching sam for text

[Mark van Atten]

On Mon, 2 Aug 2021, 7:22 pm silas poulson,  wrote:

>
> Sending document to grep with ,> grep -n  slightly neater though
> does mean leaving sam’s command set.
>

I usually have a 9term open with the same working directory as the document
I am editing, and tend to use that for things outside sam's own language,
in combination with the plumber to jump back into sam (e.g. grep -n). (And
winwatch helps here, if you have opened more than a small number of
terminals.)

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T6d4564e82d943342-Mde8e9f72eeffde61e9f7c747
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Searching sam for text

[Mark van Atten]

On Mon, 2 Aug 2021, 7:20 pm ,  wrote:

> On Monday, 2 August 2021, at 6:50 PM, Mark van Atten wrote:
>
> Combine the p with an =.
>
> If I add = to ,x g//+-p as in ,x g//+-p= I get a ?newline
> expected error.
>

man sam

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T6d4564e82d943342-M0d63103e46b8f5eebf355a05
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Searching sam for text

[Mark van Atten]

On Mon, 2 Aug 2021, 6:39 pm ,  wrote:

> In sam if I invoke ,x g//+-p sam prints out the hits in the sam
> window by lines. I was wondering if there is a way of going from any of
> those search results directly to the line in the document where the string
> occurs?
>

Combine the p with an =.

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T6d4564e82d943342-M16cde7774dd49444a12e5e6c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Help with a sam cleanup script

[Mark van Atten]

On Tue, 27 Jul 2021 at 15:23, Iruatã Souza  wrote:
> Just pushed it to https://github.com/iru-/sam9f-unix. It might be
> outdated, but I still use it daily.

Many thanks for this!

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T10b1d559ae7d981e-M709aaf85a4881ce3f4b7207d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Help with a sam cleanup script

[Mark van Atten]

On Mon, 26 Jul 2021 at 23:08,  wrote:
>
> Quoth revcomni...@gmail.com:
> > I do have 9front's sam installed
> > I am running sam as a standalone on Debian Linux
>
> 9front's sam does not run on Debian linux.

There is a port, now no longer active:
https://bitbucket-archive.softwareheritage.org/projects/ir/iru/sam9f-unix.html

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T10b1d559ae7d981e-Me3671f8e9073b8bd8146cd0e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: [9front] rc oddity with quote and backslash

[Mark van Atten]

As pointed out on the 9front list: this is as it should be.

Sorry for the noise.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td7a2640b58fc8d2d-Mbede6b7cf97b5ad84ce54227
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: [9front] rc oddity with quote and backslash

[Mark van Atten]

On Tue, 30 Mar 2021 at 17:52, Xiao-Yong Jin  wrote:
>
> ; xs=(a\
> b\
> c\
> )
> ; echo $#xs
> 3
> ; xs=('a'\
> rc: #d/0: syntax error
> ; xs=('a' \
> 'b' \
> 'c' \
> )
> ; echo $#xs
> 3
>
> The sequence of quote-backslash-newline somehow is not interpreted as 
> quote-blank, but a syntax error.  I don't think it's documented anywhere.
>

Same result on p9p.

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td7a2640b58fc8d2d-M4651bdea5395863f7e20833d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Mark van Atten]

On Fri, 19 Feb 2021 at 07:32, Mark van Atten  wrote:
>
> On Thu, 18 Feb 2021 at 10:04, Skip Tavakkolian
>  wrote:
> >
> > Plan9port has fontsrv. Any truetype you have on your system is usable.
> > man fontsrv for details.
>
> On my system (Arch 5.10.16) using fontsrv introduces 2-3 second delays
> whenever a program needs to know about the font,
> e.g. when opening acme the window first turns all black and then all
> white before the columns appear; similarly, lc always takes about
> 2 seconds before the listing appears.
>
> Do others observe this, too?

My bad (as expected); it apparently arose because of starting rio on a
small screen and then switching to a larger one. I hvae now set this
up properly, and the problem has disappeared.

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M039ed017e549db172dacbbf5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Mark van Atten]

On Sat, 20 Feb 2021 at 16:26, Russ Cox  wrote:
>
> For what it's worth, you don't need to mount fontsrv anywhere.

That is how I used to do it, as in the man page; but for some,
probably local, reason the problem I described now arises
(actually as of commit 5f0fa18, fontsrv: handle non-BMP runes on X11).
I will look into that, and use the mountpoint in my home dir in the meantime.

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M58a92fdb0b48a23c2bc700b3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Mark van Atten]

It seems to have been some kind of permissions problem. If I run
fontsrv with a mountpoint created in my home directory,
it works perfectly.
Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M4005dd63b8324e8b0133f10d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Mark van Atten]

On Sat, 20 Feb 2021 at 05:51, Bakul Shah  wrote:
> > Note this from the fontsrv man page:
> >
> >   Fontsrv has no support for X11 fonts; on X11 systems, it
> >   will serve an empty top-level directory.
>
> I just tried fontsrv on FreeBSD system and it certainly finds .ttf
> format fonts installed on the system.

It works fine on my Arch, too. On the FreeBSD system, do you find
fontsrv introduces the lags I described?

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M5bad372e794a178b3b494bb0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Mark van Atten]

On Thu, 18 Feb 2021 at 10:04, Skip Tavakkolian
 wrote:
>
> Plan9port has fontsrv. Any truetype you have on your system is usable.
> man fontsrv for details.

On my system (Arch 5.10.16) using fontsrv introduces 2-3 second delays
whenever a program needs to know about the font,
e.g. when opening acme the window first turns all black and then all
white before the columns appear; similarly, lc always takes about
2 seconds before the listing appears.

Do others observe this, too?

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-Mee8deb40c803057d43425172
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] netsurf or opossum

[Mark van Atten]

http://git.pmikkelsen.com/ph/opossum

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-Mf2d9006c5749e4decf646828
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: x11: cursor on a 4k screen

[Mark van Atten]

For rio I mean.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5b64fb7ca310358c-Mbea7a1561f60a256891327fd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] x11: cursor on a 4k screen

[Mark van Atten]

Is there a way to increase the cursor size when using a 4k screen under x11?

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5b64fb7ca310358c-Mca97229da8793e9e4521ba67
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Object Icon, drawterm, riox

[Mark van Atten]

For whomever may find this of interest -- the Object Icon project,
mentioned on this list in passing in August 2018, also caters to Plan
9:

The Object Icon object-oriented programming language:
http://objecticon.sourceforge.net/

Of wider use may be its version of drawterm
http://objecticon.sourceforge.net/Drawterm.html
and its (much) modified rio
http://objecticon.sourceforge.net/Riox.html

Mark.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T888cf1c8059b63ab-M197f28290ef268b93fff0218
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Accessing old Bell labs URLs

[Mark van Atten]

https://9p.io/plan9/index.html

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc38dd191428e8ee3-Mb4367ddd42f26967267d6e2d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] p9p winwatch

[Mark van Atten]

On Mon, Jan 28, 2019 at 10:45 AM Mark van Atten  wrote:

> I use this in combination with rio. It works fine so far, but I may
> well have overlooked some subtle or not so subtle points. It still
> crashes when starting libreoffice, which perhaps doesn't call
> XInitThreads().

I have now repaired this; I was attempting to free memory at a point
where I shouldn't have.

Mark.

[9fans] p9p winwatch

[Mark van Atten]

Thanks to Fazlul Shariar, there is a p9p version of winwatch, available at
https://github.com/fhs/misc/blob/master/cmd/winwatch/winwatch.c

I noticed memory leaks, and sometimes X11's asynchronous ways made it
crash. I put up a slightly modified version at
https://github.com/markvanatten/misc/blob/master/winwatch.c
It has two new options, -s and -w. The first sorts the labels
alphabetically (not case sensitive), the second uses XA_WM_NAME
instead of class.res_name for the label.

I use this in combination with rio. It works fine so far, but I may
well have overlooked some subtle or not so subtle points. It still
crashes when starting libreoffice, which perhaps doesn't call
XInitThreads().

When writing a paper in Sam and having many large windows with pdf and
djvu files   open for reference, I find this very useful to have;
because I use both -s and -w and keep winwatch always in the same
place (along the right edge of my screen), the process of digging up
and foregrounding any of these files has become very quick. From (say)
Sam it takes just two clicks to have them in front of me in the large
size I like to open them to.

Of course, if the winwatch window is narrow, one  will see only an
initial part of the label, so it helps to give your files good names;
but that is true in any case. (And you can always widen the window a
bit.)

I've been thinking about extending the B3 action to a little menu,
perhaps with items to open, close, and toggle the effects of the -s
and -w options, but have made no effort in that direction yet.

Thanks again to Fazlul for porting this in the first place.

Mark.

Re: [9fans] Enter special characters in acme.

[Mark van Atten]

On Tue, Dec 18, 2018 at 3:24 AM Parker Ellertson  wrote:
>
> I'm currently running acme on Debian using plan9port.  I've tried using
> X11's alt-typing (not sure if that's what it's actually called), and
> acme isn't doing squat.  I'll probably never have an actual use for it,
> but it would be nice to know.

Works here (on Arch, but I used the same on FreeBSD and Debian) with this
in my .xinitrc:


9 mklatinkbd -x $PLAN9/lib/keyboard >$HOME/.XCompose
xmodmap -e 'keycode 108 = Multi_key'

# for GNOME and QT programs, add
export GTK_IM_MODULE=xim
export QT_IM_MODULE=xim

# 
https://unix.stackexchange.com/questions/39547/dead-compose-keys-not-working-in-gtk-apps-since-upgrade/65755#65755
export XMODIFIERS=@im=none



Typing ALT, X, four hexadecimal digits works in Acme but not in
Firefox for example. The shorthands listed in
$PLAN9/lib/keyboard do.

Mark.

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

[Mark van Atten]

On Sat, Jun 16, 2018 at 1:58 AM, Iruatã Souza  wrote:

> Did you (or Thierry) tried running LuaTeX? I have "ported" lua ages
> ago to Plan 9 and it was pretty easy, but I know nothing about LuaTex
> internals or the relation between both.

Indeed, I had noted your port with interest, for this reason. But I
would be out of my depth there, so I can't say anything as informed as
what Thierry has written.

Mark.

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

[Mark van Atten]

On Fri, Jun 15, 2018 at 8:13 AM, Mart Zirnask  wrote:

> I'm a part-time writer and radio producer with no CS background, so I
> even use this machine for producing 1-hour radio shows for Estonian
> Public Broadcasting. (Thank you, Non Daw!: http://non.tuxfamily.org).
>
> I just love the "zen" of sam (and, occasionally, Acme) as a writing
> tool. Also, the idea of "everything is a file" kind of grows on you,
> intellectually.

I'm a philosopher and use sam and acme every day to write papers
in LaTeX.

With his KerTeX project, Thierry Laronde has done, and is doing, great
work for TeX on Plan 9.
It would be great to have LuaTeX as well.

I also use p9p and its rio on FreeBSD.

Mark.

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

[Mark van Atten]

On Fri, Jun 15, 2018 at 6:44 PM, Brian L. Stuart  wrote:
> Can't say for LInux, but I run it all the time under 64-bit FreeBSD.

As of 11.0, FreeBSD has its own fdclose() with conflicting types.
https://github.com/0intro/vx32/issues/3

Did you patch it, or are you running an earlier FreeBSD?

Mark.

Re: [9fans] Acme create new file

[Mark van Atten]

On Sun, May 13, 2018 at 3:22 AM, Chris McGee  wrote:

> I’ve been creating new files by executing New to create a new window, typing 
> the full path of the new file and then Put to save it. Am I missing an easier 
> way to do this, perhaps via a directory window where I want the new file?

In the directory window, you can type 'touch myfile' and then select
and execute it with B2.

Mark.

Re: [9fans] What's the fastest way to input command in Acme?

[Mark van Atten]

On Thu, May 10, 2018 at 12:09 PM, hiro <23h...@gmail.com> wrote:
> many people keep an additional text file open as scratchspace and
> command buffer for other winows.
> this is nicer than the multiline p9p tagline or other solutions like
> scrolling sideways in the plan 9 acme.

Agreed.

And obviously such a scratch space can itself be saved, which is useful for
the next editing session of the files in question.

Mark.

Re: [9fans] acme tag bars stacking

[Mark van Atten]

On Fri, Oct 28, 2016 at 4:23 PM, Mathieu Lonjaret
 wrote:
>Probably just because I'm more comfortable looking at things
> at the top half of my screen rather than at the top bottom.

Perhaps that was the very design consideration, but with preference given
to the window in which one is working over tags of other windows.

Mark.

Re: [9fans] Musings on Interfaces

[Mark van Atten]

On Thu, Sep 1, 2016 at 7:20 PM, James A. Robinson  wrote:

> So you couldn't do something like clicking on the start and typing in a
> .,// where  holds the last few words of the text range you
> wanted to select?  I understand not having regular markup like a program,
> but if a few words could be used to identify the end point I would have
> assumed you could use that?

That is convenient in cases where I recall a pattern that otherwise
would require
scrolling to see. Or where I have zeroxed the window and the other one
shows the end of the passage in question.

But otherwise I may as well use k and '.

And of course k and ' (and snarf and paste) work well enough. It is
just that acme's scroll-select
(and chording) is so much more convenient! Chording as such is
possible in p9p sam with one
simple modification in the source, but it is the combination with
scroll-select that counts here.

Mark.

Re: [9fans] Musings on Interfaces

[Mark van Atten]

The one regret I have about sam is that it doesn't do scroll-select. I
write papers rather than programs, and often want to select and
quickly move around large chunks of text whose boundaries are usually
not marked syntactically, even though I use LaTeX.

On the other hand, I find sam a more quiet experience than acme. In
acme it helps to let windows take over the whole column (B3) often.

Mark.

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] 9front sam in plan9port.

[Mark van Atten]

On Sat, May 21, 2016 at 8:30 PM,   wrote:
>> The plan9port version also has chording if in its samterm/main.c you
>> change #define chording 0 to #define chording 1.
>
> It was also marked as being buggy, which is why it remains disabled by 
> default.

I noticed the comment in the source, but also that on my systems
(FreeBSD, Debian) I have never run into trouble with it. This may be
different in other setups. Any experiences?

Mark.

Re: [9fans] 9front sam in plan9port.

[Mark van Atten]

On Sat, May 21, 2016 at 6:31 PM,   wrote:
>> If you mean Russ's project, as referred to on that link, yes.
>
> Hello James.
>
> No, it appears to be the 9front version (2014, with mouse chords in 
> samterm/main.c ), ported to plan9port.

The plan9port version also has chording if in its samterm/main.c you
change #define chording 0 to #define chording 1.

Mark.

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

[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] ctl and search in nupas questiosn

[Mark van Atten]

> but it seems 9fans.net/archive is broken.

http://news.gmane.org/gmane.os.plan9.general

Mark.

Re: [9fans] rtl8169 gbe slow

[Mark van Atten]

Same 9front under virtualbox:

term% time hget -o /dev/null http://mirrors.ctan.org/macros/latex/base.zip
0.06u 0.24s 8.74rhget -o /dev/null
http://mirrors.ctan.org/macros/latex/base.zip

Mark.


On 2/22/16, tlaro...@polynum.com  wrote:
> On Mon, Feb 22, 2016 at 12:17:30PM +, Richard Miller wrote:
>> > It seems that Plan9 is not at fault per se
>>
>> I think it probably is.  Here's another data point (same ADSL connection)
>> -
>
> The delicate point is: is plan9 at fault or it is the fact that it is
> advertised as Plan9 that is the source of this throttling down.
>
> Because I have tested retrieving a 10MB file from another server, under
> plan9 (http://mirrors.ctan.org/macros/latex/base.zip) and I have good
> results on par with what I have under NetBSD (same node; dualboot).
>
> So I think the ethernet layer (the rtl8169) is not at fault. Perhaps
> another IP layer is at fault (bad negociation under some circonstances
> leading to very small packets). Or the server is throttling down
> the connection, whether explicitely because it is Plan9/hget (used
> by some? as bittorrent utility, or the string used etc.) or simply
> because there is a rule that everything not recognized/authorized
> (ie, chrome, mozilla, wget, ftp, lftp) is considered a robot, and
> is throttled down...
>
>>
>> #l0: i82579: 1Gbps port 0xFE50 irq 10: 386077f0e800
>> 0.09u 0.08s 182.26r   hget
>> http://downloads.kergis.com/kertex/kertex_bundle.tar
>>
>> But on the same machine, using linux instead:
>>
>> $ time wget -o /dev/null
>> http://downloads.kergis.com/kertex/kertex_bundle.tar
>>
>> real 0m9.134s
>> user 0m0.048s
>> sys  0m0.186s
>>
>
> --
> Thierry Laronde 
>  http://www.kergis.com/
>  http://www.arts-po.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>
>

Re: [9fans] rtl8169 gbe slow

[Mark van Atten]

I observe the same on Debian 8.3 64 bit (the machine on which I run
9front in a virtualbox, giving the result I reported earlier today):

; time wget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
0.16u 0.57s 8.39r wget -o /dev/null
http://downloads.kergis.com/kertex/kertex_bundle.tar

Mark.

Re: [9fans] rtl8169 gbe slow

[Mark van Atten]

Dear Thierry,

> If someone under Plan9 could try to download with hget(1):
>
> http://downloads.kergis.com/kertex/kertex_bundle.tar
>
> and give me the time (it is a 10MB file) to do so,

0.10u 0.22s 192.79r   hget -o kertex_bundle.tar
http://downloads.kergis.com/kertex/kertex_bundle.tar

This is under 9front under virtualbox 4.3.32.

Mark.

Re: [9fans] rtl8169 gbe slow

[Mark van Atten]

> i think that david has a mirror up, and 9fs sources still works here.

http://9p.io/

Mark.

Re: [9fans] 9vx on OSX

[Mark van Atten]

On my machine at least it suffers from breaking window corners
when changing the window size with B1.

The source of this Lion version should be useful for someone wishing to
adapt 9vx.OSX to Yosemite. But I have only been able to find the binary.

Mark.

Re: [9fans] 9vx on OSX

[Mark van Atten]

There is a 9vx binary built for Lion on Jan 27, 2012 at
http://code.google.com/p/nix-os/source/browse/9vx.OSX

Just tried it out briefly on Yosemite (10.10.5), and, within the limits
of such a short attempt, I can say that it seems to work.
Going full screen at first left a part on the right blank, but this
was restored later on.

Mark.

Re: [9fans] Replacement for find

[Mark van Atten]

On Wed, Sep 30, 2015 at 12:07 PM, Steve Simon  wrote:

> NB: don't use sed or awk, they don't understand the shells
> quoting convention for filenames containing frogs.

That's a good point.

Mark.

Re: [9fans] ftpfs shows empty /n/ftp after login

[Mark van Atten]

Admittedly not exactly the same thing, but still: 9vx works very well
on FreeBSD,
and gives immediate access to the host's files.

Mark.

Re: [9fans] P9p from osx to ubuntu

[Mark van Atten]

On Sat, Apr 18, 2015 at 10:35 AM, jordi collell jor...@gmail.com wrote:

 Another think.. But this is not related to the switch. Someone can share
 some script for having two acme instance working with plumbers on different
 namespaces?

http://thread.gmane.org/gmane.os.plan9.general/67679/focus=67684

Mark.

Re: [9fans] once more: drawterm osx-x11 on x86-64

[Mark van Atten]

On 28 Feb 2015 02:21, Jeff Sickel j...@corpus-callosum.com wrote:

 The older versions of drawterm just map a large view to fill
 the whole screen and then clip the view to the window size you’ve
 selected.
[etc.]

thanks for the explanation. i
hadn't quite realised this, as
i usually resize only once, to
full screen, and never reduce after that.

i should also have taken a look at the code.

mark.

Re: [9fans] noob question: p9 nfs client

[Mark van Atten]

On Sat, Feb 28, 2015 at 12:02 AM, Mark van Atten vanattenm...@gmail.com wrote:

 What am I missing?

That mount(1) here needs a spec argument:

cpu% mount /srv/macmini mac Users/mva

That works.

What made me overlook this was perhaps an unconscious presupposition
that, if only one tree is specified in the server's /etc/exports,
there should be no need to specify it.

Mark.

[9fans] noob question: p9 nfs client

[Mark van Atten]

On an OSX 10.9.5 host I run Bell Labs Plan 9 in Virtualbox.

Both have fixed IP addresses:
OSX 192.168.1.152
Plan 9 192.168.1.156

On OSX I have this in /etc/exports:
/Users/mva -mapall=501:20 -alldirs

I'm trying to access /Users/mva from Plan 9 through NFS:

cpu% nfs -v -R -p 666 -s macmini 192.168.1.152
out: xid=0x0 prog 0x186a0 vers 0x2 proc 0x3 [none] [none]
PortTGetport [15 3 17 0]
send e67c8ecf 3443508661 3443509661
in: xid=0xe67c8ecf status 0x0 [none] low 0x0 high 0x0
in: xid=0xe67c8ecf status 0x0 [none] low 0x0 high 0x0
in: PortRGetport 799
out: xid=0x0 prog 0x186a0 vers 0x2 proc 0x3 [none] [none]
PortTGetport [13 3 17 0]
send e67c8ed0 3443508930 3443509930
in: xid=0xe67c8ed0 status 0x0 [none] low 0x0 high 0x0
in: xid=0xe67c8ed0 status 0x0 [none] low 0x0 high 0x0
in: PortRGetport 2049
nfs udp!192.168.1.152!799!r udp!192.168.1.152!2049!r
out: xid=0x0 prog 0x186a5 vers 0x3 proc 0x0 [none] [none]
NfsMount3TNull

send 76381d71 3443509217 3443510217
in: xid=0x76381d71 status 0x0 [none] low 0x0 high 0x0
in: xid=0x76381d71 status 0x0 [none] low 0x0 high 0x0
in: NfsMount3RNull

out: xid=0x0 prog 0x186a3 vers 0x3 proc 0x0 [none] [none]
Nfs3TNull

send ac0de7b5 3443509383 3443510383
in: xid=0xac0de7b5 status 0x0 [none] low 0x0 high 0x0
in: xid=0xac0de7b5 status 0x0 [none] low 0x0 high 0x0
in: Nfs3RNull

cpu% aux/nfsmount 192.168.1.152
connecting to udp!192.168.1.152!portmap
connecting to udp!192.168.1.152!799!r
/Users/mva


But then this fails:

cpu% mkdir mac
cpu% mount /srv/macmini mac
creds for mva: 
000D3139322E3136382E312E313536
00

out: xid=0x0 prog 0x186a5 vers 0x3 proc 0x1 [sys] [none]
NfsMount3TMnt
path=/

send 76381d72 3443716564 3443717564
in: xid=0x76381d72 status 0x0 [none] low 0x0 high 0x0
in: xid=0x76381d72 status 0x0 [none] low 0x0 high 0x0
in: NfsMount3RMnt
status=13

mount: mount mac: access denied


I imagine it is a problem with permissions; 
on the other hand I thought the mapall in 
the hosts' /etc/exportfs would take care of that.

What am I missing?

Mark.

Re: [9fans] once more: drawterm osx-x11 on x86-64

[Mark van Atten]

Sorry, last night it was getting too late and I confused.

It is drawterm-cocoa CONF=osx-cocoa that still shows the flickering 
and the broken  window edges.

drawterm-cocoa CONF=osx-x11 works fine (but to be able to build it, 
I had to copy some header files that were not found 
(although present in the tree) to ./include.

Sorry for the noise.

Mark.

Re: [9fans] once more: drawterm osx-x11 on x86-64

[Mark van Atten]

With the X11 version, drawterm can be resized with B1, 
and with xshove it can be  turned full screen. 
(On X11, I use p9p's rio as my wm.)

I look forward to any changes you may come up with; 
and many thanks for the work you have done so far!

Mark.

[9fans] once more: drawterm osx-x11 on x86-64

[Mark van Atten]

A while ago, I reported on a problem I had with flicker and broken window edges
in drawterm-cocoa CONF=osx-x11. See the email copied below. It led to a brief
exchange.

With my present configuration, that problem remains:
OSX 10.9.5
drawterm-cocoa 2014-12-02

However, I just tried rsc's drawterm 2013-07-02,
and there the problem is absent.

I take it there are not many users of drawterm on OSX,
either jas' or rsc's distribution, who
use the x11 version -- are there? I'd be interested
to compare notes.

Best wishes,
Mark.



From: Mark van Atten vanattenmark@gma...
Subject: drawterm osx-x11 on x86_64
Date: Thu, 21 Nov 2013 11:40:14 +0100

For the record---to compile drawterm
(http://code.google.com/p/drawterm/) with CONF=osx-x11 on x86_64 (in
my case running 10.8.5), just add the required substitution to the
makefile:

Make.osx-x11

20 - arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/'`; \
20 + arch=`uname -m|sed 's/i.86/386/;s/Power
Macintosh/power/;s/x86_64/amd64/'`; \

For the moment, I prefer this to drawterm-cocoa because there is no
flicker, and window borders remain intact when reshaping with B1 or
B2.

Mark.

Re: [9fans] Persistent font in Acme.

[Mark van Atten]

You can write a little script whose only task is to start acme with
your favourite parameters.

Mark.

Re: [9fans] Acme, Edit, code and newline

[Mark van Atten]

On Mon, Mar 31, 2014 at 5:54 PM, Daniel Peyrolon tucha...@gmail.com wrote:
 Edit , x/^[^ ]+[ ]*[^(]*\([^)]*\)[ ]*\{[ ]*\n/ s/[ ]*\{[ ]*\n/\n\{/g

 So, it was simply a matter of changing $ for \n at the x command!

Yes. (In the version I gave, the replacement of the second $, the one
in the s command, by \n was superfluous.)

 How come my command didn't work?
 It really should work with the $, shouldn't it?

In the original version, the x command matches up to the end of the
line, but the resulting selection is no longer itself a line; so the
subsequent s command, trying to match various things and then the
empty string at the end of a line ($), does not succeed.

But replacing, in the x command, the $ by \n leaves the result of a
match (now one character longer because it includes the \n) a line, in
which the s command then successfully matches $.

As ever,
Mark.

Re: [9fans] Acme, Edit, code and newline

[Mark van Atten]

Edit , x/^[^ ]+[ ]*[^(]*\([^)]*\)[ ]*\{[ ]*\n/ s/[ ]*\{[ ]*\n/\n\{/g

Mark.

Re: [9fans] Acme, Edit, code and newline

[Mark van Atten]

 \ before { is not necesary.

Don't know how I got that one in there; thanks for catching it!

Mark.

Re: [9fans] Python/Mercurial error

[Mark van Atten]

Attaching a
 screenshot. I still can't seem to copy text to/from virtualbox.

One thing you can do is to run Plan 9 in virtualbox but use drawterm
on the host to access it. Then you
can copy/paste from the drawterm window.

Mark.

Re: [9fans] usb configuration

[Mark van Atten]

Yes, I also use the DY651A, and like you am very happy with it.

I wasn't aware that it is also available under a different brand;
thanks for mentioning it.

Mark.

Re: [9fans] Alternative Plan 9 Logo

[Mark van Atten]

 It somehow makes me think about Alice in wonderland falling down the rabbit
 hole... Will she meet a Glenda nervously looking at the clock?

Very nice!

Mark.

Re: [9fans] Spell checking with acme in p9p

[Mark van Atten]

 Sometimes, like when you issue a command and the result goes to the Errors
 window, I would like to be able to execute text in the Errors window that
 would affect the window the Error window represents.  This would be very
 powerful.

If the original window already has the Edit command in the tag, and
the commands in +Error (or some other window) are in sam's language,
you can select those commands with B1 and then execute them in the
context of the original window by a B2-B1 chord on that window's Edit.

Closely related:
http://9fans.net/archive/2009/06/138

Mark.

Re: [9fans] Acme: fonts

[Mark van Atten]

cd /usr/local/plan9/src/cmd/fontsrv/
9 mk install

works fine on my system (p9p on OSX 10.8.5)

Mark.


On Wed, Dec 11, 2013 at 9:12 PM, Rubén Berenguel ru...@mostlymaths.net wrote:
 In my current computer the fonts look as crisp as any native Mac app, except
 for slashes where some jagginess can be seen on close inspection. Usually
 I'm not close enough to the computer to notice, but large fonts have this
 (currently I'm using Cochin 20 and AnonymousPro 16) To get Monaco or any
 other otf font from the system you actually need to compile and runt
 fontsrv. I think I had to go through some hoops to compile it (don't
 remember exactly, it was 4 months ago) but essentially should be going to
 the fontsrv directory and mk (I guess some uncommenting was needed somewhere
 in a makefile) once you have it, run it with  to keep it live to list all
 fonts with 9p ls font to see what's available.

 Ruben


 On Wed, Dec 11, 2013 at 9:04 PM, Blake McBride bl...@mcbride.name wrote:

 Your font does look better than what I have (but not perfect).  Monaco
 didn't come with 9p9.  Where did you get that?

 I am changing font via the Acme Font command on the tag line; i.e.

  Font /usr/local/plan9port/font/fixed/unicode.9x15B.font

 It is changing the font.  The change is obvious.

 Since most Mac (or Linux) apps have fonts that appear smoothly, fonts
 without significant compression exist.  How can I get uncompressed / much
 higher resolution fonts for acme?

 Thanks.

 Blake



 On Wed, Dec 11, 2013 at 1:53 PM, Rubén Berenguel ru...@mostlymaths.net
 wrote:

 Check here:

 https://vimeo.com/64487176

 The slight pixelation comes from the video compression. The font is
 Monaco, on my old Macbook

 How are you exactly changing fonts, though?


 On Wed, Dec 11, 2013 at 8:50 PM, Blake McBride bl...@mcbride.name
 wrote:

 I checked.  fontsrv didn't compile.  I'm sure I can get it to compile
 but I don't see the point.  Acme comes up, I can change fonts, etc..  What
 will fontsrv buy me?

 Incidentally, when I look on the net at picture or videos of acme, the
 fonts they show on all of those are pixilated too.  See:

 https://upload.wikimedia.org/wikipedia/commons/9/98/Acme.png
 http://research.swtch.com/acme

 Those look like mine.  Obviously it is highly usable, but the fonts
 shown are pixilated and not smooth like fonts that come with the Mac, 
 Linux,
 etc.

 Thanks.



 On Wed, Dec 11, 2013 at 1:33 PM, Rubén Berenguel ru...@mostlymaths.net
 wrote:

 When I installed p9ports in my new Macbook Air (around 4 months ago),
 fontsrv didn't compile out of the box, I had to compile it separately. 
 For
 me all available fonts read perfectly well and sharp (Mac OS X 10.9 on Air
 13 and Mac OS X 10.6.8 on Macbook 13)

 Regards,

 Ruben


 On Wed, Dec 11, 2013 at 8:26 PM, s...@9front.org wrote:

  still a bit pixilated

 1 bit fonts are legible. this is a feature.

 sl

Re: [9fans] Acme: fonts

[Mark van Atten]

On Wed, Dec 11, 2013 at 9:30 PM,  s...@9front.org wrote:
 It's a matter of taste, but I prefer the sharpness of the 1 bit fonts. The 
 gray,
 fuzzy stuff eventually takes a toll on my eyes.

 s/taste/eyesight/, perhaps?

 Perhaps, but I like to think differences of opinion don't necessarily
 indicate physical disability.

 sl

When I began using acme, sam, 9term, I much cared about ttf fonts. But
I, too, have come to prefer the sharpness of the 1 bit fonts.

Perhaps a case of acquisition of a taste catalysed by decreasing eyesight.

Now I usually start acme from standard 9term with
acme -f $font
so it uses lucm/unicode.9.font (this on a 27 1920x1080 screen).

Mark.

Re: [9fans] Acme: fonts

[Mark van Atten]

On Wed, Dec 11, 2013 at 10:56 PM, Blake McBride bl...@mcbride.name wrote:
 Interesting.  On the bottom it says fontsrv has no support for X11.  Is
 there a way to use the fonts that come with Linux?

It does support X11 now.

Mark.

Re: [9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

Same difference under qemu 1.6.1 instead of virtualbox 4.3.0.

Does anyone have experiences to share? If not, then perhaps whatever the
issue is on my setup is too local.

Mark.



On Mon, Nov 25, 2013 at 6:44 PM, Mark van Atten vanattenm...@gmail.comwrote:

 Simply pinging the virtualbox cpu server gives, over a number of tests,
 avg rtt around 150 µs  from both osx-x11 and osx-cocoa drawterms.
 (Indeed, the latest push of osx-cocoa no longer gives the warning.)

 I hope at some point it will become clear what is the matter---perhaps, as
 you suggest, in my setup; although so far I don't see why the different
 results I get should be due to that. Let me know if I haven't given enough
 data.

 And certainly the fullscreen integration of your version is nice!

 Mark.

Re: [9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

Simply pinging the virtualbox cpu server gives, over a number of tests, avg
rtt around 150 µs  from both osx-x11 and osx-cocoa drawterms. (Indeed, the
latest push of osx-cocoa no longer gives the warning.)

I hope at some point it will become clear what is the matter---perhaps, as
you suggest, in my setup; although so far I don't see why the different
results I get should be due to that. Let me know if I haven't given enough
data.

And certainly the fullscreen integration of your version is nice!

Mark.

Re: [9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

On Fri, Nov 22, 2013 at 1:02 AM, Jeff Sickel j...@corpus-callosum.com wrote:

 Will one of you describe the flicker you speak of?  I see flicker on
 Linux’s drawterm X11 when resizing rio windows and other operations,
 given the round trip time, though the flicker is less on fast local
 networks.

You are right, of course, that the presence of flicker may depend on
various things, and my original message was too elliptic.

I drawterm only to a virtual machine on the same computer.

My setup: Mac Mini Late 2012 with 10.8.5. Virtual machine:  Virtualbox
4.3.0, Bell Labs iso, 1024MB system memory, VT-x/AMD-V and Nested
Paging on, 32 MB video memory, Intel PRO/1000 MT Desktop bridged
adapter en1 Wi-Fi (AirPort). Mountain Lion's DHCP server enabled.

Drawterm for osx-x11 built from the current sources at
http://code.google.com/p/drawterm/
Drawterm for osx-cocoa built from the current sources at
https://bitbucket.org/jas/drawterm-cocoa

In the cocoa version, when sweeping a rio window all borders will
flicker continuously.  On resizing with B1 or B2, in addition to the
flicker,  border lines will fail to meet or meet but not at the
corner. All this independently of window size and sweep speed. When
creating a new window in sam, three or all corners always break open a
little.

In the x11 version, when sweeping normally, there will be no flicker
at any size, and, when sweeping quickly, flicker on one side only (the
side where the mouse pointer is). I haven't seen border lines fail to
meet or meet at the wrong place, whether in rio or in sam.

Mark.

Re: [9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

Well, I wrote `the current sources', but that was wrong: I just
checked bitbucket again and saw your commits of the last few hours. So
I pulled the updates and rebuilt. To my surprise, the phenomena remain
exactly the same. This time I got a message though:

objc[3785]: Object 0x7fb261297930 of class NSConcreteMapTable
autoreleased with no pool in place - just leaking - break on
objc_autoreleaseNoPool() to debug

Mark.


On Fri, Nov 22, 2013 at 10:05 AM, Mark van Atten vanattenm...@gmail.com wrote:
 On Fri, Nov 22, 2013 at 1:02 AM, Jeff Sickel j...@corpus-callosum.com wrote:

 Will one of you describe the flicker you speak of?  I see flicker on
 Linux’s drawterm X11 when resizing rio windows and other operations,
 given the round trip time, though the flicker is less on fast local
 networks.

 You are right, of course, that the presence of flicker may depend on
 various things, and my original message was too elliptic.

 I drawterm only to a virtual machine on the same computer.

 My setup: Mac Mini Late 2012 with 10.8.5. Virtual machine:  Virtualbox
 4.3.0, Bell Labs iso, 1024MB system memory, VT-x/AMD-V and Nested
 Paging on, 32 MB video memory, Intel PRO/1000 MT Desktop bridged
 adapter en1 Wi-Fi (AirPort). Mountain Lion's DHCP server enabled.

 Drawterm for osx-x11 built from the current sources at
 http://code.google.com/p/drawterm/
 Drawterm for osx-cocoa built from the current sources at
 https://bitbucket.org/jas/drawterm-cocoa

 In the cocoa version, when sweeping a rio window all borders will
 flicker continuously.  On resizing with B1 or B2, in addition to the
 flicker,  border lines will fail to meet or meet but not at the
 corner. All this independently of window size and sweep speed. When
 creating a new window in sam, three or all corners always break open a
 little.

 In the x11 version, when sweeping normally, there will be no flicker
 at any size, and, when sweeping quickly, flicker on one side only (the
 side where the mouse pointer is). I haven't seen border lines fail to
 meet or meet at the wrong place, whether in rio or in sam.

 Mark.

[9fans] right arrow blocked before closing bracket

[Mark van Atten]

In Plan 9 acme, if you type

{}

then go back and type text between the brackets

{Curiouser and curiouser!}

the right arrow is blocked when you want to go over the closing
bracket to continue typing to its right. (If you first go to the left,
and then back to the right, it works.)

Same for the other brackets: [ ], ( ),  .

In p9p acme, and also in Plan 9 sam and rio, this works fine.

Perhaps a patch already exists?

Mark.

[9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

For the record---to compile drawterm
(http://code.google.com/p/drawterm/) with CONF=osx-x11 on x86_64 (in
my case running 10.8.5), just add the required substitution to the
makefile:

Make.osx-x11

20 - arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/'`; \
20 + arch=`uname -m|sed 's/i.86/386/;s/Power
Macintosh/power/;s/x86_64/amd64/'`; \

For the moment, I prefer this to drawterm-cocoa because there is no
flicker, and window borders remain intact when reshaping with B1 or
B2.

Mark.

Re: [9fans] acme/sam language question

[Mark van Atten]

 I finally get around to trying this out and (so far) it seems to work.
 Thank you!

You're welcome!

Opening the group at the end of the first line has the effect of
replacing the empty command and its implied p; see sam's man page
under `Miscellany'. This also explains why your lines, without the
grouping, had the desired effect when you executed them one by one
yourself, but not when executed from a script.

Mark.

Re: [9fans] Help with plumbing rules

[Mark van Atten]

 PS: Once I get this working I'll tackle the diagnostic messages I get when
 compiling Java code using maven (not my choice).  They look like
 [error] /home/pcanning/src/java/test/PerfTest.java:[66,1] error: reached end
 of file while parsing

For lacheck, a Latex checker, I have this in my profile to put its
messages in the right form:

# for lacheck: format output for acme
fn lacheck $* {builtin lacheck $* | 9 sed 's/(.*).*line ([0-9]+):
(.*)/\1:\2:\3/'}

Can you do something similar?

Mark.

Re: [9fans] acme/sam language question

[Mark van Atten]

I write the script like this:

/A/+#0;/B/-#0 {
g/CC/ s/CC/DD/g
}
p

Mark.


On Wed, Nov 6, 2013 at 7:47 PM, Rudolf Sykora rudolf.syk...@gmail.com wrote:
 On 31 October 2013 20:24, Rudolf Sykora rudolf.syk...@gmail.com wrote:
 On 31 October 2013 16:49, Friedrich Psiorz f.psi...@gmx.de wrote:
 It works for me, but I found another inconsistency.

 I tried it on p9p and 9vx, both in acme and sam.

 /A/+#0;/B/-#0
 g/CC/ s/CC/DD/g
 p

 Well. If I use these commands one by one inside p9p acme
 (and probably sam, too), I truly get what I want (and what
 you say). The problem appears when I want to run it from
 a script like this:

 sam -d EOF $1  [2] /dev/null
 /A/+#0;/B/-#0
 g/CC/ s/CC/DD/g
 p
 EOF

 then you get, since the g is on a seperate line, an extra
 output from the line before g. And if you try to join g with
 the match like

 sam -d EOF $1  [2] /dev/null
 /A/+#0;/B/-#0 g/CC/ s/CC/DD/g
 p
 EOF

 then you get no output if CC is not between A and B
 (although when it is there, you get what I want).
 In neither case I am fully satisfied. :)

 Thanks
 Ruda

 So far I still do not know how to do it properly...
 But it seems nobody here proposes anything...

 Thanks for any clue
 Ruda

Re: [9fans] network support on virtualbox

[Mark van Atten]

Works like a charm, many thanks for this!
Mark.

Re: [9fans] sam resizing

[Mark van Atten]

Thanks for the comments!

My screen is large, and I use the space the way Ingo describes,
putting the edit buffer in the top left corner. But I'd be interested
to have the extra option for a while and see if I do find this as
useful as it now seems; when I find the time, I may be able to find
out how to do this.

As for acme, I agree that its auto layout works well. In particular I
like how you can make the window you are concentrating on take up the
whole column and restore that column's stack of windows afterward.
Although the window you enlarged ends up on top, and not necessarily
in its original position,  in acme that is far less important than it
might be in sam. (And in cases where one cares sufficiently about
fixed places one can always B2 on Sort.)

An edit buffer in acme would be very interesting to experiment with.

Mark.

[9fans] sam resizing

[Mark van Atten]

I would find it useful if a sam window resize could be undone one
step, i.e. resize the window again to its size and position before the
last resize. Perhaps by clicking B1, just as clicking B3 enlarges it.

That would help keeping windows arranged a bit while enlarging one
after the other as I see fit for my work.

One can of course do without the visual clue of such an arrangement
and rely on just the file list in the menu. When there are many files,
there is no choice, and that works well enough. But when working on
only a handful, it might be convenient to have this additional
possibility by just one click.

Have people experimented with this, or at least entertained the same wish?

Mark.

Re: [9fans] NFD and p9p acme on OSX

[Mark van Atten]

Thank you, Erik, for your comments!

I just realized that in

fn ls {
builtin ls $* | iconv -f UTF8-MAC -t UTF-8
}

one needs

u iconv

because otherwise it picks the wrong iconv when executing this
redefined ls in contexts where $PLAN9/bin occurs in the path first;
for example, try

9 man cat

with the uncorrected redefinition of ls.

As ever,
Mark.



On Thu, Sep 12, 2013 at 4:17 PM, erik quanstrom quans...@quanstro.net wrote:
 On Thu Sep 12 05:41:19 EDT 2013, vanattenm...@gmail.com wrote:
 Running p9p on OSX, I find it useful to put this in my rc profile:

 fn ls {
 builtin ls $* | iconv -f UTF8-MAC -t UTF-8
 }

 fn lc {
 builtin lc $* | iconv -f UTF8-MAC -t UTF-8
 }

 so as to deal with the NFD used by the OSX file system and list
 names containing non-ascii characters correctly.

 But this doesn't solve the corresponding problem when clicking B3 to
 open a directory in acme.

 Am I overlooking something? If not, what do people use to deal with
 this---perhaps a patch to lib9?

 i created something similar for plan 9.  it uses runecompose
 (see runeclass(2), http://9atom.org/magic/man2html/2/runeclass)
 this uses tables built by awk scripts directly from unicodedata.txt.
 there is a rune/compose (see rune(1), http://9atom.org/magic/man2html/1/rune)
 that makes it possible to write
 fn lc {builtin lc $* | rune/compose}

 but i agree, one would like a more systemic solution.  cooking this
 into stat/wstat wouldn't work, because the file name text might escape
 p9p and cause the rest of the system to be confused.

 perhaps runecompose and runedecompose (or equivalent) could be
 cooked into fullrune, chartorune, runetochar, etc.  (for apple oses only?)
 the big pain point would be dealing with the fact that chartorune
 could create up to maxcombiners*4 bytes of utf-8, and fullrune might
 need that size buffer to convert one rune.  it's easy to grep for these
 use cases.

 - erik

[9fans] NFD and p9p acme on OSX

[Mark van Atten]

Running p9p on OSX, I find it useful to put this in my rc profile:

fn ls {
builtin ls $* | iconv -f UTF8-MAC -t UTF-8
}

fn lc {
builtin lc $* | iconv -f UTF8-MAC -t UTF-8
}

so as to deal with the NFD used by the OSX file system and list
names containing non-ascii characters correctly.

But this doesn't solve the corresponding problem when clicking B3 to
open a directory in acme.

Am I overlooking something? If not, what do people use to deal with
this---perhaps a patch to lib9?

Mark.

Re: [9fans] International Ispell in Plan9

[Mark van Atten]

That's interesting work---thanks!

Mark.

[9fans] Plan 9's clock for p9p

[Mark van Atten]

I find Plan 9's clock more pleasing to the eye than, say, xclock. The
required changes to run it on p9p are minimal. Here it is:

https://codereview.appspot.com/8269048/

As ever,
Mark.

--
PLEASE NOTE MY NEW E- ADDRESS
vanattenmark
at
gmail.com

Re: [9fans] Plan 9's clock for p9p

[Mark van Atten]

Indeed, I should have mentioned that Andrey Mirtchovski did a port at
a time when p9p didn't have etimer(3) yet.

http://mirtchovski.com/p9/clock/

A while ago I had trouble compiling that one, but I don't recall the details.

At some point etimer was added to p9p, allowing for a port of clock
whose code is closer to the original.

As ever,
Mark.


On Wed, Apr 10, 2013 at 1:53 PM, Jacob Todd jaketodd...@gmail.com wrote:
 I think there's a port of clock for p9p on sources, though I don't remember
 where it was.



-- 
PLEASE NOTE MY NEW E- ADDRESS
vanattenmark
at
gmail.com

Re: [9fans] documentation suggestion

[Mark van Atten]

Here is the patch, which I have submitted to codereview.

It adds an option -t to p9p acme, which restores the Plan 9 tag style.

Mark.

 
diff -r ff3404f79037 src/cmd/acme/acme.c
--- a/src/cmd/acme/acme.c   Sat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/acme.c   Fri Apr 05 22:52:55 2013 +0200
@@ -113,6 +113,9 @@
case 'r':
swapscrollbuttons = TRUE;
break;
+   case 't':
+   neverexpandtag = TRUE;
+   break;
case 'W':
winsize = ARGF();
if(winsize == nil)
diff -r ff3404f79037 src/cmd/acme/dat.h
--- a/src/cmd/acme/dat.hSat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/dat.hFri Apr 05 22:52:55 2013 +0200
@@ -548,6 +548,7 @@
 intglobalautoindent;
 intdodollarsigns;
 char*  mtpt;
+intneverexpandtag;
 
 enum
 {
diff -r ff3404f79037 src/cmd/acme/rows.c
--- a/src/cmd/acme/rows.c   Sat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/rows.c   Fri Apr 05 22:52:55 2013 +0200
@@ -289,9 +289,9 @@
/* Expand tag if necessary */
if(t-what == Tag){
t-w-tagsafe = FALSE;
-   if(r == '\n')
-   t-w-tagexpand = TRUE;
-   winresize(w, w-r, TRUE, TRUE);
+   if(r == '\n'  neverexpandtag == FALSE)
+   t-w-tagexpand = TRUE; 
+   winresize(w, w-r, TRUE, TRUE);
}
winunlock(w);
}
diff -r ff3404f79037 src/cmd/acme/text.c
--- a/src/cmd/acme/text.c   Sat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/text.c   Fri Apr 05 22:52:55 2013 +0200
@@ -662,8 +662,12 @@
Rune *rp;
Text *u;
 
-   if(t-what!=Body  t-what!=Tag  r=='\n')
-   return;
+   if(t-what!=Body   r=='\n'){
+   if(t-what!=Tag) 
+   return;
+   if(neverexpandtag == TRUE)
+   return;
+   }   
if(t-what == Tag)
t-w-tagsafe = FALSE;
 
@@ -756,9 +760,9 @@
 
Tagdown:
/* expand tag to show all text */
-   if(!t-w-tagexpand){
+   if(neverexpandtag == FALSE){
t-w-tagexpand = TRUE;
-   winresize(t-w, t-w-r, FALSE, TRUE);
+   winresize(t-w, t-w-r, FALSE, TRUE); 
}
return;

diff -r ff3404f79037 src/cmd/acme/wind.c
--- a/src/cmd/acme/wind.c   Sat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/wind.c   Fri Apr 05 22:52:55 2013 +0200
@@ -24,7 +24,8 @@
 
w-tag.w = w;
w-taglines = 1;
-   w-tagexpand = TRUE;
+   if(neverexpandtag == FALSE)
+   w-tagexpand = TRUE;
w-body.w = w;
w-id = ++winid;
incref(w-ref);

[9fans] p9p acme: -t option for single line tags

[Mark van Atten]

Here is a patch for p9p acme. It adds an option -t which gives
single-line tags as in Plan 9 acme.

Mark.

 diff -r ff3404f79037 src/cmd/acme/acme.c
--- a/src/cmd/acme/acme.c Sat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/acme.c Sun Apr 07 14:27:42 2013 +0200
@@ -113,6 +113,9 @@
case 'r':
swapscrollbuttons = TRUE;
break;
+ case 't':
+ neverexpandtag = TRUE;
+ break;
case 'W':
winsize = ARGF();
if(winsize == nil)
@@ -120,7 +123,7 @@
break;
default:
Usage:
- fprint(2, usage: acme -a -c ncol -f fontname -F fixedwidthfontname -l 
loadfile -W winsize\n);
+ fprint(2, usage: acme -a -c ncol -f fontname -F fixedwidthfontname -l 
loadfile -t -W winsize\n);
threadexitsall(usage);
}ARGEND

diff -r ff3404f79037 src/cmd/acme/dat.h
--- a/src/cmd/acme/dat.h Sat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/dat.h Sun Apr 07 14:27:42 2013 +0200
@@ -548,6 +548,7 @@
int globalautoindent;
int dodollarsigns;
char* mtpt;
+int neverexpandtag;

enum
{
diff -r ff3404f79037 src/cmd/acme/rows.c
--- a/src/cmd/acme/rows.c Sat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/rows.c Sun Apr 07 14:27:42 2013 +0200
@@ -289,7 +289,7 @@
/* Expand tag if necessary */
if(t-what == Tag){
t-w-tagsafe = FALSE;
- if(r == '\n')
+ if(r == '\n'  neverexpandtag == FALSE)
t-w-tagexpand = TRUE;
winresize(w, w-r, TRUE, TRUE);
}
diff -r ff3404f79037 src/cmd/acme/text.c
--- a/src/cmd/acme/text.c Sat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/text.c Sun Apr 07 14:27:42 2013 +0200
@@ -662,8 +662,12 @@
Rune *rp;
Text *u;

- if(t-what!=Body  t-what!=Tag  r=='\n')
- return;
+ if(t-what!=Body  r=='\n'){
+ if(t-what!=Tag) 
+ return;
+ if(neverexpandtag == TRUE)
+ return;
+ } 
if(t-what == Tag)
t-w-tagsafe = FALSE;

@@ -756,7 +760,7 @@

Tagdown:
/* expand tag to show all text */
- if(!t-w-tagexpand){
+ if(neverexpandtag == FALSE){
t-w-tagexpand = TRUE;
winresize(t-w, t-w-r, FALSE, TRUE);
}
diff -r ff3404f79037 src/cmd/acme/wind.c
--- a/src/cmd/acme/wind.c Sat Jan 19 10:05:12 2013 +0100
+++ b/src/cmd/acme/wind.c Sun Apr 07 14:27:42 2013 +0200
@@ -24,7 +24,8 @@

w-tag.w = w;
w-taglines = 1;
- w-tagexpand = TRUE;
+ if(neverexpandtag == FALSE)
+ w-tagexpand = TRUE;
w-body.w = w;
w-id = ++winid;
incref(w-ref);

Re: [9fans] documentation suggestion

[Mark van Atten]

On Thursday, 4 April 2013 18:47:12 UTC+2, a...@9srv.net  wrote:
 I have not tried this, but I suspect that if you change
 
 w-tagexpand to FALSE in /src/cmd/acme/wind.c:/^wininit
 
 and recompile, you'll get the Plan 9 behavior. The code
 
 paths are still a bit different, but on cursory examination it
 
 looks like that'll give you what you want.

Thanks for the suggestion! 

I just tried it. Indeed, it puts the tag of a new window in Plan
9 mode. But it does not yet suffice for a full restore, because
hitting return makes the tag multiline again.

I'll look further into it when I have some time.

Mark.

Re: [9fans] documentation suggestion

[Mark van Atten]

On Thursday, 4 April 2013 18:47:12 UTC+2, a...@9srv.net  wrote:
 I have not tried this, but I suspect that if you change
 
 w-tagexpand to FALSE in /src/cmd/acme/wind.c:/^wininit
 
 and recompile, you'll get the Plan 9 behavior. The code
 
 paths are still a bit different, but on cursory examination it
 
 looks like that'll give you what you want.
 
 
 
 Anthony

I've now set w-tagexpand or t-w-tagepand to FALSE, and commented
out subsequent statements, in three files: rows.c, text.c, and
wind.c, and now it works as desired.

I should add an option to acme and submit a patch: the multiline tag
is clearly something that pleases some and annoys others.

Mark.

Re: [9fans] documentation suggestion

[Mark van Atten]

Subject: Re: [9fans] documentation suggestion

On Friday, 5 April 2013 11:05:56 UTC+2, Mark van Atten  wrote:

 I've now set w-tagexpand or t-w-tagepand to FALSE, and commented
 
 out subsequent statements, in three files: rows.c, text.c, and
 
 wind.c, and now it works as desired.

Not quite; but I should try to come up with something more robust
before addressing this in further messages.

Mark.

Re: [9fans] documentation suggestion

[Mark van Atten]

The only further thing needed is to replace in the function texttype, at 
text.c:665,

if(t-what!=Body  t-what!=Tag  r=='\n') 

by

if(t-what!=Body  r=='\n')

Sorry for the noise.

Mark.

Re: [9fans] documentation suggestion

[Mark van Atten]

Would it be possible to add an option to p9p acme so that its tags
will always remain one line, i.e., show Plan 9's acme behaviour?

Mark.

Re: [9fans] Acme Edit scriptlets

[Mark van Atten]

On Friday, 29 March 2013 01:38:06 UTC+1, Bence Fábián  wrote:

 I did a quick writeup on little Edit scripts

Many thanks, this thread is very useful.

There is also Jason Catena's list of Edit idioms at
https://raw.github.com/catenate/acme-fonts/master/test/1/acme/Edit/sam

When editing and re-editing latex, I regularly pipe selections
through a simple-minded script called `chunk' which does most of
the work for obtaining semantic linebreaks. That goes back to a
recommendation by Kernighan in his paper `Unix for beginners' of
1974; see the quotation, comments and link at [1].



#!/usr/local/plan9/bin/rc 
# chunk up (to prepare) for semantic linebreaks

# do  not break within \cite 
# do not break within $$ math 
# break after closing parentheses ),] 
# break before an opening parentheses (,[

ssam -e 'x/(^[^%].+\n)+/  y/\\cite[^{]*{(\n|.)*}/ y/\$.*\$/
x/(([^A-Z]\.)|[,;:!?]|\)|\]) | (\(|\[)/ s/ /\n/' \ | 9 fmt -w 60
-j


For batch processing probably something more sophisticated would
be needed to leave various environments unchunked. But I don't use
it that way, and just apply it to selections where I know its use
makes sense. Usually these are areas where I have just been doing
a lot of rewriting.

There's no point in chunking up commented material, and sometimes
it is actually convenient to have a place where I can keep things
unchunked for reference.

The original chunk command in Writer's Workbench [2], for troff not
latex, was  based on a parser for English, I think. I find I don't
want that (because I write in other languages as well), and that
even in English I don't need it (because the chunking based on
interpunction is always fine with me, and where I care about the
remaining cases, I prefer to do it myself; but see [3]).

Mark.


[1] http://rhodesmill.org/brandon/2012/one-sentence-per-line/

[2] http://man.cat-v.org/unix_WWB/1/chunk

[3] https://github.com/waldir/semantic-linebreaker

Re: [9fans] documentation suggestion

[Mark van Atten]

If I click 'New' to open a window in a column, go into its tag, and
start typing after `Look', the tag becomes multiline and wraps my
text when I hit the border.

Mark.

Re: [9fans] com: comments toggle in acme

[Mark van Atten]

Thanks, indeed!

I added two lines so it can be used with Latex files too:

case *.tex
c='%'

Mark.

Re: [9fans] multiple acme instances with plan9port

[Mark van Atten]

Two years or so ago I found the script below, allowing you to start any number 
of instances of acme. E.g. if you name the script acme9 you use
acme9 -n 1, acme9 -n 2, etc., each of which can followed by the usual arguments 
you wish to pass on to acme.

Thanks to whomever wrote this.

Mark.


#!/bin/sh

[ $1 = -n ]  { export NAMESPACE=/tmp/ns.$USER.$2; mkdir -p $NAMESPACE; 
shift; shift;
}
9p ls plumb/ /dev/null 2/dev/null || (cd /; 9 plumber)


exec acme  $@

[9fans] page(1) problem

[Mark van Atten]

I run p9p on FreeBSD 9.0-RELEASE. Page(1) works fine on PDF, but not
on PS files. When opening the latter, it first produces a very long
list of errors like this:

Ghostscript Error:
Error: /undefined in
D9D66F633B846A97B686A97E45A3D0AA0525392EECAC163E584A9104D99AD0BC1B1844A0E222
Operand stack:
   false   --dict:8/17(L)--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --
nostringval--   2   %stopped_push   --nostringval--   --
nostringval--   %loop_continue   --nostringval--   --nostringval--
false   1   %stopped_push   .runexec2   --nostringval--   --
nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1170/1684(ro)(G)--   --dict:0/20(G)--   --dict:80/200(L)--
Current allocation mode is local
Last OS error: 2
Current file position is 77

and then goes on to shows the ps output all the same, but without
certain ligatures, so that, eg, 'affinities' shows up as 'a nities'.

However, if I run gs directly on the same file (without parameters),
or use ps2pdf to convert that ps file to pdf and then run page on it,
there is no problem at all.

Any thoughts on what might cause this?

The version of gs used is 8.71, and p9p is up to date with the hg
tree.

Best wishes,
Mark.

[9fans] kertex on Plan 9

[Mark van Atten]

Could anyone who actually got (not tex, but) latex running using
kertex on Plan 9 show the full details? What I have found on the web
so far has not been enough for this novice.

Plain tex works wonderfully. Thanks, Thierry Laronde!

Mark.

Re: [9fans] kertex on Plan 9

[Mark van Atten]

My previous message appeared on the list with a delay; in the
meantime, in an off-list exchange, Thierry kindly worked on it
immediately and resolved all the problems. The version that now
appears on the Kertex web page works for me. I use 9vx on FreeBSD 8.2.

I also compiled Kertex successfully on FreeBSD 8.2 itself, but I had
to use clang instead of gcc; the latter had kept complaining about an
unexpected dependency on libgcc_s.so.1

Best wishes,
Mark.