oglesby@UUNET.UU.NET (Jose Oglesby) (10/08/88)
I have noticed than when editing large files buffer positioning commands do not always have the desired effect. For example going to the end of the buffer ( via M-> ) leaves you right back at the start of the buffer. Presumably this behavior is caused by the 24 bits of data / 8 bits of tag used in elisp. Can anything be done about this problem? Did I miss a relevant option in the build procedure? Thanks in advance for any hints/suggestions/explanations. Jose Oglesby oglesby@multiflow.com
meissner@xyzzy.UUCP (Usenet Administration) (10/17/88)
In article <8810080651.AA28467@uunet.UU.NET> mfci!oglesby@UUNET.UU.NET (Jose Oglesby) writes: | I have noticed than when editing large files buffer positioning commands | do not always have the desired effect. For example going to the end of | the buffer ( via M-> ) leaves you right back at the start of the buffer. | Presumably this behavior is caused by the 24 bits of data / 8 bits of | tag used in elisp. Can anything be done about this problem? Did I | miss a relevant option in the build procedure? Thanks in advance | for any hints/suggestions/explanations. One thing that leaps to mind, is to NOT define "NO_UNION_TYPE", and monkey with the Lisp_Object union in lisp.h to declare the val field as a full 32-bits. When I started porting emacs as a "hobby" project (18.48 I think), I tried this at one point, and was distressed that it would no longer build. There are a few places (mostly in garbage collection, but elsewhere as well) that assume a Lisp_Object is an integer, and that you can set both type and data in one opteration. If you make this change, you may find that emacs is slower, since some compilers use slower calling sequences for passing or returning integers. Also, the C compiler I used at the time (NOT pcc or gcc based) could not handle initializations of the form (since fixed): func () { Lisp_Object var = Qnil; } -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net