November 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Falk Hueffner

Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de> writes: > the c++ font-locking does not know the C++ keywords "explicit", > "export" and "mutable". > > Appended patch against src/font-lock.el from xemacs-21.2-b37 > introduces them. While we're at it, there are also the keywords "namespace", "using", "dynamic_cast", "static_cast", "reinterpret_cast" and "typeid", and the type-types "typename" and "wchar_t". And a bunch of stuff like "bitand", but nobody uses them. Falk

2 participants
1 comments

Missing keywords in C++ 24 years

Enrico Scholz

Hello, the c++ font-locking does not know the C++ keywords "explicit", "export" and "mutable". Appended patch against src/font-lock.el from xemacs-21.2-b37 introduces them. Enrico

1 participants
0 comments

Re: Make backward-word and backward-char as efficient as forward versions. 24 years

Olivier Galibert

On Wed, Nov 22, 2000 at 06:12:39PM +0900, Martin Buchholz wrote: > No actual bug fixes here, just efficiency, consistency and convenience. Just FYI[1] if you play with benchmarking this, backward and forward moves have completely different efficiency patterns. Forwards lookups the first byte in a 256-entry table and adds the result to the pointer while backwards decrements the pointers until a byte <= 0xa0 is found. So, well, they are hard to compare... OG. [1] Large Y.

1 participants
0 comments

Re: -no-autoloads broken in 21.2.35 --pdump 24 years

Gunnar Evermann

Olivier Galibert <galibert(a)pobox.com> writes: > On Wed, Nov 22, 2000 at 09:19:10AM +0000, Gunnar Evermann wrote: > > > Wouldn't it be easier to move the command line parsing for the relvant > > variable after the loading of the dump file? This would be more like > > the initialisation in a traditional dumped xemacs. > > You have to detect -nd before trying to load the dump file. So you'd > have to split the command parsing in two stages. Not nice. I know, but I think emacs.c is far from nice anyway, with functions hundreds of lines long and scattered with #ifdefs. Also I think the save&restore changes the semantics as changes to the variables made in the lisp executed before dumping are unconditionally tossed. (Not that changing things like inhibit-autoloads in lisp in load-up.el would be very useful.) Anyway, I don't have strong feelings about this. You guys decide. Gunnar

1 participants
0 comments

Re: Reduce core Lisp stats [WAS: That is not a flamewar] 24 years

Jan Vroonhof

[Moving the discussion to xemacs-beta] Hrvoje Niksic <hniksic(a)arsdigita.com> writes: > Thanks for working on this. To me it seems the real issue to attack > are the evil autoloads. > > Idea: the package build/installation process could concatenate all the > autoload files into one big auto-autoload for all the packages. > Startup routines would load that file, followed by the user's packages > in ~/.xemacs/ (there is usually a limited number of these.) > > Installing a new package would simply rebuild the master autoload > file. > > If the master autoload file is missing, we'd simply fall back to the > current scheme of looking for autoloads everywhere. In the past I proposed replacing [stat directory dir] [If dir is directory add to load-path] [stat dir/auto-autoload.elc] [open dir/auto-autoload.elc] [fstat dir/auto-autoload.elc] [stat dir/auto-autoloadl.el] by [open dir/auto-autoloads.elc] [If exists put dir in auto-autoloads] which should be much faster. It does need some kind of load-file-from-open-file-descriptor Jan

3 participants
2 comments

Re: -no-autoloads broken in 21.2.35 --pdump 24 years

