Re: Next pretest

Re: Next pretest

[A. Soare]

> On Jan 24, 2010, at 8:34 AM, David De La Harpe Golden wrote:
> 
> > alin.s wrote:
> >> Tabs are also ready. 
> > Um. What sort of tabs? 
> 
> Don't forget the ~5-year-old elisp implementation tabbar.el.   :-)
> 
> It sounds like you have another tab implementation for one of ~6 UI systems where we'd like to see it.  I look forward to seeing it, but mentioning it as if it would be part of a pretest in less than a week seems confusing at best.
> 

Tabs have nothing in common with tabbar.el. I have never used tabbar.el, but I remember to have seen it once loaded by a program like w3m-emacs or so.

Maybe tabs for console look a little identical, but apart from this, I cannot say anything, because I do not know tabbar.el.





____________________________________________________

Dépêchez-vous : plus que quelques jours pour envoyer vos voeux sur http://carte-de-voeux.voila.fr

Next pretest

[Stefan Monnier]

The next pretest will be cut next Wednesday.

It's probably going to be the last pretest, so after that Tuesday, no more
commits will be accepted on emacs-24 unless they fix a very urgent and
important bug.


        Stefan

next pretest

[Glenn Morris]

Let's have the next pretest this Friday.
If you need more time, please ask.

(Slightly surprised to have seen no Org changes since April.)

Re: next pretest

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 11 Aug 2014 11:43:23 -0400
> 
> (Slightly surprised to have seen no Org changes since April.)

They save them for the last moment of the last pretest.

Re: next pretest

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Glenn Morris <rgm@gnu.org>
>> Date: Mon, 11 Aug 2014 11:43:23 -0400
>> 
>> (Slightly surprised to have seen no Org changes since April.)
>
> They save them for the last moment of the last pretest.

That may be true, since I don't know when is "the last pretest".

Merging regularily is less a priority than fixing bugs in the
stable branch of Org, which gets a lot of users.

Also, I would appreciate help on merging Org into Emacs.

Anyone?

PS: I'm right now on holiday until August, 17th.

-- 
 Bastien

Re: next pretest

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: Glenn Morris <rgm@gnu.org>,  emacs-devel@gnu.org
> Date: Tue, 12 Aug 2014 10:49:44 +0200
> 
> Also, I would appreciate help on merging Org into Emacs.

Please elaborate: what kind of help do you need?

Re: next pretest

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bastien <bzg@gnu.org>
>> Cc: Glenn Morris <rgm@gnu.org>,  emacs-devel@gnu.org
>> Date: Tue, 12 Aug 2014 10:49:44 +0200
>> 
>> Also, I would appreciate help on merging Org into Emacs.
>
> Please elaborate: what kind of help do you need?

I need someone to take care of the merge.

-- 
 Bastien

Re: next pretest

[Glenn Morris]

Bastien wrote:

> That may be true, since I don't know when is "the last pretest".

It's several months after various announcements of increasing severity.
A week after the announcement of a release candidate.
Pretty standard procedure.

> Also, I would appreciate help on merging Org into Emacs.

I think I've suggested before you that you ask for help with this on the
Org mailing list, which seems to have an extensive development community.

Re: next pretest

[Bastien]

Glenn Morris <rgm@gnu.org> writes:

> Bastien wrote:
>
>> That may be true, since I don't know when is "the last pretest".
>
> It's several months after various announcements of increasing severity.
> A week after the announcement of a release candidate.
> Pretty standard procedure.

Well, it's a matter of timing.  Fixing bugs in the stable Org branch
seems preferrable than merging Org with Emacs, because I suspect the
stable Org branch has more testers than emacs-24.

>> Also, I would appreciate help on merging Org into Emacs.
>
> I think I've suggested before you that you ask for help with this on the
> Org mailing list, which seems to have an extensive development community.

I did that already, I will do it again.

-- 
 Bastien

Re: next pretest

[Bastien]

Glenn Morris <rgm@gnu.org> writes:

> (Slightly surprised to have seen no Org changes since April.)

I took over maintainership (again) in May and I have been busy
fixing longstanding bugs since then.

-- 
 Bastien

next pretest

[Glenn Morris]

Let's have another pretest, say this Friday?
If you need more time for some reason, please ask.

next pretest

[Glenn Morris]

Let's have another pretest on Monday.
If people feel they need more time, it could be delayed by a few days.

Next pretest

[Chong Yidong]

I'd like to make the 24.2.91 pretest next Friday, December 14.  Please
plan your commits accordingly.  Thanks.

Next pretest

[Chong Yidong]

I would like to make the next pretest 24.0.96, next Friday (2012-04-27).
Please plan your commits accordingly.

Could someone who has a SELinux setup please test Glenn's proposed fix
in Bug#11245?  There are a handful of other regressions being worked on,
but if they get fixed and no serious problems crop up post-24.0.96, I
think we can have the release candidate next.

Re: Next pretest

[Glenn Morris]

Chong Yidong wrote:

> Could someone who has a SELinux setup please test Glenn's proposed fix
> in Bug#11245?

Tested it myself; works for me; committed.

Next pretest

[Chong Yidong]

I intend to make the 24.0.94 pretest this Sunday, February 26.  Please
plan your commits accordingly.  Thanks.

Next pretest

[Chong Yidong]

Since there were a couple of problems with the last pretest, I'll roll
the 23.2.93 pretest a little earlier: Monday, 31 Jan.  Please plan
accordingly, thanks.

There are several important or serious bugs that we should fix before
release.  Unfortunately, several of them are platform dependent.  Any
help with these would be greatly appreciated.


C-g not working on NetBSD
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6649

Building on HP-UX
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6811

