May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [Discuss] Plea for feedback on XEmacs-FAQ 26 years, 6 months

Christian Nybø

Marc Paquette <marcpa(a)cam.org> writes: > XEmacs FAQ Maintainer wrote: > > > > > > > If you've got ideas on what to improve, answers you'd like added, > > views on presentation or other aspects of the FAQ, I'd like to hear > > from you. > > About "Q1.0.10: Is there a port of XEmacs to Microsoft ('95 or NT)? " : > it needs to be put more up-to-date. A first step would be to put a link > to the XEmacs-on-windows FAQ. The latter should probably move to a more > official location, i.e. on xemacs.org, since it is now at > > <URL:http://jagor.srce.hr/~hniksic/xemacs-on-windows-faq.txt> Yup, I got started converting it earlier today, and it should be merged with the rest of the FAQ by Saturday. I'll add a separate chapter for Xemacs on MS windows. later, -- chr

1 participants
0 comments

[Discuss] Plea for feedback on XEmacs-FAQ 26 years, 6 months

XEmacs FAQ Maintainer

Are you frustrated because your Linux kernel compiles too fast -- feeling lonely with your disgruntledness as you're not on jwz's `real-bad-attitude' mailing list -- bored of C++ flaming in comp.lang.lisp -- or simply tired of answering the same questions over and over in your favorite newsgroup? Read on -- opportunities ahead... For about six weeks now, I've had the task of maintaining the XEmacs FAQ. I've just made the second monthly posting of it to comp.emacs.xemacs. A preview of a new web version has been uploaded to the directory <URL:http://www.xemacs.org/faq/pre/>. I have attempted to reduce the versioning problem, as the web and texi versions were maintained in parallel before. Now the web-pages, the TeX and ASCII versions are all generated from the .texi file. (with a Neanderthal makefile, of course ) The newsgroup postings aren't all that automatic yet, but that'll improve. If you've got ideas on what to improve, answers you'd like added, views on presentation or other aspects of the FAQ, I'd like to hear from you. -- thanks in advance, Christian Nybo Xemacs FAQ maintainer

2 participants
1 comments

[bug] Unnarowing 26 years, 6 months

Hrvoje Niksic

Take a buffer portion, mark it and narrow it with `C-x n n'. It is important that the beginning of the narrowed portion is *not* at the beginning of a line. Now, press `C-x n w' to remove the narrowing. For me, the beginning of the narrowed region still appears to be at the beginning of line. Only after actually going to that part of the buffer and pressing C-p or C-b does the beginning of the formerly narrowed region shift to where it belongs to. This has been there for quite some time (at least since 20.2, probably since 19.12 or longer), and is likely the result of `widen' not getting the attention of the relevant redisplay structures. FSFmacs does not exhibit this behaviour. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Your lucky number today is 29842924728. Look for it everywhere.

2 participants
1 comments

Re: Two possible bugs. 26 years, 6 months

Hrvoje Niksic

"J.L.P. Lopez de Victoria" <espuela(a)prtc.net> writes: > Writing accented characters (upper ascii) with the x-compose > package involves sequences such as 'a to obtain á, etc. So far, so > good, but when commands such as `downcase-word' or `upcase-word' are > used, this takes place: > > Downcase-word: ŤMAŃANAť becomes ŤmaŃanať instead of Ťmańanať > > In like fashion: > > Upcase-word: Ťmańanať becomes ŤMAńANAť instead of ŤMAŃANAť [...] Try putting (require 'iso-8859-1) to your `.emacs'. I believe this should install the correct case-table for iso-8859-1. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Ooh, Granny, what a BIG belly-button you have!

1 participants
0 comments

Two possible bugs. 26 years, 6 months

J.L.P. Lopez de Victoria

Hello everyone, My first potential contributions since joining the mailing list follow a short introduction. My original exposure to emacs as a user took place in 1980 with the Gosling variant of the original beast. In those heady years (some would say hairy), the net was the size of a nut in the minds and winds (not like air, like twist) of a few. I migrated to xemacs about the time of 19.12 and currently run Emerald in its xemacs-20.4-1.i386.rpm incarnation. Most of my work involves editing and typesetting books and other long documents (via groff and lout) in English and Spanish. Writing accented characters (upper ascii) with the x-compose package involves sequences such as 'a to obtain á, etc. So far, so good, but when commands such as `downcase-word' or `upcase-word' are used, this takes place: Downcase-word: «MAÑANA» becomes «maÑana» instead of «mañana» In like fashion: Upcase-word: «mañana» becomes «MAñANA» instead of «MAÑANA» This involves all accented vowels and consonants. I know next to nothing about lisp coding, but would venture that it may not be too hard to fix . . . (FSF emacs performs the correct 8-bit replacements since 19.20). Another bug probably involves the masking of commands such as ^X^S (write-file). If you key in a typesetting command for groff such as `move vertically ½ line' ( \v'.5' ) followed immediately by ^X^S, you'll get: \v'.5'x -- in addition to write-file execution The second apostrophe keystroke is interpreted as the `deadkey accent' character of the two-character upper ascii generating sequence, while the ^X portion of ^X^S becomes a literal lower case `x' in the text. Oddly, (at least to this layman) the write-file command is executed properly in spite of its putative involvement with the final (previous) apostrophe. This behavior takes place with any deadkey that would normally raise the eighth bit when followed by any vowel (upper or lower case) or suitable Latin-1 consonant such as ` ÿ '. One can avoid the problem by remembering to strike the spacebar before typing ^X^S, but this is less than convenient as it requires an additional `protective' keystroke that is easily forgotten when needed and becomes a nuisance space character when not. Obviously, the spacebar keystroke is necessary to write a real apostrophe prior to an `unrelated' vowel, etc., but I should hope that a way can be found to mask control character sequences such as ^X^S to preserve their exclusive functionality regardless of what may have been written immediately before. Though in small measure, I believe these changes would usefully improve the remarkable xemacs working environment. THREE LOUD CHEERS FOR ALL WHO MAKE IT WORK! I don't know how you do it, but I sure appreciate the results . . . Hey, Bill Gates, get a life . . . elsewhere!

1 participants
0 comments

XEmacs 21.0 DND (daily patch) 26 years, 6 months

Oliver Graf

Hi there! Sorry, no patch today, because Kyle said my patches are too massive for 21.0... ;-) Just joking ;-) To much work today. I've written a basic skeleton for the lispref which is not so intresting for testing... Tomorrow I have time to test the CDE stuff on my own (perhaps I can also improve the code a bit). Regards, Oliver.

