September 2008 - XEmacs-Beta - XEmacs Mailing List Archives

failure of the \= regexp in buffers with non-ASCII text 16 years, 1 month

Julian Bradfield

This is driving me nuts. The regexp \= (match empty string at point) fails anywhere after the first non-ascii character in a buffer. I'm using XEmacs 21.4.20, Mule build, no exotic config options. To recreate, start xemacs -q, find a new file, either leave it in the default ISO8 coding system or switch it to some other, type aáa and then do M-C-s \ = at each of the four points. It will succeed at points 1 and 2, and fail at points 3 and 4. The problem also occurs in 21.5(beta28). -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2 participants
4 comments

Re: finding font at point 16 years, 1 month

Julian Bradfield

Thanks to Steve and Glynn! I'm sure it would only have taken me another few days to reach that myself ;-) -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

1 participants
0 comments

Re: version string patterns 16 years, 2 months

Stephen J. Turnbull

Marcus Harnisch writes: > Look, there's a package (CEDET) whose author (and pretty much only > active developer) recently declared that he will focus on merging his > code into Emacs (http://article.gmane.org/gmane.emacs.semantic/1572). > Clearly, writing code to support features only available in XEmacs is > not on his TODO list. Why is that clear? If the features are *better*, and labor-saving for him, he might just push to get them into Emacs, too. > As far as I am concerned, I am just a user who is trying to get CEDET > to work on his XEmacs. When I have the time I'll come up with > something. Well, you're a volunteer, too, of course. Do what works for you. I'm just tired of seeing third parties like you and Eric waste effort on problems that were solved years ago. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2 participants
1 comments

Re: version string patterns 16 years, 2 months

Stephen J. Turnbull