Slowdown after 20+ `compile's
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7069

crashes on Solaris 11/SPARC
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7163

C++ infloop
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7722
(I've asked Alan to look at this, but any help diagnosing the problem
would be welcome.)


If you see any other bug that you think should be a release blocker,
please point it out.

Re: Next pretest

[Glenn Morris]

Chong Yidong wrote:

> If you see any other bug that you think should be a release blocker,
> please point it out.

Not terribly critical, but maybe the configure of Xaw3d should be improved?

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7642#23

Re: Next pretest

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Chong Yidong wrote:
>
>> If you see any other bug that you think should be a release blocker,
>> please point it out.
>
> Not terribly critical, but maybe the configure of Xaw3d should be improved?
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7642#23

I am not sure it's really OK for a system to have the include file and
not the header, but OK.  I've added the configure check for the Xaw3d
library back in.

Re: Next pretest

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

> If you see any other bug that you think should be a release blocker,
> please point it out.

Can we uncomment the #define NO_ARG_ARRAY line in src/s/intel386.h?
We got rid of NO_ARG_ARRAY in emacs-24, that file is the only one that
still enables it in 23.3.  This is just a bug waiting to happen as
compilers get smarter...

Re: Next pretest

[Chong Yidong]

Dan Nicolaescu <dann@gnu.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> If you see any other bug that you think should be a release blocker,
>> please point it out.
>
> Can we uncomment the #define NO_ARG_ARRAY line in src/s/intel386.h?
> We got rid of NO_ARG_ARRAY in emacs-24, that file is the only one that
> still enables it in 23.3.  This is just a bug waiting to happen as
> compilers get smarter...

Since no problems have been reported since you removed NO_ARG_ARRAY on
the trunk in April, I guess it should be safe.  And it would fix
Bug#7186.  Go ahead.

Re: Next pretest

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Can we uncomment the #define NO_ARG_ARRAY line in src/s/intel386.h?
>> We got rid of NO_ARG_ARRAY in emacs-24, that file is the only one that
>> still enables it in 23.3.  This is just a bug waiting to happen as
>> compilers get smarter...

I've just committed the suggested change to the branch.

Next pretest

[Chong Yidong]

I'd like to make the next pretest, 23.2.92, on Friday Jan 14.  Please
plan your commits accordingly, thanks.

The emacs-23 branch is shaping up well, and hopefully we'll go into hard
freeze (regressions vs 23.2 only) beginning with the pretest after that
(23.2.93).  This will mostly depend on how quickly rmail-mime, and a few
remaining pieces, stabilize.

Next pretest

[Chong Yidong]

I would like to make the 23.2.91 pretest this Friday, Dec 10.  Please
plan your commits accordingly.  Thanks.

Next pretest

[Sean Sieger]

Christop, will you look at the libxpm-3.5.8 file in

ftp://ftp.gnu.org/gnu/emacs/windows please?

I need to lose a lot of what's in there and maybe you can tell me what
can go.  When we're done, I'll get rid of that one and also upload a
current libXpm with the 23.1.96 presest MS Windows binaries Monday.

Re: Next pretest

[Sean Sieger]

Sean Sieger <sean.sieger@gmail.com> writes:

    Christop, will you look at the libxpm-3.5.8 file in

Sorry, Christof.

Re: Next pretest

[Jason Rumney]

Sean Sieger <sean.sieger@gmail.com> writes:

> Christop, will you look at the libxpm-3.5.8 file in
>
> ftp://ftp.gnu.org/gnu/emacs/windows please?

I was emailed today about a new file that has appeared in that directory.
Files that are not part of a release should be on alpha.gnu.org
(uploaded into /incoming/alpha, not /incoming/ftp)

Re: Next pretest

[Angelo Graziosi]

Chong Yidong wrote:
> In the future, please send patches to the bug tracker, so that they do
> not get lost.

> If the
> latter, the patch should go in the trunk.

Ken Brown wrote:
> Nevertheless, it's fine with me if you apply it to the trunk.

After 24 hours, I think we have lost the patches even this time (the 
fourth)... :(

Ciao,
Angelo.

Next pretest

[Chong Yidong]

I plan to make the 23.1.96 pretest next Monday, April 19.

The CC mode changes have been rolled back on the branch.  Because these
changes are taking a long time to debug (Bug#5570), they'll be
postphoned till after 23.2.  (Thanks to Alan for doing this unpleasant
work.)  For everyone using the branch, please keep an eye out for any CC
mode regressions wrt Emacs 23.1; there shouldn't be any now.

CC mode in the trunk remains unreverted, so if everyone using the trunk
can keep an eye out for a reproducible test case, it would be greatly
appreciated.

Re: Next pretest

[Christoph]

On 4/13/2010 9:30 AM, Chong Yidong wrote:
> I plan to make the 23.1.96 pretest next Monday, April 19.
>    

Can anyone confirm (and fix) bug #5928 before this next pretest? This 
leads to annoying side effects on some Windows systems. I have a patch 
included in the bug report.

Thanks.

Christoph

Re: Next pretest

[Juri Linkov]

> I plan to make the 23.1.96 pretest next Monday, April 19.

There is a patch in

http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00691.html

I see neither this patch installed nor a bug reported to bug-gnu-emacs.

It seems it should be installed to emacs-23?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Next pretest

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> There is a patch in
>
> http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00691.html
>
> I see neither this patch installed nor a bug reported to bug-gnu-emacs.
>
> It seems it should be installed to emacs-23?

Yes, it's a regression.  Thanks for pointing this out, as I'd missed
this thread.  The patch is now installed.

Re: Next pretest

[Ken Brown]

On 4/13/2010 11:30 AM, Chong Yidong wrote:
> I plan to make the 23.1.96 pretest next Monday, April 19.

There's still a pending Cygwin patch that I proposed a while ago:

   http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg01128.html

Could you apply that?

Thanks.

Ken

Re: Next pretest

[Chong Yidong]

Ken Brown <kbrown@cornell.edu> writes:

> On 4/13/2010 11:30 AM, Chong Yidong wrote:
>> I plan to make the 23.1.96 pretest next Monday, April 19.
>
> There's still a pending Cygwin patch that I proposed a while ago:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg01128.html
>
> Could you apply that?

In the future, please send patches to the bug tracker, so that they do
not get lost.  Thanks.

In the previous email, you said

> Even though Dave Korn's advice about libraries turned out to be
> irrelevant for this issue, I still think it would be wise to follow
> it.  The attached patch accomplishes this.

Could you explain what you mean by "wise"?  Does the patch fix an actual
bug (e.g. inability to compile), or is it just for cleanliness?  If the
latter, the patch should go in the trunk.

Re: Next pretest

[Ken Brown]

On 4/14/2010 6:51 PM, Chong Yidong wrote:
> Ken Brown<kbrown@cornell.edu>  writes:
>
>> On 4/13/2010 11:30 AM, Chong Yidong wrote:
>>> I plan to make the 23.1.96 pretest next Monday, April 19.
>>
>> There's still a pending Cygwin patch that I proposed a while ago:
>>
>>    http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg01128.html
>>
>> Could you apply that?
>
> In the future, please send patches to the bug tracker, so that they do
> not get lost.  Thanks.

OK, I'll do that from now on.

> In the previous email, you said
>
>> Even though Dave Korn's advice about libraries turned out to be
>> irrelevant for this issue, I still think it would be wise to follow
>> it.  The attached patch accomplishes this.
>
> Could you explain what you mean by "wise"?  Does the patch fix an actual
> bug (e.g. inability to compile), or is it just for cleanliness?  If the
> latter, the patch should go in the trunk.

I'm not aware of an actual bug.  But Dave Korn is one of the gcc 
developers as well as one of the Cygwin developers, and he said it could 
cause trouble.  Nevertheless, it's fine with me if you apply it to the 
trunk.

Thanks.

Ken

Re: Next pretest

[Chong Yidong]

Ken Brown <kbrown@cornell.edu> writes:

> I'm not aware of an actual bug.  But Dave Korn is one of the gcc
> developers as well as one of the Cygwin developers, and he said it
> could cause trouble.  Nevertheless, it's fine with me if you apply it
> to the trunk.

I've applied it to the trunk.

Re: Next pretest

[Sean Sieger]

    I plan to make the 23.1.96 pretest next Monday, April 19.

Sorry about broaching this at the eleventh hour---does anyone find it
curious that after I did a MS Windows build,

configure [blah, blah]

make

[no `make info' as the info files are already intact in info/ of the
pretest tarball]

make install

and zipped it up, using

makedist

