Hello,
byte-compiling an upward funarg situation within a lexical-let is
problematic:
(funcall (lexical-let ((a 42)) (lambda () a))) => 42
(funcall (lexical-let ((a 42)) (byte-compile (lambda () a)))) => 42
Okay, modulo a compile-log warning:
** Passing a quoted lambda (arg 1) to #'apply, forcing function quoting
After that, there are more contrived situations where it completely
stops working, as in cases where you need to partially evaluate the
lambda-form:
(funcall (lexical-let ((a 42)) (byte-compile (eval '(lambda () a)))))
=> [bad lexical ref]
This is simplified, but think `(lambda () ,foo stuff a).
In general, the problem occurs when you can't control the time at which
cl-macroexpand-all performs. In such situations, the lexically let
symbols translation may miss some cases occuring in already
byte-compiled forms.
I can't quite figure out a way around this right now. Any ideas ?
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2011-05-31 - 2011-06-07)
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.
521 open ( +3) / 249 closed ( +0) / 770 total ( +3)
Open issues with patches: 12
Average duration of open issues: 873 days.
Median duration of open issues: 920 days.
Open Issues Breakdown
new 187 ( +1)
deferred 6 ( +0)
napping 4 ( +0)
verified 53 ( +0)
assigned 151 ( +0)
committed 28 ( +0)
documented 3 ( +0)
done/needs work 24 ( +0)
Issues Created Or Reopened (3)
______________________________
other-frame can pick an unraisable frame 2011-06-03
http://tracker.xemacs.org/XEmacs/its/issue770 created stephen
[Bug: 21.5-b31] Can't show Track Activate Strokes (Customize) 2011-06-04
http://tracker.xemacs.org/XEmacs/its/issue771 created mike.kupfer
[Bug: 21.5-b31] mouse-track-adjust only works with Sh-button1 2011-06-04
http://tracker.xemacs.org/XEmacs/its/issue772 created mike.kupfer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Andreas Röhler writes:
> AFAIU: should 'parse-partial-sexp' differ --which hopefully isn't the
> case-- there is no easy way to merge the rest of syntax.el.
The API syntax should not differ, but the semantics might.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hello
Can I now upgrade auctex and reftex whose most recent
versions are under GPL3?
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hello
Steve provided a working x-symbol patch for 21.5.29, however
as far as I understood that patch was considered as being to
ah aggressive, and was not included in 21.5.30. Steve you
sent me another lisp only patch for faces.el and
x-symbol-mule.el however it did not work. So what is the
plan for the future?
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Andreas Röhler writes:
> Also: if GNU syntax.el exists as a section in XEmacs syntax.el, it
> should be easier to apply possibly patches from GNU.
Not in my experience. It's better to maintain our tree organization
than to measure out the rope, tie a knot, and stick our head in the
loop by trying to make it *mechanically* easy to move code from GNU to
XEmacs. Semantically, the two programs are often subtly different,
especially at low levels.
Specifically, I personally paid a very high price for somebody else's
half-assed synch of the syntax-table property. (That person proceeded
to just disappear, and was not available to fix his own undocumented
fuckup.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
On 2/13/11 9:40 AM, Raymond Toy wrote:
> On 2/13/11 5:41 AM, Aidan Kehoe wrote:
>> Ar an triú lá déag de mí Feabhra, scríobh Raymond Toy:
>>
>> > Is it possible to build all of the packages from source using xemacs
>> > 21.5-b29? I checked out all of the packages, copied
>> > Local.rules.template to Local.rules and ran make. This eventually
>> > causes xemacs to die when building advice.el.
>>
>> It should be possible, yes, that’s what the smoketest does (though its
>> 21.5.29 binary is old). Can you paste the error?
>>
> Error attached. I'm using latest xemacs sources fresh from the hg repo
> yesterday. I'm attaching the Installation file, just for the record.
I also meant to say that in the decades (gasp!) of using xemacs, I've
never had a reason to do my own package builds. But I'm doing it now
because I've made a few minor changes to comint (sent to the mailing
list already), that are not yet in the packages. Therefore I made my
own git repo of the cvs sources so I can track my changes and not lose
them as I've already done when moving from one machine to another.
Is there a reason why the packages haven't moved to an hg repo like
xemacs has?
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
Before the alioth upgrade the commit mails started with an info
section like this.
changeset: ...
tag: ...
user: ...
date: ...
files: ...
description:
...
It is not there any more. Unfortunately the buildbot depends on
that. Should I find another solution for getting to that information
or will it be reintroduced?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I start xemacs on the main X11 display and customize the modeline
face background and foreground colors. Eventually I ssh in from
a remote machine and start a gnuclient on the tty.
After the update to F15, and whatever xemacs comes with it, when
I start gnuclient the modeline on the first frame opened in the
X11 display reverts back to the default colors. This didn't use
to happen.
I verify that this is not my doing by invoking
xemacs -vanilla
executing these lines in the *scratch* buffer
(set-face-background 'modeline "Gray75")
(set-face-foreground 'modeline "Black")
(gnuserv-start)
and going to an xterm on the same machine and running
unset DISPLAY; gnuclient -nw
At that point the modeline reverts back to the colors it had
before I executed the code above. I've looked through gnuserv.el
but can't figure out where this could happening. Here is what I
have in this system:
xemacs-21.5.31-1.fc15
xemacs-common-21.5.31-1.fc15
xemacs-el-21.5.31-1.fc15
xemacs-filesystem-21.5.31-1.fc15
xemacs-info-21.5.31-1.fc15
xemacs-packages-base-20110502-1.fc15
xemacs-packages-base-el-20110502-1.fc15
xemacs-packages-extra-20110502-1.fc15
xemacs-packages-extra-el-20110502-1.fc15
-- Henrique
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta