scott@cs.heriot-watt.ac.uk (Scott Telford) (03/01/91)
Unless you've been reading the USENET newsgroups comp.os.minix or alt.sources, you may not be aware that a new, enhanced version of the Origami folding text editor has been released. This version (1.5) was modified by Michael Haardt and Wolfgang Stumvoll of the RWTH (no, I don't know what it stands for) in Aachen, Germany, from the C/Unix port of v1.31 that was recently put on the INMOS US archive-server. They have basically turned Origami into an Emacs-lookalike editor, with a screen display very like MicroEMACS, and a new (compiled) keybinding/macro language (OCL) similar to GNU Emacs' Emacs Lisp. Some bugs have been fixed, and a few other changes made, such as dBase mode being replaced by roff mode, and fewer termcap capabilites are needed. Some extra Emacs functions have been implemented (eg. goto-matching-fence, fill-paragraph) using OCL - there is even a Towers of Hanoi macro supplied! Two keybinding files are provided with the source: one emulating GNU Emacs, the other emulating Parsytec's MultiTool (it says here). It seems to have been developed on a Minix system but it also compiles under SunOS. A User Guide and man page are also supplied with the source. A few thing still need to be fixed: TAB still does nothing (easily fixed) and filed folds still need to be in the current directory for Origami to find them, but it's a big improvement over 1.31, and probably the most painless way yet to edit TDS-format files for an Emacs-addict. The source files originally posted in comp.os.minix are now available by e-mail archive-server or anonymous FTP at plains.nodak.edu in directory pub/Minix/all.contrib/Origami. The author's e-mail address is u31b3hs@cip-s01.informatik.rwth-aachen.de (whew!). -- ---------------------------------------------------------------------------- | Scott Telford Janet: scott@uk.ac.hw.cs / scott@cs.hw.ac.uk | | Internet: scott%cs.hw.ac.uk@nsfnet-relay.ac.uk | | Dept of Computer Science uucp: scott%hwcs@ukc.uucp | | Heriot-Watt University | | 79 Grassmarket "This time it was right, it would work, and | | Edinburgh EH1 2HJ no-one would have to get nailed to anything." | | United Kingdom - Intro to The Hitch-Hiker's Guide to the Galaxy | ----------------------------------------------------------------------------
pth@transt.UUCP (Paul Hudson, Systems Software Manager) (03/01/91)
Sorry for bothering you ... can I get Origami sources from you, or
could you give me a few more details of the email server (like where
to send the requests, and the syntax of such requests)?
Thanks.
Paul.
_/ Paul Hudson - Systems Software Manager EMAIL: pth@transtech.co.uk,
_/_/ Transtech Devices Ltd, ..!ukc!transt!pth
_/_/_/ Unit 17, Manor Court Yard, VOICE: +44 494 464303
_/_/ Hughenden Avenue, High Wycombe, FAX: +44 494 463686
_/ Bucks. HP13 6RE TELEX: 838844u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt) (03/15/91)
Hello, in "RE origami ...." Phillip M. Hallam-Baker writes: > This only obliquely concerns parallelism but all this hassle >because people did not cast their mallocs properly reminds me of >an article in parallelogram where a company was crowing over it's 64 >bit database they had written for CRAY. They claimed that a lot of >their competition could not do so because their programmers had >used integers to hold pointers which is a limited value trick once your >pointers get too big... just goes to show that moaning type checkers >can be a real advantage! I read the discussion about porting Origami to different machines in this newsgroup, but I was too busy to posting an article last time. At first, I want to say something to the above article: malloc needs no cast. The correct definition is: "void *malloc(n) size_t n;" A pointer to void is compatible to any other pointer. Not all compilers handle this correct, but a pointer to malloc can always be assigned to any other pointer. If you use a broken compiler, you will get a warning which can and should be ignored. The "extern void *malloc();" (k&r!) definition is in <stdlib.h>, if your header files follow POSIX. If it is defined as "extern char *malloc()", the manufacturer shows, that he believes in old k&r. Anyway, the resulting pointer is aligned for use for any data type. A cast could me made to avoid warnings, but it does not influence the function. If you use SunOs 4.0.x, your include files and libraries are not up to date. Do not waste any time with porting it, Origami runs ok with 4.1. If you want to use it on 4.0, compile a version on 4.1 and use static linking. The resulting binary runs on 4.0. (We tried it a week ago on our systems). I assume (or hope), that those people who have problems with their keybaords use the right keybindings. Meta-z will be only defined in Emacs-mode. If your return-key does not work, try linefeed. I had the same problem with MINIX. We solved it by binding both return and linefeed to the function newline-and-indent. I can't imagine, why half of the keys are not working while using Origami. We never had any problems on SunOs 4.1 and PC MINIX 1.5.10. It must be a local problem, either with the header files or with the libraries. The code is not very clean. Some people bemoaned this and it is true. Origami compiles and works, but changes are difficult. A big clean-up is made at the moment which results in a modular, well-structured and commented code for the next version. The current version should be used for using, not for extending this editor. A lot of new features will be available too, but this new version 1.6 is neither finished or well-tested. The current version 1.5 should be stable for using it. There will be no support for old systems in Origami. We made this decision to encourage using POSIX. I really hate the divergencies between Unices, and POSIX tries to prevent this. Most manufacturers accept this in their newest releases. A program should not contain 50 percent #ifdef MY_SYSTEM, #ifdef YOUR_SYSTEM. Namaskaar Michael Haardt (u31b3hs%cip-s01.informatik.rwth-aachen.de@unido.bitnet)
scott@cs.hw.ac.uk (Scott Telford) (03/16/91)
In article <4148@rwthinf.UUCP> u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt) writes: > >If you use SunOs 4.0.x, your include files and libraries are not up >to date. Do not waste any time with porting it, Origami runs ok >with 4.1. If you want to use it on 4.0, compile a version on 4.1 >and use static linking. The resulting binary runs on 4.0. (We >tried it a week ago on our systems). > ... >A big clean-up is made at the moment which results in a modular, >well-structured and commented code for the next version. The >current version should be used for using, not for extending this >editor. A lot of new features will be available too, but this new >version 1.6 is neither finished or well-tested. The current >version 1.5 should be stable for using it. > Can you give us an approximate release date for 1.6? >There will be no support for old systems in Origami. We made this >decision to encourage using POSIX. I really hate the divergencies >between Unices, and POSIX tries to prevent this. Most manufacturers >accept this in their newest releases. A program should not contain >50 percent #ifdef MY_SYSTEM, #ifdef YOUR_SYSTEM. I can understand the attraction of sticking uncompromisingly to a standard and ignoring all else, but I think a more pragmatic attitude would be useful. There must be a still be a lot of SunOS 4.0 boxes out there (there are quite a few here!) and simply writing them off as "not up to date" is not much consolation for the people that use them. I bet GNU Emacs (or MicroEMACS, for that matter) wouldn't have got where it is today if it had been compatible with only strictly Posix-compliant systems :-) BTW, Andy Rabagliati has updated the Origami source files on the INMOS US archive-server to v1.5. _____________________________________________________________________________ | Scott Telford, Dept of Computer Science, scott@cs.hw.ac.uk | | Heriot-Watt University, Edinburgh, UK. scott%hwcs@ukc.uucp | |_____ "Expect the unexpected." (The Hitch-Hiker's Guide to the Galaxy) ______|