that the info files, as Drew immediately pointed out, were mysteriously
absent?  I don't think this was ever fully addressed.  I recently used
the same build method, plus a `make info' as it was the trunk that I
built, and the info files remained intact.

I would like to think I'll be ready to build and publish the pretest on
Monday night.

Re: Next pretest

[Christoph]

On 4/15/2010 1:13 PM, Sean Sieger wrote:
> Sorry about broaching this at the eleventh hour---does anyone find it
> curious that after I did a MS Windows build, [...]
> that the info files, as Drew immediately pointed out, were mysteriously
> absent?
>    

Yes, very curious indeed. Have you tried reproducing this by building 
from a fresh tarball?

Re: Next pretest

[Sean Sieger]

    Yes, very curious indeed. Have you tried reproducing this by building
    from a fresh tarball?

I ran out of time yesterday and hope to get to it this weekend.

Next pretest

[Chong Yidong]

I would like to make the next pretest release (23.1.95) this coming
Friday, the 2nd of April.  Let me know if there are no objections, or
any problems that you'd like to see addressed.

RE: Next pretest

[Drew Adams]

> I would like to make the next pretest release (23.1.95) this coming
> Friday, the 2nd of April.  Let me know if there are no objections, or
> any problems that you'd like to see addressed.

How about a Windows binary?

You published 23.1.93 without a binary, giving this as excuse:

> The latest pretest has a couple of serious bugs on Windows, 
> so IMO there is little point making the binary for it.

But you reassured us that you would publish again soon, with those Windows bugs
fixed:

> > Fair enough. Is there a point in publishing a new release 
> > without testing on Windows, in particular, testing the fixes
> > for those serious bugs?
> >
> > Or did you plan to publish another pretest with the bugs fixed?
> > That would be good (normal). That wasn't clear from your mails.
> 
> There should be at least two more pretests before the 23.2 release.

However, you published 23.1.94 without a Windows binary (giving no reason). You
said this on 3/12, but nothing came of it:

> Lennart is having technical problems with the box he compiles 
> on. If he fixes those, I will upload his binaries to alpha.gnu.org.

How many Windows users tested that 94 pretest, which supposedly fixed serious
Windows bugs introduced by pretest 93? Gettin any pretest feedback at all from
Windows users, besides build reports?

There was no 23.1.92 binary either. The last published Windows binary was for
23.1.91, 2010/01/03.

You have lamented the fact that no one has volunteered to build Windows
binaries, but the same day (3/12), Sean Sieger volunteered:

> I've been building and using the previous pretest as well as 
> bzr builds daily for two weeks and everything seems to be
> going well. If it's okay with you, I would like to volunteer
> to compile the Windows binaries and get them (pretests,
> releases and say weekly bzr builds) uploaded to alph.gnu.org
> and ftp.gnu.org.
> 
> In those two weeks I've been careful to read Jason's
> responses to Eli's requests and the _Information for
> Maintainers of GNU Software_ Section 9, `Distributions'.
> 
> There's a couple of questions that I have for Jason before
> I do, but I would like to volunteer to compile the binaries
> for Windows and keep the windows directories current with them.

Whatever became of that? Wasn't it "okay with you" that Sean build and post
binaries?

Re: Next pretest

[Lennart Borgman]

On Sun, Mar 28, 2010 at 9:59 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> I would like to make the next pretest release (23.1.95) this coming
>> Friday, the 2nd of April.  Let me know if there are no objections, or
>> any problems that you'd like to see addressed.
>
> How about a Windows binary?


I will be away. However I could perhaps upload something now to my
site instead. How about that?

BTW I think my checkout is a trunk checkout. How do I get a checkout
from the pretest branch from that? (I am using Launchpad.)

RE: Next pretest

[Drew Adams]

> >> I would like to make the next pretest release (23.1.95) this coming
> >> Friday, the 2nd of April.  Let me know if there are no 
> >> objections, or any problems that you'd like to see addressed.
> >
> > How about a Windows binary?
> 
> I will be away. However I could perhaps upload something now to my
> site instead. How about that?

Every little bit helps, of course. Thanks, Lennart.

However, that's not the real solution. Pretest testers will (and should) look
for Windows binary pretests at the GNU location created for them:

http://alpha.gnu.org/gnu/emacs/pretest/windows/

That's the only purpose of that directory, as stated in the README.

And pretest binaries should correspond to the pretest source code exactly.
Otherwise, we can be comparing apples and oranges (which can mean confusion and
more work for everyone involved).

And `report-emacs-bug' should correctly address the pretest mailing list (that
didn't happen the last time you made a binary available informally for pretest
testing).

So yes, thank you - that will help. But whatever happened to the Windows builds
volunteered by Sean Sieger?

Re: Next pretest

[Lennart Borgman]

On Sun, Mar 28, 2010 at 10:36 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >> I would like to make the next pretest release (23.1.95) this coming
>> >> Friday, the 2nd of April.  Let me know if there are no
>> >> objections, or any problems that you'd like to see addressed.
>> >
>> > How about a Windows binary?
>>
>> I will be away. However I could perhaps upload something now to my
>> site instead. How about that?
>
> Every little bit helps, of course. Thanks, Lennart.
>
...
> And pretest binaries should correspond to the pretest source code exactly.
> Otherwise, we can be comparing apples and oranges (which can mean confusion and
> more work for everyone involved).


Thanks. I am including a file with something like this now:

;; bzr checkout info for Emacs unpatched version
(defconst emacs-trunk-bzr-revision-id
"schwab@linux-m68k.org-20100321115749-axlxbdz2vt3sdbf6")
(defconst emacs-trunk-bzr-revno 99712)
(defconst emacs-trunk-bzr-date "2010-03-21 12:57:49 +0100")
(defconst emacs-trunk-bzr-branch-nick "trunk")

I suggested that should be recommended in the build process and
included in bug reports, but I got no responce.


> And `report-emacs-bug' should correctly address the pretest mailing list (that
> didn't happen the last time you made a binary available informally for pretest
> testing).


I have forgotten. Was I using the wrong branch, or?

Re: Next pretest

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sun, 28 Mar 2010 22:48:22 +0200
> Cc: Chong Yidong <cyd@stupidchicken.com>, Sean Sieger <sean.sieger@gmail.com>,
> 	emacs-devel@gnu.org
> 
> > And pretest binaries should correspond to the pretest source code exactly.
> > Otherwise, we can be comparing apples and oranges (which can mean confusion and
> > more work for everyone involved).
> 
> 
> Thanks. I am including a file with something like this now:
> 
> ;; bzr checkout info for Emacs unpatched version
> (defconst emacs-trunk-bzr-revision-id
> "schwab@linux-m68k.org-20100321115749-axlxbdz2vt3sdbf6")
> (defconst emacs-trunk-bzr-revno 99712)
> (defconst emacs-trunk-bzr-date "2010-03-21 12:57:49 +0100")
> (defconst emacs-trunk-bzr-branch-nick "trunk")

This is a trunk checkout, whereas Drew (see above) wants a pretest
binary, which should be built from the emacs-23 branch.

Re: Next pretest

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    This is a trunk checkout, whereas Drew (see above) wants a pretest
    binary, which should be built from the emacs-23 branch.

I'll keep trying to get the 23.1.94 binary uploaded and hope that by
Friday I'll be able to upload the 23.1.95 pretest.

Re: Next pretest

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Mon, 29 Mar 2010 11:41:40 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>     This is a trunk checkout, whereas Drew (see above) wants a pretest
>     binary, which should be built from the emacs-23 branch.
> 
> I'll keep trying to get the 23.1.94 binary uploaded and hope that by
> Friday I'll be able to upload the 23.1.95 pretest.

Thank you for your efforts.

Re: Next pretest

[Christoph]

On 3/28/2010 2:18 PM, Lennart Borgman wrote:
> On Sun, Mar 28, 2010 at 9:59 PM, Drew Adams<drew.adams@oracle.com>  wrote:
>    
>>> I would like to make the next pretest release (23.1.95) this coming
>>> Friday, the 2nd of April.  Let me know if there are no objections, or
>>> any problems that you'd like to see addressed.
>>>        
>> How about a Windows binary?
>>      
> I will be away. However I could perhaps upload something now to my
> site instead. How about that?
>    

I can build the Windows binaries for the pretest and upload them to the 
site.

I will have a look at the documentation tonight and see if I need some 
help for this the first time.

Just let me know if you want me to do this.

Christoph

Re: Next pretest

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> You have lamented the fact that no one has volunteered to build Windows
> binaries, but the same day (3/12), Sean Sieger volunteered:
>
>> I've been building and using the previous pretest as well as
>> bzr builds daily for two weeks and everything seems to be
>> going well. If it's okay with you, I would like to volunteer
>> to compile the Windows binaries and get them (pretests,
>> releases and say weekly bzr builds) uploaded to alph.gnu.org
>> and ftp.gnu.org.

> Whatever became of that? Wasn't it "okay with you" that Sean build and
> post binaries?

The problem of Windows binaries availability is on my radar, and we have
been working on it.  Sean has been having extensive problems uploading
his binaries, which we are currently trying to resolve with the FSF
sysadmins.

RE: Next pretest

[Drew Adams]

> The problem of Windows binaries availability is on my radar, 
> and we have been working on it.  Sean has been having
> extensive problems uploading his binaries, which we are
> currently trying to resolve with the FSF sysadmins.

