December 2017 - XEmacs-Beta - XEmacs Mailing List Archives

Including "vc-fossil.el" in vc? 5 years, 8 months

Hauke Fath

Hi, I nave been banging a bit on vc-fossil.el from <http://chiselapp.com/user/venks/repository/emacs-fossil/doc/tip/doc/index...>, and got it to work with Xemacses "slightly-older vc. Provided there is interest: What would be the procedure to include the fuke with the XEmacs vc? Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344

2 participants
4 comments

is speed a concern? 5 years, 11 months

Julian Bradfield

Another possibly silly question arising from perusal of the great Mule merge... Is speed (or small linear factors in memory) ever actually a concern nowadays? The whole deal of supporting multiple internal buffer formats seems to be justified by speed for multi-lingual processing, and there are various tricky things scattered around the rest of the code to improve speed. The last time I can remember being disturbed by XEmacs' slowness was sometime in the mid 90s when I was running Lucid Emacs 19 on a 68040. (The days when a full compile was a go-out-for-long-dinner job rather than a you-may-just-have-time-to-make-coffee job.) On the other hand, I don't do extensive non-English processing. Do people find XEmacs noticeably slow in any normal usage pattern? -- 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

6 participants
9 comments

Xft dpi font scaling 6 years, 10 months

René Rebe

Hi there, since years I use xemacs-beta, currently 21.5.34: https://t2sde.org/packages/xemacs-beta Except the lack of updates I am quite happy with that setup, however one details drives me increasingly crazy. Namely HiDPI font scaling when I switch between old displays and newer, 4k+ HiDPI, 192++ dpi screens. I have this font selection in my .xemacs/init.el (set-face-font 'default "Source Code Pro-13") ; or -22 for HiDPI Ideally I want this -13 to be pt, so that I do not have to edit the file each time I switch my desk or continue coding on the road. Googling around suggest others alternative forms which either do not work in xemacs-beta, or do not prove the situation. I tried to read the lisp files, but could not find anything that would help me there either. Is there anything "pt" like so that a 13pt would result in say 13 pixels on a low resolution display, and 26 (or whatever) pixels on a HiDPI screen with the X server dpi set accordingly? PS: Surprisingly the Xemacs menus and such sale automatically, just not this most important, main edit buffer, ..? Best regards – and greetings from Europe, René -- René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin http://exactcode.com | http://t2-project.org | http://rene.rebe.de

3 participants
11 comments

Re: Some XEmacs notes 6 years, 12 months

Aidan Kehoe

Ar an t-ochtú lá is fiche de mí na Nollaig, scríobh Jerry James: > Adding Jeff Sparkes to the conversation. One of you please clue me in > if there is an active mailing list I need to re-sign up for. See other communication, https://lists.xemacs.org/ to sign up. > On Thu, Dec 28, 2017 at 5:45 PM, Jerry James <loganjerry(a)gmail.com> wrote: > > Well, doggone, it only fixed ppc64le. Both big endian architectures, > > ppc64 and s390x, now exhibit some kind of memory failure on startup, > > so I appear to have introduced an assumption of little endianness in > > something I just did. I'll sort that out next.... > > No, it wasn't me. Building on big endian architectures was broken by > this commit: > > changeset: 6384:c6e0b59281cb > user: Jeff Sparkes <jsparkes(a)gmail.com> > date: Mon Apr 26 07:15:04 2010 -0400 > summary: Use G_BIG_ENDIAN instead of WORDS_BIGENDIAN. > > Specifically, src/lisp-union.h requires WORDS_BIGENDIAN to layout a > Lisp object properly, which is the cause of the breakage I am seeing > now. It looks like somebody merged a GTK branch into master, is that > what I'm seeing? Because this commit is from going on 8 years ago. > > A grep shows that there are more instances of WORDS_BIGENDIAN in > src/md5.c, src/glyphs-x.c, and src/redisplay-x.c. > > Was that merge supposed to make building with either gtk2 or gtk3 > work? I get build failures with both. I'm wondering if that is > expected or not. Let me know if it is not expected and I will provide > details. Yes, it was. Building on GTK2 and GTK3 work with warnings but without problems for me. Please give details if it doesn’t work for you. I have undone Jeff’s change to config.h.in, and now WORS_BIGENDIAN is available again. Thanks for reporting this! -- ‘As I sat looking up at the Guinness ad, I could never figure out / How your man stayed up on the surfboard after forty pints of stout’ (C. Moore)

1 participants
0 comments

gdk_events_pending vs. gdk_event_peek 6 years, 12 months

Stephen J. Turnbull

