August 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Package freeze - new package release pending 24 years, 3 months

Adrian Aichner

>>>>> "Andreas" == Andreas Jaeger <aj(a)suse.de> writes: Andreas> Hi XEmacs developers, Andreas> a new package release should happen soonish. Please Andreas> don't add any major changes - except showstoppers - Andreas> without my explicit approval! Andreas> Please give the current packages a thorough testing, I'd Andreas> like to release *stable* packages and Sumos. Andreas> This might be my last package dance - Steve Youngs is Andreas> going to take over after this round. I'll still be Andreas> around but Steve will be resonsible. Hey Andreas, you have been a great package patch tender[1]! I hope to see you around a lot. Welcome Steve! Let me know if you need more help with sourgeforge. Best regards, Adrian Andreas> Andreas Andreas> -- Andreas> Andreas Jaeger Andreas> SuSE Labs aj(a)suse.de Andreas> private aj(a)arthur.inka.de Andreas> http://www.suse.de/~aj Footnotes: [1] http://xemacs.sourceforge.net/Develop/jobs.html#package -- Adrian Aichner <adrian(a)xemacs.org>

1 participants
0 comments

why built on sco5 24 years, 3 months

Ilya N. Golubev

Shortly: I always tried to build xemacs without compatibility mode. That is why I failed and had to patch xemacs as described in <02343979a3aa08-gin(a)mo.msk.ru> posted to <xemacs-patches(a)xemacs.org> on Sat, 22 Jul 2000 13:37:46 (GMT). Even if this patch will not be applied, perhaps it should be mentioned in `PROBLEMS' entry concerning sco5 that xemacs also may be built with gcc-2.95.2 in native sco5 mode. (Vanilla) xemacs has (and had at least in 19.12) trouble with encapsulated `stat' on sco5. `#undef stat' of "sysfile.h" causes type mismatches between declarations of what should be `struct stat' residing before redefinition in <sys/stat.h> and after it. But this happens only if we use new `stat' stuff set using struct `st_stat32'. When we use old `stat' stuff based on struct `st_stat16', `stat' is not redefined by system headers and all decls match. Stuff based on `st_stat32' is used in all `native' sco programs. Stuff based on `st_stat16' is used when compiling in mode of compatibility with pre-v5 sco (v. 4 or xenix). In particular, `cc' (from sco5 development system) is able (with `-a ods30' option) to build programs for sco4 which also will run on sco5. This option may be set in system- wide defaults file, which will cause xemacs to build without any code changes as described in `PROBLEMS' file in xemacs distribution. My (supplied with v. 5.0.2) version of development system does not have `icc' mentioned in `PROBLEMS'. I suspect, however, that this compiler is borrowed from older sco systems and works in compatibility mode by default. Perhaps Robert Lipe will be able to check this hypothesis.

1 participants
0 comments

Package freeze - new package release pending 24 years, 3 months

Andreas Jaeger

Hi XEmacs developers, a new package release should happen soonish. Please don't add any major changes - except showstoppers - without my explicit approval! Please give the current packages a thorough testing, I'd like to release *stable* packages and Sumos. This might be my last package dance - Steve Youngs is going to take over after this round. I'll still be around but Steve will be resonsible. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.inka.de http://www.suse.de/~aj

1 participants
0 comments

XEmacs Makefiles 24 years, 3 months

Stephen J. Turnbull

>>>>> "Steve" == Steve Youngs <youngs(a)xemacs.org> writes: Steve> Sorry about the size of this. I kinda got a little carried Steve> away. The Golden Rules of Patching (1) It is better to be correct than fast. (2) Don't call names in patches. (3) It is better to be fast than not. Nor are they correct; just amusing and possibly applicable. Except (2) which is always correct and applicable. Steve> Anyway, the following fixes the Makefiles in XEmacs Steve> packages Which reminds me: I noticed that `make clean' under --pdump configurations doesn't clean up the xemacs.dmp file. Is this intentional? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

2 participants
1 comments

Re: write access (was: link) 24 years, 3 months