That's good to hear. Thanks for the progress report and thanks for working on
this.

Re: Next pretest

[Glenn Morris]

Chong Yidong wrote:

> any problems that you'd like to see addressed.

It would be good to deal with the six remaining "serious" bugs:

http://debbugs.gnu.org/severity:serious

2056 is NS-only, but seems to bother a lot of people

2503 is the Windows version of the same, maybe it is not as widespread
     or really "serious"

3347 I don't know

4431 message versus mail mode is hopefully better now, and perhaps is
     already as good is it is going to get

4656 Personally I think we should perhaps just remove many of these
     files, especially test.py

5162 probably was fixed by Andreas's change (note does not apply to
     Windows), or at least is no longer "serious"

Re: Next pretest

[Leo]

On 2010-03-29 19:33 +0100, Glenn Morris wrote:
> 2056 is NS-only, but seems to bother a lot of people
>
> 2503 is the Windows version of the same, maybe it is not as widespread
>      or really "serious"

The Emacs mac-port has no such bug maybe something can be taken from
there.

Leo

Re: Next pretest

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> 4431 message versus mail mode is hopefully better now, and perhaps is
>      already as good is it is going to get

This is pretty much done.  I've finished the necessary documentation
changes over the weekend, and any remaining bugs can be dealt with on a
case by case basis.  I'll close this bug.

> 4656 Personally I think we should perhaps just remove many of these
>      files, especially test.py

I've just fixed this, mostly.  Discussion about what to do with the
remaining ~25 line snippet unit test files, copyright-wise, can go into
the thread for that bug.  Since the tests are not distributed with the
tarball anyway, I'm downgrading the severity to "normal".

> 5162 probably was fixed by Andreas's change (note does not apply to
>      Windows), or at least is no longer "serious"

I'll check, and comment on the bug.

Re: Next pretest

[Glenn Morris]

Chong Yidong wrote:

> I've just fixed this, mostly.  Discussion about what to do with the
> remaining ~25 line snippet unit test files, copyright-wise, can go into
> the thread for that bug.  Since the tests are not distributed with the
> tarball anyway, I'm downgrading the severity to "normal".

Oh, sorry; for some reason I thought "tests/" was in the tarfile.
Thanks.

Next pretest

[Chong Yidong]

I intend to roll the 23.1.92 pretest this Friday, the 29th.  If you come
across any problems that would delay the pretest, please let me know.

Re: Next pretest

[alin.s]

Tabs are also ready. For the console it's completely finished; for GTK I
have to make the latests modifications. For Lesstif and Athena I just found
some notebook widgets, and have to learn how to use them.


Alin.



Chong Yidong wrote:
> 
> I intend to roll the 23.1.92 pretest this Friday, the 29th.  If you come
> across any problems that would delay the pretest, please let me know.
> 
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/Next-pretest-tp27295593p27296016.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Next pretest

[David De La Harpe Golden]

alin.s wrote:
> 
> Tabs are also ready. For the console it's completely finished; for GTK I
> have to make the latests modifications. For Lesstif and Athena I just found
> some notebook widgets, and have to learn how to use them.
> 


Um. What sort of tabs?  Last time I tuned in (some time ago), people had 
very different ideas about how tabs should work.

For my part, I presently have a half-formed notion they should be 
another dimension for emacs window splitting along with horizontal and 
vertical, and therefore an aspect of window configurations.  Notably, I 
don't have any working code though.

Another option which I looked into at one stage was toplevel-only tabs 
that collected and switched between whole emacs frames. i.e. tabs 
"outside" frames.  The gtk+ notebook container widget model was 
particular suitable for that approach IIRC, as it was sort of emulating 
a tabbed window manager internal to gtk+, and gave you drag-drop and 
rearrangement for "free", but I eventually thought the window splitting 
model was more emacsy and general.

The one thing I really don't like is the idea of tabs-as-list-of-buffers 
- simply doesn't scale well to even my typical open buffer count (10s 
rather than 100s.), and is a waste of what could be a more versatile ui 
feature for the likes of IDE-type modes.

Or maybe you meant buffer-embedded emacs tab/notebook widgets, an 
entirely different matter and independent of the other kind of
tabbing.

Re: Next pretest

[David De La Harpe Golden]

David De La Harpe Golden wrote:

> For my part, I presently have a half-formed notion they should be 
> another dimension for emacs window splitting 

> Another option which I looked into at one stage was toplevel-only tabs 
> that collected and switched between whole emacs frames. i.e. tabs 
> "outside" frames.

(well, come to think of those two aren't actually mutually exclusive, 
but perhaps potentially confusing if both present)

And there's also the "tabbar as singular native widget" option
like the toolbar and menubar, with potentially mode-dependent 
programmable behaviours.  Also not strictly mutually exclusive
with the other kinds of tabs...


Or maybe your tabs are "none of the above".  Which would be a reason I 
asked...

Re: Next pretest

[Chad Brown]

On Jan 24, 2010, at 8:34 AM, David De La Harpe Golden wrote:

> alin.s wrote:
>> Tabs are also ready. 
> Um. What sort of tabs? 

Don't forget the ~5-year-old elisp implementation tabbar.el.   :-)

It sounds like you have another tab implementation for one of ~6 UI systems where we'd like to see it.  I look forward to seeing it, but mentioning it as if it would be part of a pretest in less than a week seems confusing at best.

*Chad

Re: Next pretest

[Chong Yidong]

Chad Brown <yandros@MIT.EDU> writes:

> It sounds like you have another tab implementation for one of ~6 UI
> systems where we'd like to see it.  I look forward to seeing it, but
> mentioning it as if it would be part of a pretest in less than a week
> seems confusing at best.

No, it will not be part of the pretest, nor in Emacs 23.2.

Re: Next pretest

[alin.s]

seewhydee wrote:
> 
>> It sounds like you have another tab implementation for one of ~6 UI
>> systems where we'd like to see it.  I look forward to seeing it, but
>> mentioning it as if it would be part of a pretest in less than a week
>> seems confusing at best.
> 
> No, it will not be part of the pretest, nor in Emacs 23.2.
> 

The tabs will late a period, because this evening I did have an idea , and I
give up everything what I did.
I had done using the model of Mozilla for commuting frames, but in emacs the
tabs can do much more
than in mozilla.






-- 
View this message in context: http://old.nabble.com/Next-pretest-tp27295593p27346355.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Next pretest

[Lluís]

> Another option which I looked into at one stage was toplevel-only tabs 
> that collected and switched between whole emacs frames. i.e. tabs 
> "outside" frames.

Well... this is what I have right now... I simply open a new frame for each
"tab" and switch those frames, which simply are windows in my window-manager...

The only annoyance I perceive right now is that of opening a buffer already
shown in another frame, which simply gives focus to that frame (and my
windowmanager - awesome - does not place that frame on the top of the desktop).

Lluis

--
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: Next pretest

[Juanma Barranquero]

On Sun, Jan 24, 2010 at 15:46, Chong Yidong <cyd@stupidchicken.com> wrote:

> I intend to roll the 23.1.92 pretest this Friday, the 29th.  If you come
> across any problems that would delay the pretest, please let me know.

I'm the only one that sees #4567, an assertion failure on console mode
on Windows?

    Juanma

Re: Next pretest

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sun, Jan 24, 2010 at 15:46, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> I intend to roll the 23.1.92 pretest this Friday, the 29th.  If you come
>> across any problems that would delay the pretest, please let me know.
>
> I'm the only one that sees #4567, an assertion failure on console mode
> on Windows?

Could you try to debug it?

Re: Next pretest

[Juanma Barranquero]

On Tue, Jan 26, 2010 at 16:28, Chong Yidong <cyd@stupidchicken.com> wrote:

> Could you try to debug it?

I've tried, but I haven't gone too far because I don't know what to
expect. For example, it this event expected after typing ñ?

(gdb) p *event
$1 = {
  kind = ASCII_KEYSTROKE_EVENT,
  code = -92,
  part = scroll_bar_above_handle,
  modifiers = 0,
  x = 0,
  y = 0,
  timestamp = 16983672,
  padding = {0x0, 0x0},
  frame_or_window = 48598021,
  arg = 48474114
}

    Juanma

Re: Next pretest

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 26 Jan 2010 16:46:57 +0100
> Cc: emacs-devel@gnu.org
> 
> On Tue, Jan 26, 2010 at 16:28, Chong Yidong <cyd@stupidchicken.com> wrote:
> 
> > Could you try to debug it?
> 
> I've tried, but I haven't gone too far because I don't know what to
> expect. For example, it this event expected after typing ñ?

Probably not, since it triggers an assertion.

Does this happen with 12XX codepages as well?

> (gdb) p *event
> $1 = {
>   kind = ASCII_KEYSTROKE_EVENT,
>   code = -92,
>   part = scroll_bar_above_handle,
>   modifiers = 0,
>   x = 0,
>   y = 0,
>   timestamp = 16983672,
>   padding = {0x0, 0x0},
>   frame_or_window = 48598021,
>   arg = 48474114
> }

This is a non-optimized build, I presume, right?  We aren't chasing
wild geese here, right?

Can you see what event is received w32term.c:w32_read_socket in this
case?  Is that function at all called in the -nw session?  If not, try
w32inevt.c:key_event.  In the latter, it would be interesting to see
what was event->wVirtualKeyCode (around line 426).

Also, how did you type these non-ASCII characters on your keyboard?
Do you have keys for them, or do you need to use AltGr or some such?

Re: Next pretest

[Juanma Barranquero]

On Tue, Jan 26, 2010 at 19:09, Eli Zaretskii <eliz@gnu.org> wrote:

> Probably not, since it triggers an assertion.

True, but sometimes assertions grow stale, and nobody notices for a
long time because apparently not many developers build with assertions
enabled.

> Does this happen with 12XX codepages as well?

  C:\> chcp 1252
  C:\> emacs -Q -nw
  ñ

produces the same effect.

> This is a non-optimized build, I presume, right?  We aren't chasing
> wild geese here, right?

"--with-gcc (4.4) --no-opt --cflags -DENABLE_CHECKING=1 -DXASSERTS=1
-IC:/emacs/build/include -fno-crossjumping"

I'm using the Twilight Dragon Media MinGW build, but I'm reasonably
sure it happened too with stock MinGW gcc 3.X, so it's not likely a
compiler bug.

> Can you see what event is received w32term.c:w32_read_socket in this
> case?  Is that function at all called in the -nw session?  If not, try
> w32inevt.c:key_event.  In the latter, it would be interesting to see
> what was event->wVirtualKeyCode (around line 426).

I cannot debug this right now, but I'll try tonight.

> Also, how did you type these non-ASCII characters on your keyboard?
> Do you have keys for them, or do you need to use AltGr or some such?

They have their own keys (I'm using a Spanish keyboard). But AltGr-4 +
n (which produces ñ) triggers the assertion too.

    Juanma

Re: Next pretest

[Juanma Barranquero]

On Tue, Jan 26, 2010 at 19:27, Juanma Barranquero <lekktu@gmail.com> wrote:

> I'm using the Twilight Dragon Media MinGW build, but I'm reasonably
> sure it happened too with stock MinGW gcc 3.X, so it's not likely a
> compiler bug.

Confirmed that it also happens with gcc (GCC) 3.4.5 (mingw-vista special r3).

    Juanma

Re: Next pretest

[Juanma Barranquero]

On Tue, Jan 26, 2010 at 19:09, Eli Zaretskii <eliz@gnu.org> wrote:

> Can you see what event is received w32term.c:w32_read_socket in this
> case?  Is that function at all called in the -nw session?

No.

> If not, try
> w32inevt.c:key_event.  In the latter, it would be interesting to see
> what was event->wVirtualKeyCode (around line 426).

(gdb) p *event
$1 = {
  bKeyDown = 1,
  wRepeatCount = 1,
  wVirtualKeyCode = 192,
  wVirtualScanCode = 39,
  uChar = {
    UnicodeChar = 241 L'ñ\000',
    AsciiChar = -15 'ñ'
  },
  dwControlKeyState = 0
}

    Juanma

Re: Next pretest

[Jason Rumney]

On 27/01/2010 07:48, Juanma Barranquero wrote:
> On Tue, Jan 26, 2010 at 19:09, Eli Zaretskii<eliz@gnu.org>  wrote:
>    
>> If not, try
>> w32inevt.c:key_event.  In the latter, it would be interesting to see
>> what was event->wVirtualKeyCode (around line 426).
>>      
> (gdb) p *event
> $1 = {
>    bKeyDown = 1,
>    wRepeatCount = 1,
>    wVirtualKeyCode = 192,
>    wVirtualScanCode = 39,
>    uChar = {
>      UnicodeChar = 241 L'ñ\000',
>      AsciiChar = -15 'ñ'
>    },
>    dwControlKeyState = 0
> }
>
>    

w32inevt.c needs the equivalent of this code from w32term.c at the point 
where it currently sets the event kind to ASCII_KEYSTROKE_EVENT.

               inev.kind = inev.code < 128 ? ASCII_KEYSTROKE_EVENT
                                           : MULTIBYTE_CHAR_KEYSTROKE_EVENT;

Re: Next pretest

[Juanma Barranquero]

On Wed, Jan 27, 2010 at 03:02, Jason Rumney <jasonr@gnu.org> wrote:

> w32inevt.c needs the equivalent of this code from w32term.c at the point
> where it currently sets the event kind to ASCII_KEYSTROKE_EVENT.
>
>              inev.kind = inev.code < 128 ? ASCII_KEYSTROKE_EVENT
>                                          : MULTIBYTE_CHAR_KEYSTROKE_EVENT;

ñ ->  "A-C-H-M-S-s-\244 is undefined"

so something more needs to be done.

    Juanma

Re: Next pretest

[Jason Rumney]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, Jan 27, 2010 at 03:02, Jason Rumney <jasonr@gnu.org> wrote:
>
>> w32inevt.c needs the equivalent of this code from w32term.c at the point
>> where it currently sets the event kind to ASCII_KEYSTROKE_EVENT.
>>
>>              inev.kind = inev.code < 128 ? ASCII_KEYSTROKE_EVENT
>>                                          : MULTIBYTE_CHAR_KEYSTROKE_EVENT;
>
> ñ ->  "A-C-H-M-S-s-\244 is undefined"
>
> so something more needs to be done.
>
>     Juanma

Please try the following patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: w32-console-kbd.patch --]
[-- Type: text/x-diff, Size: 8999 bytes --]

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: jasonr@gnu.org-20100127135913-w5ki5nt0nlgk9803
# target_branch: sftp://jasonr@bzr.savannah.gnu.org/srv/bzr/emacs\
#   /trunk
# testament_sha1: c5057dffd8857a57cd7e41fafad303e6e94981c9
# timestamp: 2010-01-27 22:00:49 +0800
# base_revision_id: handa@m17n.org-20100127052918-sjr9309swfbh2ay4
# 
# Begin patch
=== modified file 'src/ChangeLog'
--- src/ChangeLog	2010-01-27 05:28:39 +0000
+++ src/ChangeLog	2010-01-27 13:59:13 +0000
@@ -1,3 +1,8 @@
+2010-01-27  Jason Rumney  <jasonr@gnu.org>
+
+	* w32inevt.c (w32_kbd_patch_key): Save the unicode character.
+	(key_event): Use unicode for characters 128 and higher.
+
 2010-01-27  Kenichi Handa  <handa@m17n.org>
 
 	* regex.c (analyse_first): Fix setting of fastmap for unibyte

