* Re: Help: build emacs in cygwin (fwd)
@ 2007-03-08 11:27 Angelo Graziosi
2007-03-09 15:24 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Angelo Graziosi @ 2007-03-08 11:27 UTC (permalink / raw)
To: emacs-devel; +Cc: Eli Zaretskii
Regarding the 'MAKE' questions, I would suggest to try the Cygwin patched
version of make that accepts PATH in DOS style:
http://cygwin.com/ml/cygwin/2006-11/msg00490.html
If I remeber correcly those patches were accepted upstream.
Cheers,
Angelo.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Help: build emacs in cygwin (fwd)
2007-03-08 11:27 Help: build emacs in cygwin (fwd) Angelo Graziosi
@ 2007-03-09 15:24 ` Eli Zaretskii
2007-03-13 13:10 ` Help: build emacs in cygwin Angelo Graziosi
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2007-03-09 15:24 UTC (permalink / raw)
To: Angelo Graziosi; +Cc: emacs-devel
> Date: Thu, 8 Mar 2007 12:27:03 +0100 (MET)
> From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it>
> cc: Eli Zaretskii <eliz@gnu.org>
>
> http://cygwin.com/ml/cygwin/2006-11/msg00490.html
>
> If I remeber correcly those patches were accepted upstream.
Yes, they were.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Help: build emacs in cygwin
2007-03-09 15:24 ` Eli Zaretskii
@ 2007-03-13 13:10 ` Angelo Graziosi
2007-03-13 18:23 ` Harald Maier
0 siblings, 1 reply; 22+ messages in thread
From: Angelo Graziosi @ 2007-03-13 13:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
> Strange, that's the version that caused lots of trouble to Angelo
> Graziosi. Also, he reported problems with debug info generated by
> 3.4.4-2 (can you debug your binary?).
I confirm.
I have done a build with GCC-3.4.4 (that now is 3.4.4-3, not -2) using the
configure options described here
http://lists.gnu.org/archive/html/emacs-devel/2007-03/msg00722.html
(it differs from mine only because it does not uses XAW3D) but it segment
faults in a few seconds/minutes!
Every time I use GCC-3.4.4 the result is unstable. Instead GCC-4.0.3 gives
results very stable.
Cheers,
Angelo.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Help: build emacs in cygwin
2007-03-13 13:10 ` Help: build emacs in cygwin Angelo Graziosi
@ 2007-03-13 18:23 ` Harald Maier
2007-03-14 0:52 ` Angelo Graziosi
2007-03-14 1:31 ` djh
0 siblings, 2 replies; 22+ messages in thread
From: Harald Maier @ 2007-03-13 18:23 UTC (permalink / raw)
To: Angelo Graziosi; +Cc: Eli Zaretskii, emacs-devel
Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes:
> Eli Zaretskii wrote:
>
>> Strange, that's the version that caused lots of trouble to Angelo
>> Graziosi. Also, he reported problems with debug info generated by
>> 3.4.4-2 (can you debug your binary?).
>
> I confirm.
>
> I have done a build with GCC-3.4.4 (that now is 3.4.4-3, not -2) using the
> configure options described here
> http://lists.gnu.org/archive/html/emacs-devel/2007-03/msg00722.html
> (It differs from mine only because it does not uses XAW3D) but it segment
> faults in a few seconds/minutes!
>
> Every time I use GCC-3.4.4 the result is unstable. Instead GCC-4.0.3 gives
> results very stable.
Me too. An Cygwin-Emacs compiled with gcc-3.4.4 is unusable!
Especially, I saw lots of crashes by subprocess handling such as ssh
and with SQLi buffers.
Harald
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Help: build emacs in cygwin
2007-03-13 18:23 ` Harald Maier
@ 2007-03-14 0:52 ` Angelo Graziosi
2007-03-14 1:31 ` djh
1 sibling, 0 replies; 22+ messages in thread
From: Angelo Graziosi @ 2007-03-14 0:52 UTC (permalink / raw)
To: emacs-devel; +Cc: Eli Zaretskii, djh
Eli Zaretskii wrote:
>> From: "djh" <address@hidden>
>> Date: Tue, 13 Mar 2007 14:51:48 +0900
>>
>> No. I get the below results. Same as Angelo, but I think Angelo was
>> trying
>> to build a native w32 version and had pathname converstion problems.
> No, he was building a Cygwin binary, not a native w32 binary.
Obviously.
I never tried to build a native 32 binary.
I refer always to a pure Cygwin build.
Cheers,
Angelo.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Help: build emacs in cygwin
2007-03-13 18:23 ` Harald Maier
2007-03-14 0:52 ` Angelo Graziosi
@ 2007-03-14 1:31 ` djh
2007-03-14 7:41 ` Jason Rumney
2007-03-22 21:41 ` emacs snapshot tarball test build Angelo Graziosi
1 sibling, 2 replies; 22+ messages in thread
From: djh @ 2007-03-14 1:31 UTC (permalink / raw)
To: Harald Maier; +Cc: Eli Zaretskii, Angelo Graziosi, emacs-devel
I did not have the problems that Angelo had. (I do have crash problems, but almost exclusively when using ddskk, a skk based Japanese input method.).
I believe Angelo also had symbol problems, that is a lack of symbols for debugging.
I believe the problem is not the compiler, but the cygwin x-window implementation.
If if the compiler, then it has been fixed (my 3.4.4 shows an installed date of December 18, 2006).
I mainly have problems (crashes) when using a Japanese input method.
Which leads me more to believe that the problem is not the compiler but the cygwin x-window implementation.
> Me too. An Cygwin-Emacs compiled with gcc-3.4.4 is unusable!
> Especially, I saw lots of crashes by subprocess handling such as ssh
> and with SQLi buffers.
>
> Harald
I just downloaded and built the newest gcc, gcc (GCC) 4.1.3 20070312 (prerelease)
and compiled emacs with it successfully.
I still get:
$ gdb /bin/emacs.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r
Starting program: /bin/emacs.exe
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw-8.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXp-6.dll
Loaded symbols for /usr/X11R6/bin/cygXau-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
emacs: standard input is not a tty
Program exited with code 01.
-----
Which leads me to believe it is not a compiler problem.
Darel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Help: build emacs in cygwin
2007-03-14 1:31 ` djh
@ 2007-03-14 7:41 ` Jason Rumney
2007-03-22 21:41 ` emacs snapshot tarball test build Angelo Graziosi
1 sibling, 0 replies; 22+ messages in thread
From: Jason Rumney @ 2007-03-14 7:41 UTC (permalink / raw)
To: djh; +Cc: Eli Zaretskii, Harald Maier, emacs-devel, Angelo Graziosi
djh wrote:
> I mainly have problems (crashes) when using a Japanese input method.
> Which leads me more to believe that the problem is not the compiler but the cygwin x-window implementation.
>
I think there is a bug in the interaction between skk and some versions
of X and/or certain window managers. I've seen lockups and crashes on
GNU/Linux with certain combinations not involving Emacs or Cygwin.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs snapshot tarball test build
2007-03-14 1:31 ` djh
2007-03-14 7:41 ` Jason Rumney
@ 2007-03-22 21:41 ` Angelo Graziosi
2007-03-23 1:34 ` djh
2007-03-23 4:37 ` emacs snapshot tarball test build Richard Stallman
1 sibling, 2 replies; 22+ messages in thread
From: Angelo Graziosi @ 2007-03-22 21:41 UTC (permalink / raw)
To: djh; +Cc: emacs-devel
djh wrote:
> The only problem is shown below (and maybe it is not a real problem).
>
> --------
> make[1]: Leaving directory `/usr/src/emacs-tmp/emacs-22.0.95/leim'
> cd lib-src; make maybe-blessmail \
> MAKE='make' archlibdir='/libexec/emacs/22.0.95/i686-pc-cygwin'
> make[1]: Entering directory `/usr/src/emacs-tmp/emacs-22.0.95/lib-src'
> ../src/emacs -batch --no-site-file --multibyte -l
> /usr/src/emacs-tmp/emacs-22.0.95/lib-src/../lisp/mail/blessmail.el
> Fatal error (6)make[1]: *** [blessmail] Aborted (core dumped)
> make[1]: Leaving directory `/usr/src/emacs-tmp/emacs-22.0.95/lib-src'
> make: *** [blessmail] Error 2
> ------
This often happens boostraping Emacs on Cygwin.
Workaround: try to build in another nested directory.
Generally, a build with the above problem gives problems!
Cheers,
Angelo.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs snapshot tarball test build
2007-03-22 21:41 ` emacs snapshot tarball test build Angelo Graziosi
@ 2007-03-23 1:34 ` djh
2007-03-23 9:09 ` Angelo Graziosi
2007-03-23 14:04 ` Eli Zaretskii
2007-03-23 4:37 ` emacs snapshot tarball test build Richard Stallman
1 sibling, 2 replies; 22+ messages in thread
From: djh @ 2007-03-23 1:34 UTC (permalink / raw)
To: Angelo Graziosi; +Cc: djh, emacs-devel
Thanks Angelo. But, one shouldn't have to build in a specific directory, or guess about a directory structure, and this should be an easy thing to fix.
If it is a semi-hard coded (if should a thing code be) reference or assumption in a Makefile then it should be corrected in my opinion.
It would be good to know why "make" aborted on blessmail.el. It was reported as
"Fatal error (6)make[1]: *** [blessmail] Aborted (core dumped)" below.
> djh wrote:
> > The only problem is shown below (and maybe it is not a real problem).
> > --------
> > make[1]: Leaving directory `/usr/src/emacs-tmp/emacs-22.0.95/leim'
> > cd lib-src; make maybe-blessmail \
> > MAKE='make' archlibdir='/libexec/emacs/22.0.95/i686-pc-cygwin'
> > make[1]: Entering directory `/usr/src/emacs-tmp/emacs-22.0.95/lib-src'
> > ../src/emacs -batch --no-site-file --multibyte -l
> > /usr/src/emacs-tmp/emacs-22.0.95/lib-src/../lisp/mail/blessmail.el
> > Fatal error (6)make[1]: *** [blessmail] Aborted (core dumped)
> > make[1]: Leaving directory `/usr/src/emacs-tmp/emacs-22.0.95/lib-src'
> > make: *** [blessmail] Error 2
> > ------
>
>
> This often happens boostraping Emacs on Cygwin.
> Workaround: try to build in another nested directory.
> Generally, a build with the above problem gives problems!
>
> Cheers,
> Angelo.
Regards,
Darel Henman
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs snapshot tarball test build
2007-03-23 1:34 ` djh
@ 2007-03-23 9:09 ` Angelo Graziosi
2007-03-23 14:04 ` Eli Zaretskii
1 sibling, 0 replies; 22+ messages in thread
From: Angelo Graziosi @ 2007-03-23 9:09 UTC (permalink / raw)
To: djh; +Cc: emacs-devel
On Fri, 23 Mar 2007, djh wrote:
>
> Thanks Angelo. But, one shouldn't have to build in a specific directory, or guess about a directory structure, and this should be an easy thing to fix.
>
> If it is a semi-hard coded (if should a thing code be) reference or assumption in a Makefile then it should be corrected in my opinion.
>
> It would be good to know why "make" aborted on blessmail.el. It was reported as
> "Fatal error (6)make[1]: *** [blessmail] Aborted (core dumped)" below.
Boostrapping Emacs on Cygwin, one often has "Fatal error
(6)make[1]:..." not only at the end, when installing, with "blessmail",
but also when it starts to compile "el" files or after it has rebuilt the
final version of "emacs.exe".
Theste errors happen at random, without an evident logic.
Usually, changing the build directory (increasing the nested level) solve
the thing (same Emacs CVS source).
So correcting the Makefile left some doubts (but I can err).
Obviously, the bootstrap of the same CVS code on GNU/Linux Kubuntu does
not give any problem.
Cheers,
Angelo.
>
> > djh wrote:
> > > The only problem is shown below (and maybe it is not a real problem).
> > > --------
> > > make[1]: Leaving directory `/usr/src/emacs-tmp/emacs-22.0.95/leim'
> > > cd lib-src; make maybe-blessmail \
> > > MAKE='make' archlibdir='/libexec/emacs/22.0.95/i686-pc-cygwin'
> > > make[1]: Entering directory `/usr/src/emacs-tmp/emacs-22.0.95/lib-src'
> > > ../src/emacs -batch --no-site-file --multibyte -l
> > > /usr/src/emacs-tmp/emacs-22.0.95/lib-src/../lisp/mail/blessmail.el
> > > Fatal error (6)make[1]: *** [blessmail] Aborted (core dumped)
> > > make[1]: Leaving directory `/usr/src/emacs-tmp/emacs-22.0.95/lib-src'
> > > make: *** [blessmail] Error 2
> > > ------
> >
> >
> > This often happens boostraping Emacs on Cygwin.
> > Workaround: try to build in another nested directory.
> > Generally, a build with the above problem gives problems!
> >
> > Cheers,
> > Angelo.
>
> Regards,
> Darel Henman
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs snapshot tarball test build
2007-03-23 1:34 ` djh
2007-03-23 9:09 ` Angelo Graziosi
@ 2007-03-23 14:04 ` Eli Zaretskii
2007-04-04 11:32 ` Pretest 22.0.97 Angelo Graziosi
` (2 more replies)
1 sibling, 3 replies; 22+ messages in thread
From: Eli Zaretskii @ 2007-03-23 14:04 UTC (permalink / raw)
To: djh; +Cc: Angelo.Graziosi, henman, emacs-devel
> From: "djh" <henman@it.to-be.co.jp>
> Date: Fri, 23 Mar 2007 10:34:19 +0900
> Cc: djh <henman@it.to-be.co.jp>, emacs-devel@gnu.org
>
> It would be good to know why "make" aborted on blessmail.el. It was reported as
> "Fatal error (6)make[1]: *** [blessmail] Aborted (core dumped)" below.
It's not "make" who aborted, it's Emacs. "make" just printed a
human-readable description of why Emacs died.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs snapshot tarball test build
2007-03-22 21:41 ` emacs snapshot tarball test build Angelo Graziosi
2007-03-23 1:34 ` djh
@ 2007-03-23 4:37 ` Richard Stallman
2007-03-23 13:58 ` Eli Zaretskii
1 sibling, 1 reply; 22+ messages in thread
From: Richard Stallman @ 2007-03-23 4:37 UTC (permalink / raw)
To: Angelo Graziosi; +Cc: henman, emacs-devel
This often happens boostraping Emacs on Cygwin.
Workaround: try to build in another nested directory.
Is this documented in the installation instructions?
In etc/PROBLEMS?
If not, would someone like to add that info?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs snapshot tarball test build
2007-03-23 4:37 ` emacs snapshot tarball test build Richard Stallman
@ 2007-03-23 13:58 ` Eli Zaretskii
0 siblings, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2007-03-23 13:58 UTC (permalink / raw)
To: rms; +Cc: Angelo.Graziosi, henman, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 23 Mar 2007 00:37:11 -0400
> Cc: henman@it.to-be.co.jp, emacs-devel@gnu.org
>
> This often happens boostraping Emacs on Cygwin.
>
> Workaround: try to build in another nested directory.
>
> Is this documented in the installation instructions?
> In etc/PROBLEMS?
>
> If not, would someone like to add that info?
These are not workarounds that I'd recommend adding to PROBLEMS.
In general, if the problem only happens during bootstrap, and doesn't
have a good workarounds, I'd say let's ignore it. Most Emacs users
will never bootstrap.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Merging multitty
@ 2007-05-11 12:00 Kenichi Handa
2007-05-11 13:34 ` merging Unicode branch and availability of Windows binaries Drew Adams
0 siblings, 1 reply; 22+ messages in thread
From: Kenichi Handa @ 2007-05-11 12:00 UTC (permalink / raw)
To: David Kastrup; +Cc: karoly, emacs-devel, multi-tty, rms, jasonr
In article <867irf3cjo.fsf@lola.quinscape.zz>, David Kastrup <dak@gnu.org> writes:
> So yes, I am aware that multitty will likely destabilize the trunk and
> require work until the trunk is useful on all architectures again.
At least, merging unicode-2 doesn't make the trunk unuseful
for any architecture, so I think it must be the first. It
may cause some problem, but it is just because that part is
not yet tested by any of unicode-2 users. Once the problem
is reported, I think I can fix it quite soon.
Currently Miles is synchronizing unicode-2 to the trunk
periodically (great thanks for that effort). If we merge
multitty to the trunk at first, and make the trunk unuseful
for some architecture, unicode-2 branch will also be
unuseful for that architecture after Miles synchronization,
which I do want to avoid.
Unicode branch has been there for more than 5 years, and we
should think that it is a kind of big bugfix for the current
weird/complicated character handling.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 22+ messages in thread
* merging Unicode branch and availability of Windows binaries
2007-05-11 12:00 Merging multitty Kenichi Handa
@ 2007-05-11 13:34 ` Drew Adams
2007-05-14 14:16 ` Drew Adams
0 siblings, 1 reply; 22+ messages in thread
From: Drew Adams @ 2007-05-11 13:34 UTC (permalink / raw)
To: emacs-devel; +Cc: Lennart Borgman
Caveat: I haven't followed the merge thread closely, and I'm ignorant of
most of what you are discussing there.
Question: Regardless of what you decide about merging, will there be
available for users, somewhere, a Windows binary of the 22 release (as it is
before merge of the Unicode branch)? Until now, I've only found Windows
binaries of the latest CVS build, which, after the merge, would presumably
include Unicode.
I ask because I've had reports by an Icicles user on Emacs 23 (Unicode) that
Icicles key completion does not work with that version. I don't have a
Windows binary of 23, so I haven't been able to look at the problem. If
Emacs 23 treatment of keymaps or key bindings is very different, then
perhaps I'll need to start over, to implement key-completion differently.
(Or perhaps key completion will be impossible or unfeasible for the Unicode
version.)
I would like for Emacs users to continue to be able to find Windows binaries
of the stable Emacs 22, even after Emacs 23 is merged, and I would like,
myself, to be able to find a Windows binary of Emacs 23 (before or after the
merge), to be able to look into the Icicles key-completion problems. Until
now, I've been using Lennart's vanilla Emacs 22 builds on Windows, but I
don't know what Lennart will make available after the merge. My question is,
will I be able to find binaries of both Emacs 22 (without Unicode) and 23
(with Unicode) after the merge? Will the former be available from GNU, for
instance, and the latter from Lennart? Or both from Lennart?
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: merging Unicode branch and availability of Windows binaries
2007-05-11 13:34 ` merging Unicode branch and availability of Windows binaries Drew Adams
@ 2007-05-14 14:16 ` Drew Adams
2007-05-14 14:30 ` David Kastrup
0 siblings, 1 reply; 22+ messages in thread
From: Drew Adams @ 2007-05-14 14:16 UTC (permalink / raw)
To: emacs-devel; +Cc: Lennart Borgman
Resending.
> Sent: Friday, May 11, 2007 6:35 AM
> Caveat: I haven't followed the merge thread closely, and I'm ignorant of
> most of what you are discussing there.
>
> Question: Regardless of what you decide about merging, will there be
> available for users, somewhere, a Windows binary of the 22
> release (as it is
> before merge of the Unicode branch)? Until now, I've only found Windows
> binaries of the latest CVS build, which, after the merge, would presumably
> include Unicode.
>
> I ask because I've had reports by an Icicles user on Emacs 23
> (Unicode) that
> Icicles key completion does not work with that version. I don't have a
> Windows binary of 23, so I haven't been able to look at the problem. If
> Emacs 23 treatment of keymaps or key bindings is very different, then
> perhaps I'll need to start over, to implement key-completion differently.
> (Or perhaps key completion will be impossible or unfeasible for
> the Unicode
> version.)
>
> I would like for Emacs users to continue to be able to find
> Windows binaries
> of the stable Emacs 22, even after Emacs 23 is merged, and I would like,
> myself, to be able to find a Windows binary of Emacs 23 (before
> or after the
> merge), to be able to look into the Icicles key-completion problems. Until
> now, I've been using Lennart's vanilla Emacs 22 builds on Windows, but I
> don't know what Lennart will make available after the merge. My
> question is,
> will I be able to find binaries of both Emacs 22 (without Unicode) and 23
> (with Unicode) after the merge? Will the former be available from GNU, for
> instance, and the latter from Lennart? Or both from Lennart?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: merging Unicode branch and availability of Windows binaries
2007-05-14 14:16 ` Drew Adams
@ 2007-05-14 14:30 ` David Kastrup
2007-05-14 15:05 ` Drew Adams
0 siblings, 1 reply; 22+ messages in thread
From: David Kastrup @ 2007-05-14 14:30 UTC (permalink / raw)
To: Drew Adams; +Cc: Lennart Borgman, emacs-devel
"Drew Adams" <drew.adams@oracle.com> writes:
> Resending.
Why?
>> Sent: Friday, May 11, 2007 6:35 AM
>> Caveat: I haven't followed the merge thread closely, and I'm
>> ignorant of most of what you are discussing there.
If it is important enough for you to resend, wouldn't it be important
enough to read the thread?
>> Question: Regardless of what you decide about merging, will there
>> be available for users, somewhere, a Windows binary of the 22
>> release (as it is before merge of the Unicode branch)? Until now,
>> I've only found Windows binaries of the latest CVS build, which,
>> after the merge, would presumably include Unicode.
The EMACS_22_BASE will, obviously, not be merged with unicode-2, and
that is what Emacs 22.1 will be released from "real soon now"(TM).
--
David Kastrup
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: merging Unicode branch and availability of Windows binaries
2007-05-14 14:30 ` David Kastrup
@ 2007-05-14 15:05 ` Drew Adams
2007-05-14 17:32 ` David Kastrup
0 siblings, 1 reply; 22+ messages in thread
From: Drew Adams @ 2007-05-14 15:05 UTC (permalink / raw)
To: emacs-devel, Lennart Borgman
> > Resending.
> Why?
Because there was no reply to my question.
> >> Caveat: I haven't followed the merge thread closely, and I'm
> >> ignorant of most of what you are discussing there.
>
> If it is important enough for you to resend, wouldn't it be important
> enough to read the thread?
I did read it. I did not find my question answered in it, so I posed it
explicitly. Do you have the answer, or do you just want to hassle?
> >> Question: Regardless of what you decide about merging, will there
> >> be available for users, somewhere, a Windows binary of the 22
> >> release (as it is before merge of the Unicode branch)? Until now,
> >> I've only found Windows binaries of the latest CVS build, which,
> >> after the merge, would presumably include Unicode.
>
> The EMACS_22_BASE will, obviously, not be merged with unicode-2, and
> that is what Emacs 22.1 will be released from "real soon now"(TM).
I asked about Windows binaries. Where will one be able to find a Windows
binary of Emacs 22?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: merging Unicode branch and availability of Windows binaries
2007-05-14 15:05 ` Drew Adams
@ 2007-05-14 17:32 ` David Kastrup
0 siblings, 0 replies; 22+ messages in thread
From: David Kastrup @ 2007-05-14 17:32 UTC (permalink / raw)
To: Drew Adams; +Cc: Lennart Borgman, emacs-devel
"Drew Adams" <drew.adams@oracle.com> writes:
> Because there was no reply to my question.
>
>> >> Caveat: I haven't followed the merge thread closely, and I'm
>> >> ignorant of most of what you are discussing there.
>>
>> If it is important enough for you to resend, wouldn't it be important
>> enough to read the thread?
>
> I did read it. I did not find my question answered in it, so I posed it
> explicitly. Do you have the answer, or do you just want to hassle?
>
>> >> Question: Regardless of what you decide about merging, will there
>> >> be available for users, somewhere, a Windows binary of the 22
>> >> release (as it is before merge of the Unicode branch)? Until now,
>> >> I've only found Windows binaries of the latest CVS build, which,
>> >> after the merge, would presumably include Unicode.
>>
>> The EMACS_22_BASE will, obviously, not be merged with unicode-2, and
>> that is what Emacs 22.1 will be released from "real soon now"(TM).
>
> I asked about Windows binaries. Where will one be able to find a Windows
> binary of Emacs 22?
Same places where you now find Emacs 21 binaries.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2007-05-14 21:13 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-08 11:27 Help: build emacs in cygwin (fwd) Angelo Graziosi
2007-03-09 15:24 ` Eli Zaretskii
2007-03-13 13:10 ` Help: build emacs in cygwin Angelo Graziosi
2007-03-13 18:23 ` Harald Maier
2007-03-14 0:52 ` Angelo Graziosi
2007-03-14 1:31 ` djh
2007-03-14 7:41 ` Jason Rumney
2007-03-22 21:41 ` emacs snapshot tarball test build Angelo Graziosi
2007-03-23 1:34 ` djh
2007-03-23 9:09 ` Angelo Graziosi
2007-03-23 14:04 ` Eli Zaretskii
2007-04-04 11:32 ` Pretest 22.0.97 Angelo Graziosi
2007-04-13 11:47 ` Build failure on Cygwin Angelo Graziosi
2007-05-14 20:56 ` merging Unicode branch and availability of Windows binaries Angelo Graziosi
2007-05-14 21:13 ` Drew Adams
2007-03-23 4:37 ` emacs snapshot tarball test build Richard Stallman
2007-03-23 13:58 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2007-05-11 12:00 Merging multitty Kenichi Handa
2007-05-11 13:34 ` merging Unicode branch and availability of Windows binaries Drew Adams
2007-05-14 14:16 ` Drew Adams
2007-05-14 14:30 ` David Kastrup
2007-05-14 15:05 ` Drew Adams
2007-05-14 17:32 ` David Kastrup
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.