sam-fans - fans of the sam editor
 help / color / mirror / Atom feed
From: "Mark H. Wilkinson" <mhw@kremvax.demon.co.uk>
To: Scott Schwartz <schwartz@bio.cse.psu.edu>
Cc: Sam Fans <sam-fans@hawkwind.utcs.toronto.edu>,
	Bengt Kleberg <bengt@softwell.se>
Subject: Re: 9libs, new sam release, experimental wily release
Date: Mon, 14 Jun 1999 15:46:50 -0400	[thread overview]
Message-ID: <199906142046.20514.9libs.badum@kremvax.demon.co.uk> (raw)
In-Reply-To: <19990614064432.24527.qmail@g.bio.cse.psu.edu>

> "Mark H. Wilkinson" <mhw@kremvax.demon.co.uk> writes:
> | 9libs-1.0, sam-9libs, wily-9libs

> Thanks.  I have a couple of complaints, though.  Several of my
> favorite bugs (patches posted ages ago) have been resurrected
> in this new release.

It looks like your patches hadn't made it into the Bell Labs source,
although I do remember some of them being posted to sam-fans. If you
forward them to Bengt and myself we'll get them integrated.

> They are:
>   * In samterm, MAXFILES is too small.  (I've been using 4K.)

Sounds reasonable. The "sam" program uses a variable length list to
hold open files whilst the "samterm" program uses a fixed size array.
A better solution might be to replace the fixed size array with a variable
sized list, but upping the limit looks fine for the time being.

>   * In sam, private temp files are world readable/writable.

Yup, I remember this one too. Again, sounds Ok to me.

>   * In libXg, "fontfile" is specified by the X client app.  In general
>     that cannot work: unlike in Plan 9, the X terminal usually won't
>     share any filesystem with the machine on which the X app is
>     running, so *no* filename can be valid for "-p9font".  The fix is
>     to store the unicode font map in an X property which is set by your
>     xinitrc.

By this, do you mean the case where you're logging into remote machines
and running sam & samterm on the remote machine? You can always get round
the problem by making sure the font file you want to use is available
on each of the machines you connect to, but I guess you're after a
solution which is easier to manage, using the X server as shared storage.
That sounds reasonable, but I'd like to retain the existing mechanism
too: it works well in networks where the file system is common to all
machines to some degree.  It also has utility in wily where the Font
builtin can be used to switch between font files dynamically.

> I'll dig the diffs out of my RCS files tomorrow and sent them along.

That would be great!

Cheers,

-Mark.


  reply	other threads:[~1999-06-15 21:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-10 23:04 Mark H. Wilkinson
1999-06-14  6:44 ` Scott Schwartz
1999-06-14 19:46   ` Mark H. Wilkinson [this message]
1999-06-15  0:10     ` Scott Schwartz
1999-06-15  0:39     ` Scott Schwartz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199906142046.20514.9libs.badum@kremvax.demon.co.uk \
    --to=mhw@kremvax.demon.co.uk \
    --cc=bengt@softwell.se \
    --cc=sam-fans@hawkwind.utcs.toronto.edu \
    --cc=schwartz@bio.cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).