=== modified file 'src/w32inevt.c'
--- src/w32inevt.c	2010-01-13 08:35:10 +0000
+++ src/w32inevt.c	2010-01-27 13:59:13 +0000
@@ -81,6 +81,9 @@
 static INPUT_RECORD event_queue[EVENT_QUEUE_SIZE];
 static INPUT_RECORD *queue_ptr = event_queue, *queue_end = event_queue;
 
+/* Temporarily store lead byte of DBCS input sequences.  */
+static char dbcs_lead = 0;
+
 static int
 fill_queue (BOOL block)
 {
@@ -253,13 +256,15 @@
 			  keystate, buf, 128, 0);
       if (isdead > 0)
 	{
-          char cp[20];
-          int cpId;
-
-          GetLocaleInfo (GetThreadLocale (),
+	  char cp[20];
+	  int cpId;
+
+	  event->uChar.UnicodeChar = buf[isdead - 1];
+
+	  GetLocaleInfo (GetThreadLocale (),
 			 LOCALE_IDEFAULTANSICODEPAGE, cp, 20);
-          cpId = atoi (cp);
-          isdead = WideCharToMultiByte (cpId, 0, buf, isdead,
+	  cpId = atoi (cp);
+	  isdead = WideCharToMultiByte (cpId, 0, buf, isdead,
 					ansi_code, 4, NULL, NULL);
 	}
       else
@@ -425,8 +430,6 @@
 
   if (lispy_function_keys[event->wVirtualKeyCode] == 0)
     {
-      emacs_ev->kind = ASCII_KEYSTROKE_EVENT;
-
       if (!NILP (Vw32_recognize_altgr)
 	  && (event->dwControlKeyState & LEFT_CTRL_PRESSED)
 	  && (event->dwControlKeyState & RIGHT_ALT_PRESSED))
@@ -461,9 +464,65 @@
 	  else if (event->uChar.AsciiChar == 0)
 	    w32_kbd_patch_key (event);
 	}
+
       if (event->uChar.AsciiChar == 0)
-	return 0;
-      emacs_ev->code = event->uChar.AsciiChar;
+	{
+	  emacs_ev->kind = NO_EVENT;
+	  return 0;
+	}
+      else if (event->uChar.AsciiChar < 128)
+	{
+	  emacs_ev->kind = ASCII_KEYSTROKE_EVENT;
+	  emacs_ev->code = event->uChar.AsciiChar;
+	}
+      else if (event->uChar.UnicodeChar > 0)
+	{
+	  emacs_ev->kind = MULTIBYTE_CHAR_KEYSTROKE_EVENT;
+	  emacs_ev->code = event->uChar.UnicodeChar;
+	}
+      else
+	{
+	  /* Fallback for non-Unicode versions of Windows.  */
+	  wchar_t code;
+	  char dbcs[2];
+          char cp[20];
+          int cpId;
+
+	  /* Get the codepage to interpret this key with.  */
+          GetLocaleInfo (GetThreadLocale (),
+			 LOCALE_IDEFAULTANSICODEPAGE, cp, 20);
+          cpId = atoi (cp);
+
+	  dbcs[0] = dbcs_lead;
+	  dbcs[1] = event->uChar.AsciiChar;
+	  if (dbcs_lead)
+	    {
+	      dbcs_lead = 0;
+	      if (!MultiByteToWideChar (cpId, 0, dbcs, 2, &code, 1))
+		{
+		  /* Garbage  */
+		  DebPrint (("Invalid DBCS sequence: %d %d\n",
+			     dbcs[0], dbcs[1]));
+		  emacs_ev.kind = NO_EVENT;
+		}
+	    }
+	  else if (IsDBCSLeadByteEx (cpId, dbcs[1]))
+	    {
+	      dbcs_lead = dbcs[1];
+	      emacs_ev.kind = NO_EVENT;
+	    }
+	  else
+	    {
+	      if (!MultiByteToWideChar (cpId, 0, &dbcs[1], 1, &code, 1))
+		{
+		  /* Garbage  */
+		  DebPrint (("Invalid character: %d\n", dbcs[1]));
+		  emacs_ev.kind = NO_EVENT;
+		}
+	    }
+	  emacs_ev->kind = MULTIBYTE_CHAR_KEYSTROKE_EVENT;
+	  emacs_ev->code = code;
+	}
     }
   else
     {

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWXaAsuIADTzfgHEwc3f//3//
366////6YBG8+uz1z3wZPPsUltqTfc94N62g0vdnuH33u7ha4+8a83uwdQpKlKj5sKVhlE0yjTT1
Eekyek8o9qYkaGQAaZAAAAAGSABMJkQmhJlPNJPRDQBkZAAAAAZTTCEqfkFPTTapoeUDIAGgyGgA
AAaASaopiNRHqepp5MiNGTR6nqADQBoAAAA0EUk0AJkTBBkAKeFNopo9E0DQ00NAMmTQRRJMKYEa
ZE8mp6aTamQBP1TymmR6jQAGNQeiNiS6QLi5IpBZEUZIiRREEQxn+Ng3DIInppxFhRc1MJy8GitL
RllErUMV1cOI1VgeCvHTktvYiCcESp7r3L+Z8T9j4HcfodpJnJLj+BkM+mljqMHKrWq5diaM0t1Y
SS/E3mqtKDgrXazyXJAI/oRtGCJFoBVJSl16dw4Umta0jEAxYIBsFrXFmOzWgutCWGAie+YmgfKG
yBTy+6NjxncXGwprP9qjZU5sfwITBAeQoZ4Agjbidm6IxK6eHgtSK3kkVPGN+Nzfuca+bYJ0OdyG
aJVUkNN5B3R0EkFOPNqB4gaaJ95JTPovWHUEGu8OhHWXrpKqrfAUMrfebWIrrm3bgrddYVK1GWVG
sgi2Q3zkBKQwxGNiUPdXecW5abprUrr1wFqSYcF9QpcL+5BIiYvfF50UdrFMJACoOF0RgAPXWU4n
YcVWl5MGaEEgawJEIHZD6nXGvVHIdzYbzoKzSWeqYYJxqMdONlDwNHXhT+uKqbuXCn8Q4rxOggxZ
MMCwwv3MAvYwtDCBJgRzA6l6208l4ryjxrfNycloZg0g2tS0tK0P3gzQrC14A9LYs17gLFrmvi9E
RdFFdMX3zzgtndcOKfgOTiDAObQ5JJJWJIghJYE6c6UNAdpNa7Kqqqqqqq5yuNmbLWXEmQI7rKBW
KBTTWQkZvQ860O+Y8ttwM/dQtIKtKitQhexxOelcD3U1RTeSUhOybp5Weit1OLC4LEhKJLwUuKmZ
Fowo4MhJquTRQSs0NJ0EwRVuMxMwC5eqmAQXAKkA6D+g4tIYZufStyZn2X2XYYyaqGMyVmYat8OG
LALcgHbZ0Q97MaKifsGhPqACifmOmFxXdbAuywkSgEJkN9K6mbQtOrvBosapKK1OmECss+pSlDTA
tLAl3MA6fYGleBi1glAkCcBjmoG7BmJuapCULXcDeA114bwAIi0/eGQCwkDg3U/ySULJruq7hjcA
vXtIyA5NtyyWVsEapqk5s1inXi4rNtrdAjRITNaVtJ0M2pZLsNDT6A7QfBbramBNl6dLJmXMJ56K
FuRItVVCBenrJjouqhnQlQOfVMMIDjd3RhKnmyI0AG49YOGU26qJ3ofCTk7BnF+8KrZ11Gmmq/mX
sdS/ItbC6fxMMUtrlOkvbh8IUSUJYGgsJaBrTQoAyQSLbHL4RZc23pOO5iYahQvJYSoCmxWswEYL
7JteohMaOH0vEv8u0Wm7VvwvotMwIICPJzN01C2orpkaKQnrywqOcHVnkFhsYP8gDhIUJB7OEOfQ
2paspR4U52euW9H1ZEiZPiup4NS9i5X6EdDtwyhxzg20WWMAXyLWthbpLTDa787bO9a6qGtw14lC
wVLgugso7V1UpXMXxgCIJHT/+hqEQUE3tvgMkggSxCXq67Uc2KibBCZkoCHMz5sLy3BuwnajYvww
Tq1b4JJuxMhlhoALQYY2PSAKgZaVyjJYMi0DrIKLJdVLxheGz11M3dC76952tuPDkZpkcLiEnHLR
osy3pa6lsnMRunKcuQocqs7FmuffJYZjJeTkZE8VhO7bLdpvrDJYdLC00yX6VlI6Xg9GyzXkO3Fb
ouY5M1OhsluVLq5NvPQ1TJdGazFix35SUYsWLFCiFBgWFgBa0yymGYf6FDsmAAXgmCSDeknvJ7vl
DNfZjlFd0VUSmMkrMzE+hKidz2MD1rpUdQADA5R3DxUsPynwOZRwdcb5tblDIwNutGlhLrb7+TXA
PTcmc7kw4Kg8vgSslJoTu8V+ByLOMCaMlFbJoAGIGr7K0zb1Nhxp99wk3ct8CaO2U59WBfoDr3AO
IHmvqPSu/TvxL8NDvoZrQ0T19VlZpdu7bOLgmxx3Sb8CZgIb5DESMal22wcBIQa6xhbNK06vn1pS
MidOinC2ybXZjB1A2LhAA6GQuW5zuqPyaoYWml9S6NzzOGL5fCA5qNu/ibn5Dkn4zOgE+wqAKEsC
LwBfC6TQBoxzwtNUEwCWQAXRWGDz2tq660d4up4wd0jQiQr8SouqrrGqsM5atxA4AOQQVndmr+4r
X7id99oYmhrMNYlstVw5rlWU5+WhxMDuSo9iXE4J3Je5NgiMIWAagBVbkXv3DmEzk90lXm7pQpec
2LuomXWi+MnpRjIcRrXCw1586UDRXdlokwcAUvIYbsLWAMjDqAXSfIycGVFZNWwMxxZVbdDIxu0Y
+a+K9K1OWbW4UWNCzQiBJDv1VAaa3ZTUcbx8y+MYLOOQLk2iV1D/adhzN8+dr+GVrh8AAuFGDoZA
HsADzp2FOvzBj6mexVtqjk8SWnc4PvJb1+YE3RvBkAVg3JuICmbkDFIN7KAYKgeEGALQaAyANG0G
UCgMiMA2AuAjgmhIMUAMgDBqPye3S/kqcGebK8nd0Wc5dXsLAAdINmZBYD2EMo9e/5iFLNzMGBPR
yFD2YWIUXrEtV/59mv7S/+vg5o6yFiGAWRCKfCfI8HBxk/HEeW3tzPeXJmJSi4zguvqfSzF3LGFe
1zEP9V8F3bD/MfgaC4zX6ZPqAvmYtu6gbXK4au5wd46C/eLlPs95QLsq8PB3PcFXsM7YWo2E1z8m
oot1CDI1YzoyF3xL3j2uWhkXKSy85zAchHZxm70pERH0TaamGI07IuE+04dwPETvHtJUa0wiHnwM
/jK7hyOYCDmIGVS7UOOAPbuRci3lVloQhGZlayDkFTXZU3/S99vylCaQf+eEJiwU4Ld5/jBHJFgB
jdQMp7GnLXk4GG8HBRxcHMNz9R8/08HgcAa1+sG8HacImFhDVAB6zo4AEs+KNyINqNRANaAQk64k
JiOkZDgmNDhPQlaHPFz7JsD9QcpqLKlimWVTp+4NeS+TFIyMB9YSXHP6fILuH6rtwSt0qVrck2Hv
D8w01BSbg2y+MqQD2W9CdiXAHuJk4J9AV/KPqBI+NXYILl9OU50vaxPZYaj8+8r06I605GmGNUYt
7D4suUHaSV9AFk18dpSbAMaxVnMoiTD+70pf1/U1tdTdFZsWLD4BnEfPklyoHWghpkNsVCTSfQpB
+wwJKJQZgZ/V9pMsYaBIU5HEukTCJCQlrme6jmWN4IahFwBQRSoPgIlonvNJvxgG64WU1WmaIaZO
ctkQHyXw3X01ajBWRPu3d+oRxz79VlwNNbZbduN5qANT0gzec2uOKxldzcD/sB1wfhEdcuTft1Ov
nxz20aJ+SmmCwhizi809vAHhoOzFfgLJ8F5jEG7s1DoKh2R1eYVkOuoQsSpnvPuhoDiDIAwNFc+U
6cd6sM1Gv7L5Y728WAPcbeVO8fDFPL080lnG+Vds76smK6ZidBp9RCu69Mg9WKGT4KzCU2Rk0M4H
4B9wMJEiQg7gFFNBRfI0oKCiQWY3qtoRCifk6DvZR/WNtR1bouwGdNnA5dnPRu+B6xEEMRbPQN2m
8HHhKfPtp4XWzorB6gLdR7SAMDr2+2covVpXSu4BvXxty9vxOW3MADniM3Sbsrum/5wd4BzHh6Yg
hCPu5HcaXiA2CwCECOB5eg2nOUkHojlexSujdsB4qwekB9eHYDIS+sTEGD5drETFCpMACEdaHQ3A
zLxwhNuQTBwvxzhLyQlVqcX3U2Syubld+tCFCiu2vC2FWMtcDwYvZUVZfgr3Z8mLLl7CWTh9k1V9
fiSZ/iJ0vD4cglJDVvnbryz5hYsfuPcdJY4LytCBuB7XoaFPlXNaQYXcuo6Yg6xQZNSyR1uD5LeT
WEevRJRoCyg1nEDStIfi+y5MkEcl+l3rivXxB1/EHuetpdS5rW+gLseVf5TISAgSB1ODP4Fy2tT0
HtXxWr3mzzXne1dJM7ASVqPyAy5wKNjqmNYOdhDgOQHzAG+/JoDfrbgfzGwOIt5W7mXa94WkEZXA
NukQMTzTXMqPZJ6di+MHlBsB4VQqe+D4XgwL23z5xQr3A+jeNWh5XStq5Aew7JCSZCSZCSZWSZCS
ZCSZCSZCSZCSZCSZCSWCcqOdyL4XK4Xm5E1ljuWQekDzO+7S+to1vHUaieZ6HY/MB877MWKPm/B5
3xda+TtfR9WwAbF5VA52HmB6lvADNxcd6HniKEmNzwTVscjnXQBqW4fEDHWDiIYTEDLfxIGddiy3
BYJDY7kGDQDYA+INYNyM2GkGtaBbPzvc0rxXP3LqXyXA9DLOgX8ichcW8GxaFdz2rIug0rYWA31g
2sqMrBvHGxajGwGpN6NjL9pY2A8ofamx+hoU7QMMXqdOB2jxaUQetgqDICdIEEwCFGZEbyCMrvkA
hlaLneTS8I1PW+r6w0IFe+U2li13HM6XpuUuHnYB4k0cJT0gMmBflBl0tSIM66GxHKuDKEKMx5VB
aINKAhxc5aNqhDxvoWRMlOkGSBHyFYuhx4Ygi2+D63rXnfO1g2Oa3aauTQDuMAKnmWgeh8Fuc2le
hexfkfmW54zWmFgIiQgeDE0F1uZm82IgyytijgDEjiRLv8TSzATdw2g+wMhbFBb1JhHGv/J7PU8q
2IPDi6KVLdAN4BXyNSnktAIdJbTfyFkLgtK9TzPlWA4bgc10r/RwBum8dZiaQmg0HHYiKoJFTZOb
JhJAy1LJjDSiiiiiiiiiijm2yBJ3jGA6sCjh3M9LINpbgk0FxIJuSQZA6FxLWDMJnkHMjMqKAYec
rBiqDQG8HxXWvQu6kLweqtlvB2APKtUzx0gugEPeubIKlLZCOtcQdT7212ei+i43OXeOCCPaulc3
5h6/A9DlB2v7H7EfB5QzUvdkAehmt60lBEZxNbR9LU2LYeUca5S4G2yQKwQwSKHMtD1rQla9y/E8
rPP6IsA98+K0Lp2Pbxdy0zBr7WY8fE7FkPqfzjW5LJyXfm0cF2ri5ruRdAPilkB5necL6ltazxsa
18jLsXqcrsXAv46IaXFseDuX4rPnel5vV9y2g2vxtzXU/efcwMMB/xdyRThQkHaAsuI=

Re: Next pretest

[Juanma Barranquero]

On Wed, Jan 27, 2010 at 15:03, Jason Rumney <jasonr@gnu.org> wrote:

> Please try the following patch:

(I've changed three trivial typos emacs_ev. to emacs_ev->)

It still triggers the assertion, and kind is still ASCII_KEYSTROKE_EVENT:

  keyboard.c:5614: Emacs fatal error: assertion failed: c == event->code

  Breakpoint 1, w32_abort () at w32fns.c:7345
  7345      button = MessageBox (NULL,
  (gdb) bt
  #0  w32_abort () at w32fns.c:7345
  #1  0x0104f358 in die (msg=0x1548e80 "assertion failed: c ==
event->code", file=0x15404e0 "keyboard.c", line=5614) at alloc.c:6259
  #2  0x010135f6 in make_lispy_event (event=0x167f178) at keyboard.c:5614
  #3  0x010117e7 in kbd_buffer_get_event (kbp=0x88f828,
used_mouse_menu=0x88fabc, end_time=0x0) at keyboard.c:4347
  #4  0x0100d899 in read_char (commandflag=1, nmaps=2, maps=0x88f960,
prev_event=48322562, used_mouse_menu=0x88fabc, end_time=0x0) at
keyboard.c:3079
  #5  0x0101f75f in read_key_sequence (keybuf=0x88fc00, bufsize=30,
prompt=48322562, dont_downcase_last=0, can_return_switch_frame=1,
      fix_current_buffer=1) at keyboard.c:9512
  #6  0x01007c86 in command_loop_1 () at keyboard.c:1643
  #7  0x0103bb12 in internal_condition_case (bfun=0x10073e0
<command_loop_1>, handlers=48379098, hfun=0x1006b11 <cmd_error>) at
eval.c:1490
  #8  0x01006feb in command_loop_2 () at keyboard.c:1360
  #9  0x0103b531 in internal_catch (tag=48378290, func=0x1006fc8
<command_loop_2>, arg=48322562) at eval.c:1226
  #10 0x01006fa1 in command_loop () at keyboard.c:1339
  #11 0x01006203 in recursive_edit_1 () at keyboard.c:954
  #12 0x01006727 in Frecursive_edit () at keyboard.c:1016
  #13 0x01002af2 in main (argc=3, argv=0xa71318) at emacs.c:1833
  (gdb) frame 2
  #2  0x010135f6 in make_lispy_event (event=0x167f178) at keyboard.c:5614
  5614                eassert (c == event->code);
  (gdb) p *event
  $1 = {
    kind = ASCII_KEYSTROKE_EVENT,
    code = -92,
    part = scroll_bar_above_handle,
    modifiers = 0,
    x = 0,
    y = 0,
    timestamp = 25781364,
    padding = {0x0, 0x0},
    frame_or_window = 48446469,
    arg = 48322562
  }


In key_event, control is going through this branch

      else if (event->uChar.AsciiChar < 128)
	{
	  emacs_ev->kind = ASCII_KEYSTROKE_EVENT;
	  emacs_ev->code = event->uChar.AsciiChar;
	}

(that's lines 473-477 after your patch) because at that point, event is

  (gdb) p *event
  $3 = {
    bKeyDown = 1,
    wRepeatCount = 1,
    wVirtualKeyCode = 192,
    wVirtualScanCode = 39,
    uChar = {
      UnicodeChar = 164 L'¤\000',
      AsciiChar = -92 '¤'
    },
    dwControlKeyState = 0
  }

    Juanma

Re: Next pretest

[Jason Rumney]

Juanma Barranquero <lekktu@gmail.com> writes:

> (I've changed three trivial typos emacs_ev. to emacs_ev->)

Thanks, I don't have a W32 installation here to try it on.
> In key_event, control is going through this branch
>
>       else if (event->uChar.AsciiChar < 128)

try changing that to:

     else if (event->uChar.AsciiChar > 0 && event->uChar.AsciiChar < 128)

That should catch the following:

>     uChar = {
>       UnicodeChar = 164 L'¤\000',
>       AsciiChar = -92 '¤'
>     },

Re: Next pretest

[Juanma Barranquero]

On Wed, Jan 27, 2010 at 17:18, Jason Rumney <jasonr@gnu.org> wrote:

> try changing that to:
>
>     else if (event->uChar.AsciiChar > 0 && event->uChar.AsciiChar < 128)

That works, yeah.

Now with

  C:\> chcp 1252
  C:\> emacs -Q -nw

I'm able to type and correctly display all spanish characters
(ÇçÑñ¡¿ºª plus accented chars).

    Juanma

Re: Next pretest

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> That works, yeah.
>
> Now with
>
>   C:\> chcp 1252
>   C:\> emacs -Q -nw
>
> I'm able to type and correctly display all spanish characters
> (ÇçÑñ¡¿ºª plus accented chars).

Great, could someone check this into the repository before Friday's
pretest?  Thanks.

Re: Next pretest

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Thu, 28 Jan 2010 00:18:01 +0800
> Cc: emacs-devel@gnu.org
> 
> Juanma Barranquero <lekktu@gmail.com> writes:
> 
> > (I've changed three trivial typos emacs_ev. to emacs_ev->)
> 
> Thanks, I don't have a W32 installation here to try it on.
> > In key_event, control is going through this branch
> >
> >       else if (event->uChar.AsciiChar < 128)
> 
> try changing that to:
> 
>      else if (event->uChar.AsciiChar > 0 && event->uChar.AsciiChar < 128)
> 
> That should catch the following:
> 
> >     uChar = {
> >       UnicodeChar = 164 L'¤\000',
> >       AsciiChar = -92 '¤'
> >     },

The "event->uChar.AsciiChar < 128" part in the above condition causes
compiler warnings:

  w32inevt.c: In function `key_event':
  w32inevt.c:473: warning: comparison is always true due to limited range of data type

I think we can remove the second part, because AsciiChar is declared
as CHAR, which is a `signed char' type, so it is always less than
128.  Jason, do you agree?  Juanma, can you check that removing that
does not cause trouble in your use-case?

Re: Next pretest

[Juanma Barranquero]

On Fri, Jan 29, 2010 at 13:14, Eli Zaretskii <eliz@gnu.org> wrote:

> The "event->uChar.AsciiChar < 128" part in the above condition causes
> compiler warnings:
>
>  w32inevt.c: In function `key_event':
>  w32inevt.c:473: warning: comparison is always true due to limited range of data type

Curious, comping with gcc (TDM-2 mingw32) 4.4.1-dw2 I don't get these warnings.

> Juanma, can you check that removing that
> does not cause trouble in your use-case?

No trouble at all.

    Juanma

Next pretest

[Chong Yidong]

I plan to make the next pretest next Monday, the 30th of March.