Adrian Aichner

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> This doesn't happen to me. If I do all read-only Martin> operations including checkout using :pserver:, then no Martin> CVS/Root file ever ends up containing :ext: APA> But your cvs-rw script specifies -d :ext:... explicitely. APA> And still your CVS/Root does not get changed? Martin> It does not. APA> Interesting! Martin> Perhaps your CVS client is different? Martin> Remember that I usually only use :ext: with commit. Me too. Martin> Could the -w flag make a difference? I don't use it myself. I Martin> recommend removing it. It's the default anyways. APA> I'll try this on my next commit tonite. tonite just slipped a few days. I just did a commit to 21.2 without the -w flag and CVS/Root still got overwritten from :pserver: to :ext:. Here's the command I used: cvs -z3 -d:ext:martinb＠cvs.xemacs.org:/usr/CVSroot commit -m "[21.2 PATCH] trivial typo fix in man/emodules.texi <upumzawxq.fsf(a)ecf.teradyne.com>" ChangeLog emodules.texi Best regards, Adrian APA> Thanks, APA> Adrian APA> -- APA> Adrian Aichner <adrian(a)xemacs.org> -- Adrian Aichner <adrian(a)xemacs.org>

1 participants
0 comments

Re: PSGML mode should not override 'M-BS'. 24 years, 3 months

Daniel Pittman

On Thu, 24 Aug 2000, Martin Buchholz <martin(a)xemacs.org> wrote: >>>>>> "DanP" == Daniel Pittman <daniel(a)danann.net> writes: > > DanP> The new PSGML mode has, in it's keymap, one stunningly > DanP> counter-intuitive binding[1]. > > I agree completely. > >>>>>> "Ray" == Raymond Toy <toy(a)rtp.ericsson.se> writes: > > Ray> I have the same problem. I hate it. I want M-backspace (in > Ray> Fortran mode at least) to kill word just like it does everywhere > Ray> else! (But perhaps this is a bug created when the great > Ray> Backspace vs Delete change took place and Fortran was forgotten? > Ray> I know that Fortran mode used to work correctly.) > > Proof that different users want different things. > > XEmacs thinks BS is BS, whereas FSF Emacs thinks BS is DEL? > > Still, for any particular user preference, XEmacs should work > consistently, so there is a bug here. Mmmm. I think, in part, this is a social problem with the various modes. IIRC, the how to design major modes stuff from the texi covers this as: * Don't redefine standard keys in text-like modes. * Don't redefine them anyway. :) Which, mostly, makes sense to me. One reason I (and others, I know) use (X)Emacs is because you /do/ get the same text-like behavior everywhere. I know that's not why everyone does it, but, it is the least surprising thing to do. >>>>>> "DanH" == Dan Holmsand <dan(a)innehallsbolaget.com> writes: > > DanH> I don't know if it's a bug or a feature - but this is all > DanH> because XEmacs works differently from fsfmacs. Fortran-mode etc > DanH> all define "\e\C-h" in a local keymap, which on XEmacs overrides > DanH> both M-backspace and C-M-h. On fsfmacs it only overrides C-M-h > DanH> (the intended behaviour). > > But FSF Emacs redefines Meta+Backspace if you do > > (global-set-key "\e\C-?" 'backward-char) > > so XEmacs is consistent at the _syntactic_ level. It merely disagrees > on the name of the key labelled "BackSpace" (on my computer). > > DanH> That means that you have to re-assign backward-kill-word > DanH> explicitly to M-BS if you also define C-M-h. > > I vote for someone working with the package maintainers to modify the > key bindings for psgml-mode. > > They can probably be (compatibly!) changed to > > (define-key sgml-mode-map [(meta control h)] > 'sgml-mark-current-element) > > Daniel, could you verify that this kind of change is safe for XEmacs > and Emacs, search for other such changes (some suggested in this > thread), communicate with the other package maintainers, but make the > changes in XEmacs in any case? I am happy to do this sort of thing, but my time is currently kind of crunched. Work is in 'panic before release' mode, so I end up doing long hours and... lacking enthusiasm. I will, at the least, do some investigation into what this will and won't break with, though, and post results to -beta. [...] Daniel -- Cease to be a drudge; seek to be an artist. -- Mary McLeod Bethune

1 participants
0 comments

