ACTIVITY SUMMARY (2014-11-11 - 2014-11-18)
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.
563 open ( +0) / 317 closed ( +0) / 880 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1916 days.
Median duration of open issues: 2082 days.
Open Issues Breakdown
new 255 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 145 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 15 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Uwe Brauer writes:
> Well but how to write ”? Copy and paste? That is what I said before, cumbersome.
In M-x search-forward you have an ordinary minibuffer, so you just
type it as you normally would, using an Emacs input method, a platform
level input method (on Ubuntu it would be XIM, if your XEmacs is
configured for it), or an AltGr key combination. The latter two might
also work with isearch (eg, Japanese input works in a terminal on Mac
OS X for me).
If you want it to work as it does in GNU, I suppose changing the
syntax of ?” to w would do the trick as well.
Or you could define
;; Untested but looks right.
(defun isearch-yank-character ()
"Pull the character at point in the buffer into search string."
(interactive)
(isearch-yank (function (lambda () (forward-char 1)))))
and bind it to some convenient character in isearch-mode-map.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Uwe Brauer writes:
> > I don't think so. Probably what's happening is that it is being
> > treated as a word character in the other Emacsen you use, while it's
> > being treated as a non-word character in Mule XEmacsen.
>
> Right in GNU (24) it is.
That seems strange to me. I'm almost tempted to call it a bug.
> But I don't remember whether it was ”smooth” or maybe ”regular”
> so I thought of searching just ” the way I described. I could type it,
> kill it and then paste into the search string, but that seems quite
> cumbersome.
It should be possible to enter it directly into isearch. I'm not sure
why that doesn't work (but I'm not surprised, isearch implementation
is a huge crock). What I do when I need to search for something that
isearch doesn't allow to enter is use M-x search-forward.
In the particular case you're talking about I might use a regexp
search: C-u C-s smoo\|reg
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2014-11-04 - 2014-11-11)
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.
563 open ( +0) / 317 closed ( +0) / 880 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1909 days.
Median duration of open issues: 2075 days.
Open Issues Breakdown
new 255 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 145 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 15 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Michael et al -
I fear that it has been too long since I committed anything to the
21.5 tree. Here is the message I am getting:
pushing to https://bitbucket.org/xemacs/xemacs
searching for changes
http authorization required
realm: Bitbucket.org HTTP
user:
Thank you,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Per Stephen's request, I'm forwarding this to xemacs-beta.
- Vin
---------- Forwarded message ----------
From: <turnbull(a)sk.tsukuba.ac.jp>
Date: Sat, Nov 8, 2014 at 2:25 AM
Subject: Re: [P21.5] Patches for Native Windows Builds
To: "It's me FKtPp ;)" <kai.fktpp(a)gmail.com>
Cc: Vin Shelton <acs(a)alumni.princeton.edu>, Michael Sperber
<sperber(a)deinprogramm.de>
Hi all!
We should move this conversation to xemacs-beta. [I'm not doing it and in
fact removed xemacs-patches because my employer's POP3 server is down and
I'm replying from squirrely-mail, and can't change From to my subscribed
address, and on top of that I'm having connectivity issues with
mail.xemacs.org so won't be able to approve it in the spamtrap! Feel free
to forward or just quote in a post to -beta as appropriate. Gaaahh.]
There's an excellent description of GNU Emacs's mingw/msys build system at
http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/nt/INSTALL
If possible we should be compatible with that for obvious reasons, and for
not so obvious reasons -- namely, Stallman is finally coming around on the
issue of loadable modules. My understanding from the Python guys is that
managing them is easy enough on *nix or Mac OS X because everybody agrees
on ABIs on each platform, but it's a world of pain on Windows because of
DLL hell compounded by at least three mutually incompatible ABIs: MSVC,
mingw, and mingw64. (Don't take "ABI" too seriously, the issue is more
which version of msvcrt.dll is used or something like that, but I just use
ABI as an abbreviation.)
The main thing missing from that documentation is the 32bit/64bit issue.
My understanding from the Python discussion I mentioned elsewhere is that
there are current two mingw projects: the dormant "mainline" mingw
(implied -32) project, and the more active but more beta mingw64 project.
I'm not sure which is preferred for GNU Emacs. "Somebody" should ask Eli
Zaretskii <eliz(a)gnu.org> about it. I'd do it (Eli and I go way back), but
really somebody directly involved in the Windows dev work for XEmacs ought
to get to know him, and I can't promise to get involved in that, I've got
too much other stuff I've promised to do already.
> I'd like to paticipate in the force if we chose the later way.
Glad to hear that!
> Thanks,
> kai
>> On Fri, Nov 7, 2014 at 7:54 PM, Vin Shelton <acs(a)alumni.princeton.edu>
>> wrote:
>> > This "auto-migrate" thing sounds cool. Too bad you didn't work in the
>> > compiler or tools groups at Microsoft.
If you like I can put you in touch with Steve Dower at MSFT, who's helping
the Python crew with their migration issues.
>> But don't hold your breath. :-)
Nope.:-) But with fresh blood interested in helping, something should
get done in a reasonable time frame, I think!
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi all!
[@ Vin, Mike, Kai: I fixed my mail/network issues, a combination of
shutting off the unencrypted POP3 server and an "update" to Mac OS X
resulting in an MTU problem on wireless. Sorry for the dupe.]
This is the most recent post in a series that was on XEmacs Patches.
I thought it's probably of interest to a lot of XEmacs users on
Windows, some of whom might be able to help or give advice.
There's an excellent description of GNU Emacs's mingw/msys build system at
http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/nt/INSTALL
If possible we should be compatible with that for obvious reasons, and for
not so obvious reasons -- namely, Stallman is finally coming around on the
issue of loadable modules. My understanding from the Python guys is that
managing them is easy enough on *nix or Mac OS X because everybody agrees
on ABIs on each platform, but it's a world of pain on Windows because of
DLL hell compounded by at least three mutually incompatible ABIs: MSVC,
mingw, and mingw64. (Don't take "ABI" too seriously, the issue is more
which version of msvcrt.dll is used or something like that, but I just use
ABI as an abbreviation.)
The main thing missing from that documentation is the 32bit/64bit issue.
My understanding from the Python discussion I mentioned elsewhere is that
there are current two mingw projects: the dormant "mainline" mingw
(implied -32) project, and the more active but more beta mingw64 project.
I'm not sure which is preferred for GNU Emacs. "Somebody" should ask Eli
Zaretskii <eliz(a)gnu.org> about it. I'd do it (Eli and I go way back), but
really somebody directly involved in the Windows dev work for XEmacs ought
to get to know him, and I can't promise to get involved in that, I've got
too much other stuff I've promised to do already.
> I'd like to paticipate in the force if we chose the later way.
Glad to hear that!
> Thanks,
> kai
>> On Fri, Nov 7, 2014 at 7:54 PM, Vin Shelton <acs(a)alumni.princeton.edu>
>> wrote:
>> > This "auto-migrate" thing sounds cool. Too bad you didn't work in the
>> > compiler or tools groups at Microsoft.
If you like I can put you in touch with Steve Dower at MSFT, who's helping
the Python crew with their migration issues.
>> But don't hold your breath. :-)
Nope.:-) But with fresh blood interested in helping, something should
get done in a reasonable time frame, I think!
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
We have had this problem for a long time in the buildbot. Two builds
on mac and one build on linux seems to be affected by it. Anyone who
can have a look at this?
Since its g++ involved, and the error message talks about not a
throw-expression(!), this sounds quite interesting. Don't you think?
Feel free to beat me to it! ;-)
----------------------------------------------------------------------
...
cd ./src && make all
g++ -c -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked -Wpointer-arith -Weffc++ -g -O3 -fno-strict-aliasing -I/opt/local/include -Demacs -I. -I/Users/buildbot/builds/build-xemacs/rtoy_imac_osx_cfg1/build/src -DHAVE_CONFIG_H -I/usr/X11R6/include/freetype2 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/usr/X11/include abbrev.c
abbrev.c: In function 'Lisp_Symbol* abbrev_oblookup(buffer*, Lisp_Object)':
abbrev.c:234: error: '0' has type 'void' and is not a throw-expression
make[1]: *** [abbrev.o] Error 1
make: *** [src] Error 2
program finished with exit code 2
----------------------------------------------------------------------
Same problem but on linux so another error message.
----------------------------------------------------------------------
...
g++ -c -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked -Weffc++ -g -fno-strict-aliasing -Demacs -I. -I/home/buildbot/slaves/bot1name/matsl_cfg3/build/src -DHAVE_CONFIG_H -I/usr/include/freetype2 abbrev.c
abbrev.c: In function 'Lisp_Symbol* abbrev_oblookup(buffer*, Lisp_Object)':
abbrev.c:234:14: error: third operand to the conditional operator is of type 'void', but the second operand is neither a throw-expression nor of type 'void'
GNUmakefile:102: recipe for target 'abbrev.o' failed
make[2]: Leaving directory '/home/buildbot/slaves/bot1name/matsl_cfg3/build/src'
make[2]: *** [abbrev.o] Error 1
GNUmakefile:98: recipe for target 'src' failed
make[1]: Leaving directory '/home/buildbot/slaves/bot1name/matsl_cfg3/build'
make[1]: *** [src] Error 2
program finished with exit code 2
----------------------------------------------------------------------
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta