December 2006 - XEmacs-Beta - XEmacs Mailing List Archives

Bug with redefinition of register on ia64 architecture 17 years, 4 months

Hans de Graaff

Hi, One of the currently open Gentoo bugs for XEmacs 21.4 has to do with the redefinition of register in src/lisp.h on ia64. I don't have access to this architecture so I can't check myself, but the bug report contains a good description of the problem: http://bugs.gentoo.org/show_bug.cgi?id=73366 I had a quick look in src/lisp.h myself, and I found it interesting to see that the code that is currently enabled is the DEBUG_XEMACS code. It seems that using the non-debug variant would solve this particular problem, but this may have other repercussions. It would be great if someone could have a look at this. Kind regards, Hans _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

3 participants
5 comments

checking for fields 17 years, 4 months

Ilya N. Golubev

Emacs version: 21.4a. Merged from emacs 21 to xemacs 21.5 with the same bug, so cross- posting there. `beginning-of-line' (in emacs only: another inconsistency of the merge), `forward-paragraph' and many other commands by default refuse to move across field boundaries. It is not even stated so in their docstings, for `forward-paragraph' at least. Other commands on top of them are also affected by that, and in an obscure way. Viper vi state `f' command operate within paragraph boundary as determined by `forward-paragraph' (which is also not documented), and if the boundary is before the end of line due to fields, then characters on that line are not found as expected. It actually happens with default settings of `shell-mode', if point is in shell prompt and character to find is in command being edited, which are different fields set up by `comint'. There is even no interactive commands to check for fields explicitly. All of the field limiting only overloads existing point movement commands. Some packages may set different faces for different fields, like `comint' does (using `comint-highlight-prompt' face), or may set nothing except fields themselves. It is entirely up to package. And even if face with different foreground color (or other visual attributes) is set, differences between it and text outside the field may be visible or not visible on particular display / terminal. (With xemacs `comint.el' after revision 1.14 of 2006/05/25 it is even more complex. `comint-highlight-prompt' is used only for `font-lock-face' extent property, so there is an additional unknown of whether font lock mode is on. It is also not typical use of font lock to denote otherwise hidden text areas across which regular editing commands will refuse to move, and thus required in this case. Normally it is used for syntax structures which may be easily recognized otherwise, across which editing commands move freely, and thus optional.) Generally user has to resort to evaluating elisp expressions to figure what is going on. Or, in emacs, work around it all by setting `inhibit-field-text-motion t' locally. Can not do so in xemacs due to bug in its comint. For these reasons considering lack of interactive commands to check for field boundaries a bug. These commands should do the same regardless of minor modes, faces attributes and display capabilities in particular emacs process. Explicit error messages about hitting field boundary would be even better. ** Why still report for emacs 21. Limiting movements to fields as described appeared in 21 release branch only, as 1999-10-17 Miles Bader <miles(a)gnu.org> change. If users could have noticed that and complained about that in that time, it would be reasonable now to recommend them just to switch to new development branch from release 21 one. But at that time emacs cvs was not publicly readable. Such a recommendation would be at best unreasonable. It signals that now it is <too late> to complain about release 21 bugs. Until 21 release, it was <too early> to do so. When there was time to do so, then?

2 participants
2 comments

Since 2006-10-28, someone has broken `Face-frob-property' 17 years, 4 months

Nix

I just upgraded to latest CVS (2006-12-16, 21:20) to try to dig further into this KKCC-related (?) memory leak. (I'll know for sure if it's KKCC-related in an hour or so.) Instantly I had two new problems. The first was that all my comments were suddenly popping up in proportional fonts. The first two things I do to `font-lock-comment-face' are these: (make-face-italic 'font-lock-comment-face) (make-face-unbold 'font-lock-comment-face) and after the second, the face was changing drastically. (copy-face 'font-lock-comment-face 'foo-test-face) (face-font-name 'foo-test-face) "Bitstream Vera Sans Mono-11" (make-face-unbold 'foo-test-face) (face-font-name 'foo-test-face) "-*-lucidatypewriter-medium-o-*-*-*-120-*-*-*-*-*-*" What's going on? It becomes clearer if we look at the face's plists. Before: (cl-prettyprint (object-plist (get-face 'foo-test-face))) (foreground #<color-specifier global= [...] font #<font-specifier global=<unspecified> fallback=#<font-specifier global= (((x) . "Bitstream Vera Sans Mono-11") ((encode-as-utf-8 initial x) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((initial two-dimensional x) . "Monospace-12") ((final one-dimensional x) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((final two-dimensional x) . "-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1")) fallback= (((tty) . "normal") ((x) . "-*-lucidatypewriter-medium-r-*-*-*-120-*-*-*-*-*-*") ((x) . "-*-*-medium-r-*-*-*-120-*-*-c-*-*-*") ((x encode-as-utf-8 initial) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((x two-dimensional initial) . "Monospace-12") ((x two-dimensional initial) . "Sazanami Mincho-12") ((x one-dimensional final) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((x two-dimensional final) . "-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1") ((x) . "*")) 0x1f98> 0x2ca057> display-table [...] At this stage, we have an empty global and two fallback objects, one constructed from X resources (I think) and one from raw C code. After: (foreground #<color-specifier [...] font #<font-specifier global= (((default x) . "-*-lucidatypewriter-medium-r-*-*-*-120-*-*-*-*-*-*") ((default x) . "-*-*-medium-r-*-*-*-120-*-*-c-*-*-*") ((default encode-as-utf-8 initial x) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((default final one-dimensional x) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((default final two-dimensional x) . "-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1")) fallback=#<font-specifier global= (((x) . "Bitstream Vera Sans Mono-11") ((encode-as-utf-8 initial x) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((initial two-dimensional x) . "Monospace-12") ((final one-dimensional x) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((final two-dimensional x) . "-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1")) fallback= (((tty) . "normal") ((x) . "-*-lucidatypewriter-medium-r-*-*-*-120-*-*-*-*-*-*") ((x) . "-*-*-medium-r-*-*-*-120-*-*-c-*-*-*") ((x encode-as-utf-8 initial) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((x two-dimensional initial) . "Monospace-12") ((x two-dimensional initial) . "Sazanami Mincho-12") ((x one-dimensional final) . "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1") ((x two-dimensional final) . "-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1") ((x) . "*")) 0x1f98> 0x2ca057> [...] Well, we've got a global spec-list now, but the damn silly thing has gone and used the *last* fallback, the one I can't customize, the one from C code, completely disregarding the X font that was *actually being instanced*. Face-frob-property is a bit of a monster and I haven't dug into it yet: if anyone knows the cause, please say? The second problem was scarier. When writing a region --- *any* region, up to and including a whole buffer --- I got this: Debugger entered--Lisp error: (invalid-byte-code "unbalanced specbinding stack") write-region(1 1242 "~/.emacs-uptimes" nil 0) uptimes-save-uptimes() kill-emacs(nil) call-interactively(kill-emacs) command-execute(kill-emacs t) execute-extended-command(nil) call-interactively(execute-extended-command) (dispatch-event "[internal]") Obviously this happened at the return from write-region (that's the only place this error gets generated): (gdb) print speccount $13 = 29 (gdb) print specpdl_depth_counter $14 = 30 I was trying to diagnose this bug further when it vanished. Unless symlinking xemacs/src/.gdbinit into ~ could cause this (!) then it vanished without obvious cause. Installation-string follows. uname -a: Linux hades 2.6.19.1-skas3-v9-pre9-g968519be-dirty #1 PREEMPT Sat Dec 16 14:56:48 GMT 2006 i686 GNU/Linux /usr/packages/xemacs/21.5.27-20061216/configure '--without-optimization' '--with-dynamic' '--prefix=/usr' '--infodir=${prefix}/info' '--with-infopath=/usr/info' '--with-athena=xaw' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=athena' '--with-widgets=athena' '--with-xft=all' '--with-external-widget' '--with-gpm=no' '--with-sound=alsa' '--with-mule' '--with-mail-locking=flock' '--with-modules' '--with-xim=no' '--without-xfs' '--with-pdump' '--without-newgc' '--with-bignum=gmp' '--with-memory-usage-stats' '--with-assertions' '--with-zlib' '--with-database=berkdb' '--with-postgresql' '--with-error-checking' XEmacs 21.5-b27 "fiddleheads" (+CVS-20061215) configured for `i686-pc-linux'. Compilation Environment and Installation Defaults: Source code location: /usr/packages/xemacs/21.5.27-20061216 Installation prefix: /usr Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler version: gcc (GCC) 4.1.1 - GCC specs file: /usr/packages.bin/gcc/4.1.1-1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/specs - Compiler command: gcc -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked -Wunused-parameter -g -O2 -march=athlon-4 -pipe -D__NO_STRING_INLINES -D__NO_MATH_INLINES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -ffast-math libc version: 2.5 Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: - X Windows libraries location: - Handling WM_COMMAND properly. - Using fontconfig to manage fonts. - Compiling in support for Xft antialiased fonts (EXPERIMENTAL). Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. - Using Xft to render antialiased fonts in menubars. WARNING: This feature will be replaced with a face. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. - Using Xft to render antialiased fonts in tab controls. WARNING: This feature will be replaced with a face. - Using Xft to render antialiased fonts in progress bars. WARNING: This feature will be replaced with a face. WARNING: This feature not yet implemented; setting ignored. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ALSA (Advanced Linux Sound Architecture). Compiling in support for NAS (network audio system). Databases: Compiling in support for Berkeley database. Compiling in support for PostgreSQL. - Using PostgreSQL header file: libpq-fe.h - Using PostgreSQL V7 bindings. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Mail: Compiling in support for "flock" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for dynamic shared object modules. Compiling in support for more number types using the GNU MP library. Using the new GC mark algorithms (KKCC). WARNING: --------------------------------------------------------- WARNING: The new algorithms are experimental. They are enabled by WARNING: default for this release. Use `--disable-kkcc' to WARNING: turn it off. WARNING: --------------------------------------------------------- Using the new portable dumper. Dumping into executable. Compiling in support for extra debugging code. Compiling in support for runtime error checking. WARNING: --------------------------------------------------------- WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- -- `He accused the FSF of being "something of a hypocrit", which shows that he neither understands hypocrisy nor can spell.' --- jimmybgood _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

3 participants
4 comments

Re: Patches for ruby-modes 17 years, 4 months

The XEmacs Package Smoketest

>>>>> Stephen wrote: Stephen> jobs.html is way out of date. I really doubt we have a Stephen> package patch tender anymore (if we ever did :-). OK. So it is up to the reviewers then for the packages that lack a dedicated maintainer. Stephen> Our past experience says that it's important to build a Stephen> package in the XEmacs package tree to ensure consistency, Stephen> especially of inlined code (macros and defsubsts). I know. ;-) I was thinking of maintaining within the package tree but trying to find a procedure that could make it easier for the package tree maintainers. It is hard to know all different modes so just making some small checks, make it build and then let the requester and users beta test it could be a way to handle obscure things without demanding to much labor!? 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

Re: [Bug: 21.4.20] Segmentation Fault on C-SPC (set mark to current location of point) 17 years, 4 months

Vin Shelton

On 12/16/06, Alan M. Feldstein <afelds1(a)earthlink.net> wrote: > > C-SPC in scratch buffer caused Segmentation Fault. Just before the > window disappeared, the status area at the bottom left corner of the > application window changed from "[English/European]" to garbage > characters. What follows is a C stack backtrace and then a Lisp backtrace. I don't think --with-xim works on Solaris. Last time I tried, I couldn't even build that way. HTH, Vin PS. BTW, what's with the 102K .png? It strikes me as a significant waste of bandwidth when sent to all the members of a distribution list. -- The Journey by Mary Oliver http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506 _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2 participants
1 comments

Re: [COMMIT] Don't use the server-side fallbacks for XFT 17 years, 4 months

Aidan Kehoe

Ar an seachtú lá déag de mí na Nollaig, scríobh Nix: > I'll be digging into that while I'm up north (out of contact with primitive > things like X servers, or indeed any device capable of a GUI at all). Wow, I knew things were grim in the north of England, but I hadn’t quite expected that! Anyway, thanks for testing. -- When I was in the scouts, the leader told me to pitch a tent. I couldn't find any pitch, so I used creosote. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

1 participants
0 comments

Re: Patches for ruby-modes 17 years, 4 months

Mike Kupfer

>>>>> "Mats" == Mats Lidell <matsl(a)xemacs.org> writes: Mats> From the MAINTAINERs file the ruby-modes are maintained by the Mats> XEmacs Development Team. I'm not sure what that means. AFAICT, it basically means that there's no dedicated maintainer. So changes only happen if someone happens to find some time and has interest. Hans> If action is needed it would be useful to know what to do. Mats> Voluntering to maintain the package might open some doors and Mats> speed up things ;-) Short of volunteering to be the maintainer, the only thing to do (that I know of ) is post bug reports (and hopefully patches) to xemacs-beta. mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

5 participants
4 comments

Re: Sound Support on Solaris with 21.4.20; Was: [Success with a little effort] XEmacs 21.4.19 17 years, 4 months

Mike Kupfer

A couple years ago (!) someone gave me a patch that uses the current (post-SUNWaudmo) native Solaris audio API. It works fine on SPARC but not on x86 boxes. I suspect it's a byte-ordering issue, but I haven't had time to look at it. I hope to get to it next year, after I've updated the XEmacs MH-E and gnus packages. Once I've got it working on both platforms, I'll submit a patch. cheers, mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

1 participants
0 comments

Name of ocaml package 17 years, 4 months

Hans de Graaff

Hi, Is there a specific reason that the ocaml package is called 'ocaml' and not 'ocaml-mode'? The latter seems to be more consistent with other similar packages such as ruby-mode and perl-mode. I got triggered about this by a Gentoo feature request to rename the package: http://bugs.gentoo.org/show_bug.cgi?id=156943 I'd rather follow XEmacs package names, but I think the suggestion to rename the package makes sense. Kind regards, Hans _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

3 participants
2 comments

Patches for ruby-modes 17 years, 4 months

Hans de Graaff

A few weeks ago I sent a rather large patch to the patches mailing list for ruby-modes. The patch basically brought ruby-modes up to date with the versions distributed with the ruby package itself. I've seen no feedback on this patch, so now I'm wondering if I should just be patient or if additional action is needed to move this patch towards CVS. If action is needed it would be useful to know what to do. Kind regards, Hans _______________________________________________ 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 December 2006