I have some Lisp files created on a symbolics, which I'd like to be
able to use on a Unix machine. They have (at least) font information,
and slightly strange newline conventions, and I suspect there are
other odd (by unix standards) chars in there too. Does anyone either
have a tool to strip & convert these, or any details on what the
conventions are? The tool could run on the symbolics if need be.
Thanks
--tim
In article <·················@scarp.ed.ac.uk> ···@ed.ac.uk (Tim Bradshaw) writes:
> I have some Lisp files created on a symbolics, which I'd like to be
> able to use on a Unix machine. They have (at least) font information,
> and slightly strange newline conventions, and I suspect there are
> other odd (by unix standards) chars in there too. Does anyone either
> have a tool to strip & convert these, or any details on what the
> conventions are? The tool could run on the symbolics if need be.
>
> Thanks
>
> --tim
I don't know about the newline conventions; I thought they used the same
conventions as Unix. Maybe the lines are just really long?
My experience is mostly with Explorers, but they also keep font
information in the files, and I've got several tools for stripping them
out. Perhaps this will work for you. First, the syntax is that the whole
file is in font 0 (the first font listed in the fonts attribute at the top
of the file), unless otherwise specified. A different font is specified
by the sequence ^F# (control-F followed by a number) and turned off by ^F*
(control-F followed by an asterisk). Therefore, the way to get rid of all
the font information is to go through the file and remove every ^F
character and the character that follows it.
I use the following Emacs-lisp code to remove fonts. There may be better
ways, but this works fine for me:
;;; For removing Explorer fontification of lisp files. The Explorer turns on
;;; the nth font by doing ^Fn, and turns a font off by doing ^F*. The base font
;;; is zero, I guess.
(defun cleanup-explorer-fonts ()
"Remove Explorer fontification of files."
(interactive)
(save-excursion
(beginning-of-buffer)
(while (re-search-forward "." nil t) ; that's a literal ^F
(replace-match "" nil nil))))
I hope this helps.
Scott D. Anderson
········@cs.umass.edu
PS: If you prefer to work on the Symbolics, a M-X command like "Set
Fonts" and giving a null font list should do the trick. At least, it
works on my Explorer.
········@earhart.cs.umass.edu (Scott D. Anderson) writes:
>My experience is mostly with Explorers,
> A different font is specified
>by the sequence ^F# (control-F followed by a number) and turned off by ^F*
>(control-F followed by an asterisk). Therefore, the way to get rid of all
>the font information is to go through the file and remove every ^F
>character and the character that follows it.
The format on the Symbolics machine differed, since the encoded
information was character styles, not fonts (Long, long, time ago,
before rel-6, the formats were the same). There's also a "password"
used to enable font information, so a random character sequence didn't
trigger the font mechanism. The format of the character styles and
passwords should be obvious from inspection, and I'm sure you can
clean that up with no problem.
What isn't obvious, is the extended character set: >= <= <NewPage>
etc. If you have access to a LispM and the file is small enough you
can convert them manually. I've forgotten the encodings of those
characters, and don't have access to a manual or a Lisp Machine. But
what you should do is collect the non-ascii codes in the entire file,
and build up a table of the translations (for example, by running
CODE-CHAR on the Symbolics machine of your choice). Then you can do
the conversion in your editor on the Unix box.
Sorry I can't be of more help.
Michael Greenwald
In article <·················@scarp.ed.ac.uk>, ···@ed.ac.uk (Tim Bradshaw)
wrote:
> I have some Lisp files created on a symbolics, which I'd like to be
> able to use on a Unix machine. They have (at least) font information,
> and slightly strange newline conventions, and I suspect there are
> other odd (by unix standards) chars in there too. Does anyone either
> have a tool to strip & convert these, or any details on what the
> conventions are? The tool could run on the symbolics if need be.
I'm not sure what newline problems you're seeing (I'd swear Genera uses
LFD, char-code 10, just like Unix -- at least I've never had problems with
EOL), but I might be able to help with the font info and the special
characters.
If you have access to GNU Emacs on your Unix box, I have some workable (if
shoddily-written) Elisp code which takes a buffer with Genera font
information and special characters and converts it to one of several
possible formats:
- straight ASCII text (fonts stripped out wholesale)
- marked-up TeX source (the mapping from Zmacs character styles to
commands is hardwired but easy to fix)
- text with Emacs 19 text-face properties (bold, bold-italic, etc.).
This latter is only useful so long as you're visiting the file, there
being no way to save these properties back to the file, but it's the
truest view of the original Zmacs buffer. Again, mappings are crude but
straightforward.
All of these also try and map the 30-odd special characters in the Genera
character encoding to a plausible ASCII representation (possibly a
multigraph, e.g. the "right arrow" character might be changed to "->")
I've also provided a find-file hook that allows you to perform
translations like these automatically whenever you visit such a file.
If you don't have GNU, I can probably also rustle up our "Thin File"
utility that runs on the LispM's.
pete
In article <·················@scarp.ed.ac.uk> ···@ed.ac.uk (Tim Bradshaw) writes:
>I have some Lisp files created on a symbolics, which I'd like to be
>able to use on a Unix machine. They have (at least) font information,
>and slightly strange newline conventions, and I suspect there are
>other odd (by unix standards) chars in there too.
Except for the fonts, I think you will be fine. We used to frequently
use the identical files on Symbolics and Sun/Lucid, taken off a
partition that was NFS-mounted on both machines.
Regarding the fonts, there is a Symbolics function called either
THIN-STRING or STRING-THIN that strips fonts out of a string. I recall
we used to convert files by reading lines in with READ-LINE, running
THIN-STRING, and then writing them back with WRITE-LINE.
Now that I have font-lock-mode on XEmacs, I don't even miss the
Symbolics fontification any more.
- Marty
(proclaim '(inline skates))
From: Dave Dyer
Subject: Re: Stripping / converting files made on a symbolics?
Date:
Message-ID: <ddyerDDBAGo.LqK@netcom.com>
If you're fortunate enough to still edit on symbolics machines some of
the time, here's a code snippet that sets up the readtable to ignore
symbolics font information. With this hack, you don't need to remove
the fonts to compile under harlequin/lucid/franz lisp.
A couple caveats; this doesn't work correctly if partial words are fontified,
and the font information still makes editing on unix platforms look bad. It
does, however, provide a bridge to delay the inevitable.
(defconstant ESCAPE-QUOTE (code-char 6))
(defvar BAD-ESCAPE-ACTION :error)
(defun SKIP-ESCAPE-SEQUENCE (stream)
;;(format t "~&@~D" (file:read-stream-pointer stream))
(let* ((next-char (read-char stream)))
(or (when (or (eql next-char escape-quote)
(eql next-char #\return))
next-char)
(block process-real-escape-sequence
(cond ((eql next-char #\( )
(unread-char next-char stream)
(read stream))
((eql next-char #\* )
nil)
((eql next-char #\ )
(let ((c nil))
(loop (setq c (read-char stream)) (when (eql c #\] ) (return)))))
((char-lessp next-char #\0)
(case bad-escape-action
(:error (error "Junk (~S) in escape sequence" next-char))
(:notify (format t "~&Junk (~S) in escape sequence...losing it."
next-char))))))
nil))
)
(defun MAKE-EPSILON-IGNORING-READTABLE (&key
(template-readtable *readtable*)
(new-readtable (copy-readtable template-readtable)))
(set-macro-character escape-quote
#'(lambda (stream macro-character)
(declare (ignore macro-character))
(skip-escape-sequence stream)
(values))
nil ;was T. NIL is the right thing [ddyer]
new-readtable)
new-readtable)
(defmacro %RT (&optional (readtable 'cl:*readtable*))
`(make-epsilon-ignoring-readtable :new-readtable ,readtable))
(eval-when (load eval)
#-symbolics (%rt)
#+lucid (progn
(proclaim '(special lucid::*standard-readtable*))
(%rt lucid::*standard-readtable*))
)
--
---
My home page: ftp://ftp.netcom.com/pub/dd/ddyer/home.html
or try http://www.triple-i.com/~ddyer/home.html
From: Bruce R. Miller
Subject: Re: Stripping / converting files made on a symbolics?
Date:
Message-ID: <3017417075@ARTEMIS.cam.nist.gov>
In article <·················@scarp.ed.ac.uk>, Tim Bradshaw writes:
> I have some Lisp files created on a symbolics, which I'd like to be
> able to use on a Unix machine. They have (at least) font information,
> and slightly strange newline conventions, and I suspect there are
> other odd (by unix standards) chars in there too. Does anyone either
> have a tool to strip & convert these, or any details on what the
> conventions are? The tool could run on the symbolics if need be.
I've seen font-stripping & cleanup tools around, but for most purposes,
I've found the following approach sufficient:
In zmacs, simply set the font for the file to the default font (font #0)
[eg. meta-shift-<, control-space, meta-shift->, to mark the whole buffer
& c-X, c-J to set the font style: generally, <return> will give the
default font]
In some cases, you might need to remove font info from the attribute
line, first. (just edit the text, then m-X reparse attribute)
Then c-X,c-W to write the file to a unix host -- assuming you've got nfs
running, genera will write the appropriate newlines, etc.
No?
······@FS1.cam.nist.gov (Bruce R. Miller) writes:
...
>In some cases, you might need to remove font info from the attribute
>line, first. (just edit the text, then m-X reparse attribute)
...
>Then c-X,c-W to write the file to a unix host -- assuming you've got nfs
>running, genera will write the appropriate newlines, etc.
>No?
Unless I'm misremembering, the fonts are >not< the problem. They're
trivial to clean up. The issue, as I said yesterday, are the
non-standard characters i.e. >= etc. What the original poster needs
to do is to collect all the non-standard characters in his file,
lookup their translation on the LISPM, and replace them with their
(sometimes multi-character) equivalents.
Michael Greenwald
·········@cs.stanford.edu