Hi, I did a little spelunking with negative results. 0. Installed current macports sources for gtk3 (includes gdk3) and glib2. 1. There's nothing obvious in the implementation of gdk_events_pending, which first looks at event queues, I think, then goes and examines the "events pending" flag on each open display. If there's a bug, since peek doesn't find any events, I guess it's because somehow that flag doesn't get cleared even though the queue is drained, but I didn't feel like going after that yet. 2. There are no bugs on GNOME.org that look like this. Ditto trac.macports.org. 3. GNU Emacs doesn't use the toolkit event loop at all, but rather invokes event dispatch itself at the glib level. 4. glib also basically just checks "events pending" flags. 5. Thank god for grep. GNU keeps all of its events and command loops in "keyboard.c", and its handling of window system events in "xgselect.c", exactly where you'd expect to find them. <sigh/> I'll push on #1 later, and if that doesn't get anywhere I'll file a bug on GNOME.org. Steve

1 participants
0 comments

GTK3 event loop broken on Mac OS X 6 years, 12 months

Stephen J. Turnbull

Jeff Sparkes, Aidan: If you're listening, I'd appreciate an ACK even if you have nothing to say. (Otherwise I'll eventually spam you personally ....) All, On Mac OS X "High Sierra" I'm having trouble with the recently committed GTK3 port (thanks Jeff and Aidan!) Lots of things are less than copacetic, but the first problem I ran into is an infloop if I even mouseover the toolbar. Turns out that gdk_events_pending can return non-zero even when gdk_event_peek returns NULL. So I wrote the attached patch to use the latter to test for no more events. This isn't great, but it seems to work. I think I got the GdkEvent cleanup right, but I suppose it's possible this leaks GdkEvents, so be warned. Steve

3 participants
2 comments

Summary of XEmacs Issue Tracking System Issues 6 years, 12 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2017-12-19 - 2017-12-26) XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 574 open ( +0) / 323 closed ( +0) / 897 total ( +0) Open issues with patches: 13 Average duration of open issues: 2999 days. Median duration of open issues: 3210 days. Open Issues Breakdown new 266 ( +0) deferred 6 ( +0) napping 3 ( +0) verified 57 ( +0) assigned 145 ( +0) committed 19 ( +0) documented 3 ( +0) done/needs work 15 ( +0)

1 participants
0 comments

Re: Failures in "test charset-in-* functions" in mule-tests.el 6 years, 12 months

Aidan Kehoe

Ar an ceathrú lá is fiche de mí na Nollaig, scríobh Stephen J. Turnbull: > So after dealing with the test all characters issue[1] I noticed that > charsets-in-region and charsets-in-string were failing. I suspect the > reason is that in the Unicode build the precedence lists are not tuned > right. I guess a real fix would need to be some intelligent approach > to modifying the precedence list according to the charsets used at > read time or input (although that won't work if the input is > Unicode). The other problem is that "intelligent" really means > constructing some kind of precedence graph, and it could easily be > impossible (eg if both Chinese and Japanese were used in the same > file, you'd need a language tag to disambiguate). > > I guess the first thing I'd try is ensuring that ISO charsets come > before the windows-xxx and IBM CPxxx versions. > > Any other suggestions? We could disable the charsets-in-region tests on the Unicode builds. Or have a defined order we expect depending on the current language environment; but to be honest, with unicode-internal, the output of charsets-in-region isn’t something the user is going to care about, I would lean more towards the former. > Footnotes: > [1] By the way, why does the Unicode build have a 2^30 repertoire? > ISO 10646 has a 2^31 repertoire IIRC (maybe 2^32?), but Unicode only > has 2^21 (precisely, 2^20+2^16). Ben’s choice. We do need more than 2^21, for our invalid sequence characters, but we certainly don’t need the full 2^30. -- ‘As I sat looking up at the Guinness ad, I could never figure out / How your man stayed up on the surfboard after forty pints of stout’ (C. Moore)

2 participants
3 comments

Test of all characters 7 years

Stephen J. Turnbull

Hi, I got tired of having "make check" stall on mule-tests. Something I don't understand is going on, because Skip-Test-Unless is failing the char-code-limit condition, but doing the test anyway. The only thing I can think of is that Skip-Test-Unless is a macro but for some reason evaluates its condition anyway, which is a bug, but I'm not sure whether it's in XEmacs or in Skip-Test-Unless. Currently I'm dealing with it with the attached patch. If nobody has an idea about the underlying bug, I'll apply it in January. -- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull(a)sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN

2 participants
1 comments

GTK 1 support has been removed from the trunk. 7 years

Aidan Kehoe

I’ve just merged Jeff Sparkes’ GTK-2-and-greater branch into the trunk code, and imported the branch wholesale into the trunk. I intended to develop for GTK-2-with-pango by default from here on in, though of course I will support X11. I will be keeping an eye on the buildbot and will trigger a package rebuild in the next few days to see what provokes, but please get in touch if that provokes any issues. -- ‘As I sat looking up at the Guinness ad, I could never figure out / How your man stayed up on the surfboard after forty pints of stout’ (C. Moore)

2 participants
2 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 2017