Marcus Harnisch writes: > Traditions never die. Try this for kicks: Old code that works need not change. That's quite a different issue. It's this business of using old fragile hacks in new code that makes me puke when I look at GNU code. > Shouldn't we have all converted to (featurep 'xemacs) or similar? No. Why change what works? If somebody *wants* to do it, a patch will probably be accepted. > > XEmacs has for several years had a (mostly) systematic way of dealing > > with version numbers. > > Sure. But Emacs doesn't, apart from these two: So we have to wait for another decade because Emacs sucks even more than XEmacs does? The ONLY way to get Emacs developers to adopt modern practices is to get the code in front of their faces so that they realize that it's better (although that's not necessarily going to persuade them). > Before *rewriting* inversion.el for XEmacs, I thought that a less > invasive modification to support current XEmacs would be the better > option. Look, you're just going to end up with inversion-emacs-major-version inversion-emacs-minor-version etc etc (or the moral equivalents) anyway, right? How about wrapping the current code with (setq inversion-emacs-major-mode (when (boundp emacs-major-mode) emacs-major-mode) inversion-emacs-minor-mode (when (boundp emacs-minor-mode) emacs-minor-mode) ;; etc etc ;; if you want, we can even obsolete-alias the xemacs-* version ;; variables for future cross-emacs standardization but your code ;; will still need to deal with the old wacko xemacs-* versions. ) (unless (and inversion-emacs-major-mode inversion-emacs-minor-mode ;; etc etc ) (do-it-the-old-crufty-way-that-warms-rms's-heart)) and then you can modify the old crufty way to snaggle out only stuff that isn't available in native variables already, at some future date. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2 participants
1 comments

version string patterns 16 years, 2 months

Marcus Harnisch

Hi all The current CVS version from CEDET throws an error when loaded. Reason is the library `inversion'[1] which comes with CEDET and aims at providing a standard interface for dealing with version numbers and strings. It parses `emacs-version' using a list of regular expressions (`inversion-decoders') and tries to figure whether this is a full release, alpha, beta, etc. None of the regexps matches our format: "21.5 (beta28) \"fuki\" 4cb7c59b5201 XEmacs Lucid" I guess it wouldn't be too difficult to add XEmacs regexps to these. But looking at version.el I found some confusing information: ,---- | (defconst emacs-version | (format "%d.%d %s%s%s%s%s" | emacs-major-version | emacs-minor-version | (if emacs-patch-level | (format "(patch %d)" emacs-patch-level) | "") | (if xemacs-betaname | (concat " " xemacs-betaname) | "") | (if xemacs-codename | (concat " \"" xemacs-codename "\"") | "") | (if xemacs-extra-name | (concat " " xemacs-extra-name) | "") | " XEmacs Lucid") | "Version numbers of this version of XEmacs.") `---- Conditionals evaluating `emacs-patch-level' and `xemacs-betaname' are not mutually exclusive. What does it tell me if both variables are non-nil? Does that indicate a patch for a beta-XEmacs, or a beta version of the next patch-level? IOW, would "21.5 (patch 37) (beta93)" be more like 21.5.37.93 or 21.5.93.37? Thanks Marcus Footnotes: [1] http://cedet.cvs.sourceforge.net/cedet/cedet/common/inversion.el?revision... _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

4 participants
4 comments

Re: reftex needs to be upgraded. 16 years, 2 months

Stephen J. Turnbull

Rodney Sparapani writes: > However, having looked at the results spit out for ESS makes me wonder > what exactly you are doing. You have spit out a PostScript file for > example. How do you license a PostScript file? Same way as you license any other file. Every file we distribute must be licensed to us for distribution. If it's part of XEmacs, it must be compatible with the GPL of appropriate version. If it's generated, it normally comes under the license of the file it was generated from. I guess in the packages we do need to look for GFDL specifically, and in the XEmacs core documentation, for the unnamed doc license. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

4 participants
7 comments

Re: [issue] XEmacs often crashes when "VI emulation" is activated. (RHEL4) 16 years, 2 months

Daniel Novotny

Okay, sending as plain text, no prob Daniel ----- "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote: > Sorry, but my mailreader doesn't handle zip files automatically. You > could wait for me to save and open the zip file manually, but that > will take a while, maybe forever if your mail ends up far enough down > the stack. > > Or you can take what hints I can give in 60 seconds, and maybe > somebody else will pick up the ball during the conversation. That's > just the reality of my life for the next month. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

1 participants
0 comments

Re: [issue] XEmacs often crashes when "VI emulation" is activated. (RHEL4) 16 years, 2 months

Daniel Novotny

----- "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote: > Daniel Novotny writes: > > > I am now solving a bug in RHEL4 > > (https://bugzilla.redhat.com/show_bug.cgi?id=249668), but I got to > > very strange behavior while debugging it > > > > in the "bytecode.c" file xemacs abort()s in the function > > execute_rare_opcode(), because it somehow got another opcode than > > the ones listed in the switch: > > There is a known type of bug in the bytecode interpreter where > bytecode interpreter's stack gets corrupted. This kind of bug is due > to a failure of one of the bytecode internal functions to save enough > stack space. That bug has this kind of signature. > > > inside the function execute_rare_opcode() the "opcode" parameter > > seems to be 0, however when I go one stack frame up, > > What function is in the parent frame? execute_optimized_program () - it all was in my bugreport ZIP file, I sent with the previous mail (the text file xemacs-vi-mode-bugreport.txt shows my GDB session, with me going up and down the stack and inspecting variables) > > > it shows that the REGISTER variable "opcode", which should get > > passed to the function, is 5590 and not 0, > > This is already bad. When opcode gets passed to execute_rare_opcode, > it's supposed to be an enum; 5590 is out of range (> 255) and neither > 0 nor 5590 % 256 are valid members of the enum. > > > If it's a compiler issue, it may have to do with misuse of register > variables. You could try compiling without the register declaration. Interesting, when I comment out the register declaration specifier on all the variables, I am getting another error elsewhere in the code: 100% reproducible the same thing again, a segfault I attach the "where" backtrace in this mail best regards, Daniel _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2 participants
1 comments

Re: reftex needs to be upgraded. 16 years, 2 months

The XEmacs Package Smoketest

>>>>> Rodney Sparapani <rsparapa(a)mcw.edu> writes: Rodney> However, having looked at the results spit out for ESS makes Rodney> me wonder what exactly you are doing. You have spit out a Rodney> PostScript file for example. How do you license a PostScript Rodney> file? IANAL, but I assumed that you were concerned with Rodney> e-lisp files only. The script works by artificial stupidity and goes through every files it finds. If there is nothing that looks like a GFPLv2 or LGPLv2 license notice in the beginning of the file it is reported as possible candidate for further manual inspection. The script uses a list though of known extensions that is considered to be safe, not possible to license. If Postscript files can be safely ignored it is easy to add any extension that is applicable, I guess ".ps" is a good candidate here. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2 participants
1 comments

XEmacs often crashes when "VI emulation" is activated. (RHEL4) 16 years, 2 months

Daniel Novotny

hello, I am now solving a bug in RHEL4 (https://bugzilla.redhat.com/show_bug.cgi?id=249668), but I got to very strange behavior while debugging it in the "bytecode.c" file xemacs abort()s in the function execute_rare_opcode(), because it somehow got another opcode than the ones listed in the switch: inside the function execute_rare_opcode() the "opcode" parameter seems to be 0, however when I go one stack frame up, it shows that the REGISTER variable "opcode", which should get passed to the function, is 5590 and not 0, so the program should get to the "if" -push constant- and not "else" -execute_rare_opcode()- part see my attached gdb session for details: the core file is large, I uploaded it to http://grafomanie.zapisnik.cz/xemacs-vi-mode-bugreport-with-core.zip The comment in the "bytecode.c" file is, that it is heavily optimized, so maybe this is an compiler/optimalization issue, but it happens even with -O0, even tried the "-fno-caller-saves" switch "PROBLEM" file mentions. Maybe there is some other compiler switch wrong? Or could there be race condition in the code perhaps? I see the file is not touched for several years in the project, so it probably is correct :) Maybe I take a wrong approach, can you help me, please? Attached: "Installation" file from the build tree, "where" from gdb and a txt file with my gdb session, showing the mysterious behavior have a nice day, Daniel Novotny _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

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 September 2008