Gunnar Evermann

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Works for me. Will apply shortly since Olivier approves. > > 2000-09-28 Stephen J. Turnbull <stephen(a)xemacs.org> > > * dumper.c (pdump_load_finish): move restoration of > `noninteractive1' to emacs.c (main_1). > * emacs.c (main_1): protect LISP-visible command-line flags > from pdump_load(). I think this patch is wrong. Sorry for not reviewing it earlier. AFAICT what happens with this patch at run-time (not build time) is: - a variable (say, inhibit_autoloads) is declared in emacs.c directly in C with 'int inhibit_autoloads;' no DEFVAR macros involved! note it doesn't get initialised to anything. - Command line options are parsed. inhibit_autoloads potentially gets set to 1. - Its value is saved in inhibit_autoloads_save - The pdump file is loaded, thus the normal DEFVAR_BOOL initialisation from vars_of_emacs() takes effect. - The saved value inhibit_autoloads_save is written back to inhibit_autoloads I think it is rather bad style to save&restore values we have never initialised to anything. In particular all this breaks for values which get set to 1 by default in vars_of_emacs(), like inhibit_site_[lisp|modules] (at least depending on configure time constants). > +/* WARNING! > + > + Some LISP-visible command-line options are set by XEmacs _before_ the > + data is dumped in building a --pdump XEmacs, but used _after_ it is > + restored in normal operation. Thus the restored values overwrite the > + values XEmacs is getting at run-time. Such variables must be saved > + before loading the dumpfile, and restored afterward. > + > + This is done immediately before and after pdump_load() in main_1(). > + See main_1() for the current list of protected variables. > + > + Note that if the variable is never DEFVAR'd, saving/restoring is not > + needed. I assume that this last sentence is meant to refer to INHIBIT_SITE_LISP and _MODULES? They are always DEFVAR'd. It is the *initialisation* to 1 that is conditional. > + int inhibit_early_packages_save = inhibit_early_packages; > + int inhibit_autoloads_save = inhibit_autoloads; > + int debug_paths_save = debug_paths; > +#ifdef INHIBIT_SITE_LISP > + int inhibit_site_lisp_save = inhibit_site_lisp; > +#endif > +#ifdef INHIBIT_SITE_MODULES > + int inhibit_site_modules_save = inhibit_site_modules; > +#endif from vars_of_emacs(). DEFVAR_BOOL ("inhibit-site-lisp", &inhibit_site_lisp /* Set to non-nil when the site-lisp should not be searched at startup. */ ); #ifdef INHIBIT_SITE_LISP inhibit_site_lisp = 1; #endif Finally I don't see a way to affect inhibit_site_lisp by command line options anyway, thus making the whole save&restore thing overkill. Maybe there should be a command line option? Michael? Gunnar

2 participants
1 comments

Re: Xemacs Mule + koi8 fonts question. 24 years

Nickolay Pakoulin

>>>>> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "Nick" == Nick V Pakoulin <npak(a)ispras.ru> writes: Nick> How to make XEmacs use koi8-r fonts instead of iso8859-5 fonts? It seems that I should be more prescise ;)) The observations are that XEmacs-MULE uses iso8859-5 fonts to display cyrillics. As I get it, XEmacs encodes buffer with cyrillic stuff into ISO8859-5 character set and then display it using iso8859-5 fonts. Right? If this reasoning is right, then let's name ISO8859-5 be "basic cyrillic encoding". Then the question is: is it possible to make KOI8-R to be "basic cyrillic encoding" in MULE XEmacs? Ok, now I see the problem -- KOI-8 does not have some characters that one can find in oher cyrillic languages (like Ukranian). May be it is possible to make KOI*-R to be another cyrillic charset, to be independent from iso8859? SJT> Build without Mule, use koi8-r file and process encodings, and set the SJT> font to koi8-r using X resources or command line arguments. Ok, but the question is for MULE XEmacs. Nick> And many people complain that they have to install 8859-5 fonts for Nick> XEmacs solely while all other apps do well with koi8. SJT> If you have an example of a multilingual app that works with koi8-r, I'd SJT> like to know about it. KDE2(qt-2.2.1) and KDE2 apps. XEmacs-MULE does understand koi8, but it needs iso8859-5 fonts to display it. This is inconvenient. SJT> Does GNU Emacs do it correctly? If so, it should be possible to port. SJT> Are there any tricks involved (eg, like using unibyte buffers)? Yes, GNU Emacs uses koi8-r fonts to display russian text. For more details need some hackung :)) Nick> Is there easy and straightforward way to use koi8-r fonts in Mule Nick> xemacs? SJT> Only if you are willing to limit yourself to 8859-5 portions of the KOI8 SJT> character set. The problem is that XEmacs basically assumes that KOI8 SJT> is a remapping of ISO Cyrillic, and translates other characters to a SJT> dummy replacement. In that case it should be possible to derive a font SJT> mapping CCL program from the code for KOI8 file encoding. SJT> Another possibility would be to create a KOI8-R charset (XEmacs SJT> currently doesn't have one), and install it in private space. Like the SJT> "no Mule" solution, this would require that you use KOI8-R file SJT> encodings; you would not be able to easily save those buffers in SJT> ISO-8559-5. You would also find it difficult to save multilingual files SJT> mixing KOI8 with any other character set (except ASCII, of course). SJT> I would guess that would be acceptable (probably everybody already uses SJT> KOI8 in their files); is it? Well, most russian texts/files use three encodings: koi8-r, windows-1251, alternativnaya(rare). Nobody uses iso8859-5 to write in russian. SJT> Can you tell me where I could get free KOI8 fonts? The only one I have SJT> is -etl-fixed-medium-r-normal--16-160-72-72-c-80-koi8-1 from the GNU SJT> intlfonts collection. http://sunsite.doc.ic.ac.uk/Mirrors/ftp.redhat.com/pub/redhat/redhat-6.2/... SJT> Also, how are the KOI8-R fonts specified under X and Windows? (I can't SJT> do much about the latter, I don't know anything about Windows, but I can SJT> at least document it for when somebody who does Windows wants to work on SJT> it.) Don't understand your question :( SJT> It's going to be a while before I can work much on this, but let me know SJT> about the GNU Emacs, what registry(s) are used for KOI8-R in X11, and SJT> whether saving files in KOI8-R is acceptable. Ok. SJT> I may have more questions to make things more robust and allow SJT> multilingual use, but answers to these should be enough to allow Mule to SJT> work with pure KOI8-R files and display them on screen. Nick.

2 participants
1 comments

Re: External modules 24 years

Adrian Aichner

>>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: Gunnar> Adrian Aichner <adrian(a)xemacs.org> writes: >> >>>>> "Jerry" == Jerry James <james(a)eecs.ukans.edu> writes: >> Jerry> I am willing to be a guinea pig to help get external Jerry> modules working, but I need some direction from the list Jerry> and whoever is coordinating module development. >> >> Would that be you, Gunnar? Gunnar> Me? No, not at all. What makes you think that? I am afraid A neutrino must have fired the wrong synapse in my skull on its way through the earth. Gunnar> I don't know anything about modules or autoconf magic. Gunnar> I guess our (only) modules expert is J. Kean Johnston Gunnar> <jkj(a)sco.com> Gunnar> Gunnar -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org

1 participants
0 comments

Re: External modules 24 years

Gunnar Evermann

Adrian Aichner <adrian(a)xemacs.org> writes: > >>>>> "Jerry" == Jerry James <james(a)eecs.ukans.edu> writes: > > Jerry> I am willing to be a guinea pig to help get external > Jerry> modules working, but I need some direction from the list > Jerry> and whoever is coordinating module development. > > Would that be you, Gunnar? Me? No, not at all. What makes you think that? I am afraid I don't know anything about modules or autoconf magic. I guess our (only) modules expert is J. Kean Johnston <jkj(a)sco.com> Gunnar

1 participants
0 comments

Re: PSGML's syntax table for HTML error in XEmacs 21.1 24 years

Adrian Aichner

>>>>> "Gleb" == Gleb Arshinov <gleb(a)broadbase.com> writes: >>>>> "Jerry" == Jerry James <james(a)eecs.ukans.edu> writes: Gleb> It seems like I hit the problem previously reported in Gleb> http://www.xemacs.org/list-archives/xemacs-beta/200009/msg00153.html Jerry> The problem there was that Stephen had an old version of Jerry> PSGML installed. You appear to have the latest version, Jerry> however. Also note that Stephen's problem was with XML, Jerry> but your patch modifies sgml-parser-syntax. If you look at Jerry> the code in psgml-parse.el just after your patch, you will Jerry> see that the colon *is* in xml-parser-syntax. So this does Jerry> not seem to be the problem previously reported. Gleb> Hi Jerry, Gleb> The way I read it, Stephen's problem is exact same one I am reporting. Gleb> Let me try to provide more detail. Jerry> What, exactly, were you trying to do, and what did PSGML do Jerry> that you consider incorrect? Gleb> Basically, I wanted to migrate my HTML documents from "-//W3C//DTD Gleb> HTML 4.0 Transitional//EN" to "-//W3C//DTD XHTML 1.0 Gleb> Transitional//EN". Both are types of HTML. The latter also happens Gleb> to be XML (XHTML is supposed to be an intersection of HTML spec and Gleb> XML spec). Gleb> I had old PSGML packages which did not include XHTML DTDs, so I Gleb> upgraded all the packages to the latest versions. Then I tried to Gleb> validate a small XHTML document: Jerry> Can you give some example SGML that shows the problem? Gleb> <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"> Please use this instead: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> so that people can easily find the canonical DTD information. Gleb> <html> Gleb> <head> Gleb> <title>My Title</title> Gleb> </head> Gleb> <body> Gleb> <h1>My Title</h1> Gleb> </body> Gleb> </html> Gleb> Save this to a file xhtml_test.html. Open it. Run C-c C-p Gleb> `sgml-parse-prolog'. At this point PSGML attempted to compile Gleb> xhtml1-transitional.dtd, and barfed while parsing it (i.e. while Gleb> parsing the DTD not the XHTML test document). The backtrace for this Gleb> is in my original message. I had this problem too. I think you need to edit XHTML documents in xml-mode! PSGML should switch to xml-mode based on a XHTML DTD, I think. Here's what I did for the XEmacs website at http://xemacs.sourceforge.net/[1] See (defun psgml-find-file-hook () in http://xemacs.sourceforge.net/batch-psgml-validate.el I should obviously rename that hook, since it's not in psgml*.el, but in batch-psgml-validate.el. Best regards, Adrian Gleb> After much scratching my head, I figured out that lines of the form: Gleb> xml:lang language code (as per XML 1.0 spec) Gleb> in xhtml1-transitional.dtd were causing the parsing error. When I Gleb> removed these lines, PSGML was able to parse and compile the DTD. The Gleb> reason parsing of this DTD fails seems to be that PSGML uses Gleb> sgml-parser-syntax to parse the DTD and it considers ':' a terminator Gleb> for the token. So adding ':' to sgml-parser-syntax got rid of the Gleb> problem for me. Jerry> Finally, if this really is a problem with PSGML, it should Jerry> also be reported to Lennart Staflin, the PSGML maintainer. Gleb> The way I read Stephen's message, it worked for him in 21.2. If this Gleb> works in 21.2 but not in 21.1, I figure XEmacs team should have the Gleb> first try. Gleb> Gleb Footnotes: [1] That site is mostly XHTML 1.0 already, automatically validated by PSGML! -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org

4 participants
6 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 November 2000