January 2011 - XEmacs-Beta - XEmacs Mailing List Archives

XEmacs Packages have been pre-released (2011-01-10-08) 13 years, 10 months

Norbert Koch

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey there everyone. I have just added the following packages to the 'Pre-Releases' directory: New Packages in Pre-Release: =========================== xemacs-base-2.30-pkg.tar.gz upstream version: none xemacs-devel-1.81-pkg.tar.gz upstream version: none Previously Announced Packages Still in Pre-Release: ================================================== leim-1.32-pkg.tar.gz upstream version: none text-modes-2.00-pkg.tar.gz upstream version: none x-symbol-1.13-pkg.tar.gz upstream version: 4.5.1 Detailed Changes: ================ - ------- ChangeLog Entries from xemacs-packages/xemacs-base/ChangeLog ------- 2011-01-10 Norbert Koch <viteno(a)xemacs.org> * Makefile (VERSION): XEmacs package 2.30 released. 2011-01-08 Aidan Kehoe <kehoea(a)parhasard.net> * add-log.el (patch-to-change-log): Use defun*, not cl-parsing-keywords, now the latter is gone from 21.5. Isn't it a shame the diff command doesn't understand Lisp indentation. Document that an explicit nil was equivalent to the default for the :my-name and :my-email keys, something that cl-parsing-keywords did which defun* (correctly enough) doesn't. - ------- ChangeLog Entries from xemacs-packages/xemacs-devel/ChangeLog ------- 2011-01-10 Norbert Koch <viteno(a)xemacs.org> * Makefile (VERSION): XEmacs package 1.81 released. 2011-01-08 Aidan Kehoe <kehoea(a)parhasard.net> * find-func.el (find-function-C-source): Deal better with #'builtin-symbol-file returning full paths in this function; check for readability of find-function-C-source-directory. Installing These: ================ Manually: - -------- 1) Download the packages that you want to install from: /ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/ 2) Unpack them to: [1] /usr/local/lib/xemacs/xemacs-packages/ 3) Re-start XEmacs. Using XEmacs Package Tools (XEmacs 21.[245].x): - ---------------------------------------------- 1) Tools -> Packages -> Add Download Site -> Pre-Releases 2) Tools -> Packages -> List and Install 3) Select the packages you wish to install (there are brief instructions at the bottom of the packages buffer). 4) Packages -> Install/Remove Selected 5) Re-start XEmacs. Using XEmacs Package Tools (XEmacs 21.1.14): - ------------------------------------------- 1) Options -> Manage Packages -> Add Download Site -> Pre-Releases 2) Options -> Manage Packages -> List and Install 3 - 5) As per XEmacs 21.[245].x. Footnotes: [1] Note: Mule packages should be installed into: /usr/local/lib/xemacs/mule-packages/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFNKrm9gu3ywdHdhM0RAvbyAJsFN+v5GSlJVfg6Cp1BInC48/n4YwCfXjTj k01+5I8uoa2TJATOhReU6iU= =pUsL -----END PGP SIGNATURE----- _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

3 participants
2 comments

Re: matlab+comint: works only for certain comint.el versions. 13 years, 10 months

Uwe Brauer

>> Regarding Re: matlab+comint: works only for certain comint.el versions.; Jerry James <james(a)xemacs.org> adds: >> >> >> There is no bugtrace and I have no idea how to debug it. >> > I tried to sync our comint.el with the Emacs version, > intending to eventually sync up their GDB support. The > first part of that effort appeared in xemacs-base > version 2.04. Various bugs were fixed, but many > remained. The last xemacs-base release to contain that > effort was 2.10. People were having so many problems > with it that I reverted the whole thing, starting in > xemacs-base version 2.11. So it appears that you need > something from that sync effort after all to make > matlab support work correctly. We definitely need to > try the sync again at some point, and for some value of > "we". I am willing to test and to debug anything, but it is also true that the set of Xemacs and matlab user is "almost" empty. Uwe _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

Re: problems with make-extent in matlab.el using the matlab debugger. 13 years, 10 months

Uwe Brauer

>> Regarding Re: problems with make-extent in matlab.el using the matlab debugger.; Jerry James <james(a)xemacs.org> adds: > Are you willing to try an experiment? Of course! >> > What happens if you alias those to the overlay functions defined in the > fsf-compat package (overlay.el)? For example: > (require 'overlay) > (defalias 'matlab-make-overlay 'make-overlay) > (defalias 'matlab-overlay-put 'overlay-put) > etc. Well I tried: (if (featurep 'xemacs) (require 'overlay)) ;; compatibility (if (string-match "X[Ee]macs" emacs-version) (progn ; (defalias 'matlab-make-overlay 'make-extent) (defalias 'matlab-make-overlay 'make-overlay) (defalias 'matlab-overlay-put 'set-extent-property) (defalias 'matlab-overlay-get 'extent-property) ; (defalias 'matlab-delete-overlay 'delete-extent) (defalias 'matlab-delete-overlay 'delete-overlay) ; (defalias 'matlab-overlay-start 'extent-start-position) (defalias 'matlab-overlay-start 'overlay-start) ; (defalias 'matlab-overlay-end 'extent-end-position) (defalias 'matlab-overlay-end 'overlay-end) ; (defalias 'matlab-previous-overlay-change 'previous-extent-change) (defalias 'matlab-previous-overlay-change 'previous-overlay-change) ; (defalias 'matlab-next-overlay-change 'next-extent-change) (defalias 'matlab-next-overlay-change 'next-overlay-change) (defalias 'matlab-overlays-at (lambda (pos) (extent-list nil pos pos))) But the behavior did not change :'( Uwe _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