Re: PSGML mode should not override 'M-BS'. 24 years, 3 months

Martin Buchholz

>>>>> "DanP" == Daniel Pittman <daniel(a)danann.net> writes: DanP> The new PSGML mode has, in it's keymap, one stunningly counter-intuitive DanP> binding[1]. I agree completely. >>>>> "Ray" == Raymond Toy <toy(a)rtp.ericsson.se> writes: Ray> I have the same problem. I hate it. I want M-backspace (in Ray> Fortran mode at least) to kill word just like it does everywhere Ray> else! (But perhaps this is a bug created when the great Ray> Backspace vs Delete change took place and Fortran was forgotten? Ray> I know that Fortran mode used to work correctly.) Proof that different users want different things. XEmacs thinks BS is BS, whereas FSF Emacs thinks BS is DEL? Still, for any particular user preference, XEmacs should work consistently, so there is a bug here. >>>>> "DanH" == Dan Holmsand <dan(a)innehallsbolaget.com> writes: DanH> I don't know if it's a bug or a feature - but this is all because DanH> XEmacs works differently from fsfmacs. Fortran-mode etc all define DanH> "\e\C-h" in a local keymap, which on XEmacs overrides both M-backspace DanH> and C-M-h. On fsfmacs it only overrides C-M-h (the intended DanH> behaviour). But FSF Emacs redefines Meta+Backspace if you do (global-set-key "\e\C-?" 'backward-char) so XEmacs is consistent at the _syntactic_ level. It merely disagrees on the name of the key labelled "BackSpace" (on my computer). DanH> That means that you have to re-assign backward-kill-word explicitly to DanH> M-BS if you also define C-M-h. I vote for someone working with the package maintainers to modify the key bindings for psgml-mode. They can probably be (compatibly!) changed to (define-key sgml-mode-map [(meta control h)] 'sgml-mark-current-element) Daniel, could you verify that this kind of change is safe for XEmacs and Emacs, search for other such changes (some suggested in this thread), communicate with the other package maintainers, but make the changes in XEmacs in any case? It requires a certain amount of development discipline and documentation, but I think the use of `CVS vendor branches' can allow us to safely modify upstream packages and maintain those changes with upgrades. We have to have a clear plan for how those vendor branches should work and what naming convention to use for them. The key binding code in XEmacs could use a lot of work. An interesting project for someone who has time (perhaps me, in a future life). Martin

1 participants
0 comments

[regex] shy grouping with interval quantifier 24 years, 3 months

Daiki Ueno

Hello. I found that interval quantifier doesn't work correctly with "shy" grouping. (string-match "\\(1+\\)\\{2,2\\}" "11") => 0 (string-match "\\(?:1+\\)\\{2,2\\}" "11") => nil I'm using cvs updated the latest beta. XEmacs 21.2 (beta35) \"Nike\" [Lucid] (i686-pc-linux, Mule) of Wed Aug 23 2000 on localhost Thanks, -- Daiki Ueno

1 participants
0 comments

Unix98 pty support suboptimal 24 years, 3 months

Martin Buchholz

If I build the latest XEmacs on Linux with getpt(), I get these warnings: /project/xemacs/ws/ia64/src/process.h:143: warning: `PTY_ITERATION' redefined s/linux.h:216: warning: this is the location of the previous definition /project/xemacs/ws/ia64/src/process.h:146: warning: `PTY_OPEN' redefined s/linux.h:228: warning: this is the location of the previous definition /project/xemacs/ws/ia64/src/process.h:148: warning: `PTY_TTY_NAME_SPRINTF' redefined Inspection shows that we have similar code in src/process.h: #ifdef HAVE_GETPT #define PTY_ITERATION #define PTY_OPEN \ if ((fd = getpt()) < 0 || grantpt (fd) < 0 || unlockpt (fd) < 0) \ return -1; #define PTY_NAME_SPRINTF #define PTY_TTY_NAME_SPRINTF strcpy (pty_name, ptsname (fd)); #endif and src/s/linux.h: #ifdef HAVE_GETPT #define PTY_OPEN \ do { \ fd = getpt(); \ if (fcntl (fd, F_SETFL, O_NDELAY) == -1) \ fatal ("could not set master PTY to non-block mode"); \ } while (0) #else /* the master PTY device */ #define PTY_NAME_SPRINTF strcpy (pty_name, "/dev/ptmx"); #endif /* This sets the name of the slave side of the PTY. grantpt(3) and unlockpt(3) may fork a subprocess, so keep sigchld_handler() from intercepting that death. */ #define PTY_TTY_NAME_SPRINTF \ { \ char *ptsname(), *ptyname; \ \ sigblock(sigmask(SIGCHLD)); \ if (grantpt(fd) == -1) \ fatal("could not grant slave pty"); \ if (unlockpt(fd) == -1) \ fatal("could not unlock slave pty"); \ if (!(ptyname = ptsname(fd))) \ fatal ("could not enable slave pty"); \ strncpy(pty_name, ptyname, sizeof(pty_name)); \ pty_name[sizeof(pty_name) - 1] = 0; \ sigsetmask(siggetmask() & ~sigmask(SIGCHLD)); \ } I see various bugs and buglets: - before redefining macros like PTY_ITERATION, you need to #undef them first. - ptsname doesn't have a full prototype. Actually, we shouldn't have system functions declared in XEmacs source files anyways. - the functions grantpt() and unlockpt() are logically part of PTY_OPEN, not PTY_TTY_NAME_SPRINTF. What exactly were the bugs that this external patch was supposed to fix? Actually, this is the sort of thing I've maintained in the past. My approach would be to grok the pty_termios.c file and import its wisdom into XEmacs. For amusement, here is some code from pty_termios.c: } else if (grantpt(master)) { static char buf[500]; exp_pty_error = buf; sprintf(exp_pty_error,"grantpt(%s) failed - likely reason is that your system administrator (in a rage of blind passion to rid the system of security holes) removed setuid from the utility used internally by grantpt to change pty permissions. Tell your system admin to reestablish setuid on the utility. Get the utility name by running Expect under truss or trace.", expErrnoMsg(errno)); close(master); return(-1); } However, be careful. Expect is a full-time hobby for Don Libes, and fixing the pty code in XEmacs may become a similar full-time hobby. Martin

1 participants
0 comments

Re: Please test http://xemacs.sourceforge.net/ 24 years, 3 months

Adrian Aichner

>>>>> "Terje" == Terje Bless <link(a)tss.no> writes: Terje> Adrian Aichner wrote: >> http://www.w3.org/People/Connolly/9903webtechs-snafu.html Terje> The crucial difference beeing that 1) this one is hosted at Terje> w3.org and 2) it's open source (which, IIRC, the WebTechs Terje> service wasn't). If someone manages to hijack w3.org we Terje> might as well just pack up and go home! The validator is Terje> under the W3C Licence, but as far as I can tell that is Terje> essentially the same as the Perl Artistic License. IOW, you Terje> could just set up a copy on xemacs.org and refer to that in Terje> static HTML instead of kluding around it with Terje> genpage/psgml. genpage is doing something different. You can think of it as a pre-processor with perl under the hood. PSGML can do other nice things. Currently it intends all HTML according to the indenting style we have chosen. It may also normalize all tags and convert them to lower-case in preparation for a migration to XML. What's the scope of the validator? Can it do things like that too? Terje> Anyway, it was just a suggestion. It's on the TODO in any Terje> case and fits nicely with some other stuff I'm planning on Terje> doing. I was only thinking of speeding that particular Terje> feature up if it'd solve the immediate problem on Terje> xemacs.org. I am certainly interested and will have a look when you get somewhere with it. >> I really love the idea of doing it all inside XEmacs. Terje> Actually, I kinda dislike the idea of doing _everything_ in Terje> XEmacs. I just want an editor dammit! Well, and version Terje> control... and debugger support... and compiler Terje> integration... and... oh to hell with it! ... and I want all of it ``buffered'': *compilation*, *shell*, *netstat*, *Backtrace*, *SGML*, etc. Terje> LILO: Booting XEmacs.... :-) And I want it on my Palm NOW! Hard to put up a fight while looking in the same direction :-) Keep me posted. Adrian -- Adrian Aichner <adrian(a)xemacs.org>

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 August 2000