1 participants
0 comments

re: makeinfo 1.6.8? 26 years, 6 months

Nobu Toge

I wrote - > Anyway, my makeinfo is v.1.67 that came with GNU Texinfo 3.9, and after > some searching around I don't see any newer versions of Texinfo in > ftp.gnu.org, etc. Where do I find makeinfo 1.68? My blunder, I found texinfo-3.12 there. Sorry for wasting the bandwidth. -- Nobu Toge toge(a)accad.kek.jp toge(a)kekvax.kek.jp

1 participants
0 comments

Re: makeinfo 1.6.8? 26 years, 6 months

SL Baur

Charles G Waldman <cgw(a)pgt.com> writes: > Nobu Toge writes: >> >> Anyway, my makeinfo is v.1.67 that came with GNU Texinfo 3.9, and after >> some searching around I don't see any newer versions of Texinfo in >> ftp.gnu.org, etc. Where do I find makeinfo 1.68? There was a new bug apparently introduced in makeinfo-1.67 that causes a coredump when processing the XEmacs internals manual. "Apparently introduced" because some earlier versions work. This bug is fixed in makeinfo-1.68 and later. > It comes with texinfo 3.12, which you can find at 3.11 actually, but 3.12 should be O.K. too. > ftp://ftp.gnu.org/pub/gnu/texinfo-3.12.tar.gz > or any of the Gnu mirror sites.

1 participants
0 comments

Re: [FAILURE] XEmacs 21.0-beta38 on MkLinux 26 years, 6 months

Hrvoje Niksic

"Stephen R. Anderson" <sra(a)bloch.ling.yale.edu> writes: > hniksic(a)srce.hr said: > > Step 1: Edit config.h and undefine HAVE_MATHERR. See if you get a > > clean compile. > > OK. Did that. Everything compiled without problem. [...] I think I see what is going on: 1) XEmacs configure process simply checks for `matherr' function, without actually verifying that it accepts `struct exception'. In my opinion, this is OK. 2) Under C++, `struct exception' cannot work, so XEmacs does not use HAVE_MATHERR at all. This is, again, OK. 3) One glibc snapshot contains math.h which has `struct exception' unconditionally removed. This is *not* OK. The right solution is to keep XEmacs sources the way they are, and let glibc people fix their header. If I understand correctly, this has already been done. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- You have an unusual magnetic personality. Don't walk too close to metal objects which are not fastened down.

2 participants
1 comments

Re: [bug] buffer-syntactic-context hosed by `(' at beginning of line 26 years, 6 months

Jan Vroonhof

[Latest news after some playing around with it again] Couldn't the problem be that we don't invalidate the cache when changing major modes and that somehow now we setup the cache before switching to c-mode, Try C-x b newbuffername1 /* ab (cd) ef */ Cursort to 'e' M-: (buffer-s-context) => nil M-x c-mode M-: (buffer-s-context) => nil (Invalidate the cache by doing something else (like calling b-s-c in another c buffer) M-: (buffer-s-context) => 'block-comment M-x fundamental-mode M-: (buffer-s-context) => 'block-comment !!!! [old news:] Hrvoje Niksic <hniksic(a)srce.hr> writes: > This is because the cache gets updated right. But it still creates > hard-to-track problems in many situations. For instance, I see it > with font-lock-mode, and it makes modifying the line after `(' hosed. Are you sure it is the cache? If it is the cache it is probably this 1998-03-29 Martin Buchholz <martin(a)xemacs.org> * font-lock.c (find_context): Use context_none with context instead of ccontext_none. RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/font-lock.c,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- font-lock.c 1997/09/03 03:39:36 1.2 +++ font-lock.c 1998/03/31 20:11:42 1.3 ＠＠ -432,7 +432,7 ＠＠ if (context_cache.needs_its_head_reexamined) { if (context_cache.depth == 0 - && context_cache.context == ccontext_none) + && context_cache.context == context_none) { /* We've found an anchor spot. The weird thing is, if it is this, why does it matter? Assuming enums are assigned from 0 the difference is only syntactic.

2 participants
1 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta May 1998