string-to-syntax for XEmacs 21.4? 13 years, 10 months

Skip Montanaro

GNU Emacs defines a string-to-syntax function in src/syntax.c. XEmacs, at least through 21.4, fails to provide this function. The latest version of python-mode (just released yesterday) uses this function in a number of places. In my poking around I noticed that other major mode implementations seem to use it as well Is there an Emacs Lisp version of this thing floating around somewhere that I can use or is there a way to easily get by without it? Thx, -- Skip Montanaro - skip(a)pobox.com - http://www.smontanaro.net/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
2 comments

matlab+comint: works only for certain comint.el versions. 13 years, 10 months

Uwe Brauer

Hello I wrote about this subject some month ago, but just now I found out that the problem occurs also with more recent versions of comint.el. The problem I describe occur for xemacs.21.4.21-mule -vanilla xemacs.21.5.29b -vanilla The issue is the following. Matlab is commercial product provided by Mathworks. If I am not mistaken it is released every 6 month. There is a lisp package, matlab.el, now maintained by Eric Ludlam, which helps editing matlab files but also allow to connect to the matlab engine via matlab-shell and it also allows to debug (In a way similar to the emacs shell command). The current version of matlab is 3.3.1. Now comes the issue: When I use an older version of matlab (release 2004) I have no problem to use the matlab-shell command. When I use a more recent version (release 2008, newer version I don't have), then there is the following problem. When I use comint.el from xemacs-base 2.10, everything is fine. But if I use either an older or a newer comint version, say from xemacs-base 2.19, then the matlab-shell command tries to start matlab but then I obtain an error M-Shell aborted There is no bugtrace and I have no idea how to debug it. There are a lot of changes between these two comint.el version so I don't know how to track down this error. Can anybody who knows about the recent changes in comint.el help me, because I would like that more recent versions of xemacs-base would allow xemacs users to use matlab, right now they have to downgrade the comint.el version which is not a good solution. regards Uwe Brauer _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

GPLv3|L8R -- Remaining files one by one: "nt/Win32.cf" 13 years, 10 months

The XEmacs Package Smoketest

Hi, According to the ChangeLog entry this file and "nt/site.def" are example files for X! And yes they do look like copies of these files as distributed with your X11! (I don't understand why they were added there in the first place!?) The comment about examples seems to be true as well. I find no reference to them from some other file. So these seems like good candidates for removal. Logic being: They are a part of another well known package and they are not used. (Am I missing something?) Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

4 participants
4 comments

regexps 13 years, 10 months

Jamie Zawinski

Having not followed the politics in years, I don't know whether this is still considered heresy, but I have to ask: Isn't it about time that XEmacs supported the Perl/Python/Javascript regexp syntax? The world has moved on. Even if church dogma dictates that we still double-slashify all our parens in Lisp code, Perl's simpler syntax could still be supported for interactive commands. It's mostly the extra backslashing and lack of \s that drives me crazy on a daily basis. I suppose a bound variable around re-search-forward, to indicate the parsing style, would be the way to go. That, or a separate function for new-style, like PHP does. -- Jamie Zawinski http://www.jwz.org/ http://www.dnalounge.com/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

13 participants
24 comments

GPLv3|L8R -- Remaining files one by one: "modules/base64/Makefile" 13 years, 10 months

The XEmacs Package Smoketest

Hi, This time it is "modules/base64/Makefile" that is the item under investigation. I think we can include the file "modules/zlib/Makefile" as well since it seems to have the same history. I have done some analysis in order to follow these files but it is tricky. I don't even know if it helps that much. Read on and you'll be the judge of that. Anyway if I get it right the introduction of the modules directory seems to be attributed to William Perry. Somewhere around version 20.5. At that time there were Makefile.in's in the bae64 and zlib directories. These Makefile.in's were later replaced by plain Makefile's in 21.2.9. (February 1999?) From the ChangeLog it is not clear who did that change. Work with loadable modules are attributed to both Damon Lipparelli and J. Kean Johnston in that version but it could have been someone else who fixed the Makefiles. I believe these are the versions of the files we have today anyway. At some time later the other directories under modules got configurable Makefile.in.in but not zlib and base64. Maybe because these modules are not used? Oddly!? the very same Makefile is found here: http://autocad.xarch.at/lsp_tools/ntemacs/emodules/w32hhelp/ If the dates are correct there that file is younger than what we have. Maybe "ntemacs" gives some clue from where these Makefiles originates. They contain the text "Sample makefile for a simple Emacs module." which indicates they actually come from Emacs or!? Any suggestions on how to deal with these Makefiles? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

3 participants
7 comments

Re: regexps 13 years, 10 months

Stephen J. Turnbull

Jamie Zawinski writes: > > The other question is should we try to support pcre + Emacs > > extensions, or just use the simpler syntax. > > What Emacs extensions do you mean? Mule charsets and character classes mostly. (These are increasingly important, although lots of people don't need them at all.) OTOH, pcre syntax includes some POSIX stuff that we don't have even today ([[:ALPHA:]], for example), and I think it also has extensions to POSIX, right, like context matching? So how far in that direction should we go? I think we can get most of the mileage from a straightforward string- oriented translator. > These days I tend to deal with regexps much more often in perl, > javascript and php, so when I'm back in Emacs-land, OK, so muscle memory etc really matters here; simple dodges like #r are helpful, but not yet optimal. > And I never remember what the Emacs equivalents of \d and \s are, Ooh, that hits me where I live. "\s-" instead of "\s" doesn't bother me, but it is annoying to me that we don't support "\d". > It also sure would be nice if copying a regexp from some random > piece of perl code and pasting it into emacs-lisp code just worked, I'm not sure that can happen. You'll need to wrap it either with a function or a variable binding because Elisp will have to default to Emacs regexps for the forseeable future. Is such wrapping good enough? > Also, the perl "x" syntax (allowing inline whitespace and comments) > is really nice. You can fake most of that in emacs by splitting a > regexp into multiple lines and using concat, but the more concise > syntax would be better. You mean, instead of (concat "foo" ;; sine qua non "\s+" ;; multiple spaces occur in justified text "bar") ;; preferably DNA Lounge you want "foo ;; sine qua non \s+ ;; multiple spaces occur in justified text bar ;; preferably DNA Lounge" or so? Does look nice (especially avoiding that stray close paren in the "middle" of describing the regexp). What do you suggest for the comment delimiter? "#" as in Perl and Python, I guess, given your copy/paste use case. I think I'd rather not use both. > Random thought: what if the #r syntax allowed arbitrary delimiters > like sed's "s" does, so that #r"foo\bar" was equivalent to > #r/foo\bar/ and #r＠foo\bar＠ ? That would also allow trailing > regexp flags like #r/foo/i and #r/foo \s+ bar/x. Pretty random (although Lars came up with the same kind of thing, so maybe ...). But remember, #r is reader syntax. How do you propose conveying those flags to the regexp compiler and/or search driver? As string properties, maybe. Seems unlispy to me. And what about #r/foo\bar/unknown -- would that be a syntax error? But then you'd need to embed knowledge of the flag syntax in the lexer. I think I would prefer that flags be (an) argument(s) to the regexp translator, or use the Python "(?FLAGS)" syntax in the string. But I'm admittedly biased toward Python vs. Perl. Another possibility would be to have Perl-style regexps be delimited within the string: #r"/foo \s+ bar/x" Ugly, though. I guess you could allow #r/foo \s+ bar/x and pass the string "/foo \s+ bar/x" to the translator (ie, in this syntax, the string includes the delimiters). Again, seems unlispy to allow non-sexp syntax; I lean toward doing everything with ordinary strings (though the rawstring reader syntax is very useful for regexps). > True. case-fold-search is an analogous precedent, but that doesn't > necessarily make it a good idea. I think this is going to be more like when Bash decided to obey POSIX locales and started collating ASCII as "AaBb...Zz" so that case sensitive search for [a-z] would pick up "Z" (but not "A"!), but not in LANG=C. That was a real PITA. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

7 participants
10 comments

Re: regexps 13 years, 10 months

Stephen J. Turnbull

Jamie Zawinski writes: > So, "#r" can mean "just do backslash hacking", as now, for > historical compatibility, and the new "#R" can mean "read this in > Perl syntax". > - return Funcall ("perl-regexp-to-emacs-regexp", regexp_string, regexp_flags); > That function can either mechanically transform the string into an > Emacs-syntax string, OK. I still don't like the reader macro enough to implement it myself, though. I do think we should implement `perl-regexp-to-emacs-regexp'. Even using my own copious free time. > or it can return a new object of with type-of "perl-regexp" which > prints itself with #R syntax and which string-match accepts as an > argument. (Maybe perl-regexp objects can also be typep 'string.) That, I think, is a bad idea. I think that users would likely to be annoyed whether (concat #R(a)...＠ "...") returns an ordinary string that is interpreted as an Emacs-syntax regexp when handed to a matching function, or a perl-regexp object, or a "non-regexp-string" object, depending on which is the user-supplied part. > > And what about #r/foo\bar/unknown -- would that be a syntax error? > > But then you'd need to embed knowledge of the flag syntax in the lexer. > > #'perl-regexp-to-emacs-regexp just signals, resulting in a parse > error. OK. > Incidentally, #r is inconsistent, as it has no way to read a string > ending in a backslash or a double-quote. That is, the rules for > parsing character N differ from the rules for characters [0-N). A > more consistent grammar would prohibit \" within #r, which is > exactly why sed-syntax regexps allow arbitrary quote-characters > after the "s". Sure. I've only needed such strings as examples of what not to do, though, so I don't consider them a big loss. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 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 January 2011