Emacs pretest 24.0.90

Emacs pretest 24.0.90

[Chong Yidong]

Emacs pretest 24.0.90 is now available for download via FTP, at the
following location:

  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz

This is the first pretest for what will become Emacs 24.1.
See etc/NEWS for a list of changes since Emacs 23.3.

Please send me an email reporting success or failure on your build
platform.  Please report any bugs that you come across via
M-x report-emacs-bugs, or email bug-gnu-emacs@gnu.org.
For questions, email emacs-devel@gnu.org.

Thank you for helping to test Emacs.


Note: this email is also sent via BCC to the list of Emacs pretesters.
If you are not subscribed to the emacs-devel mailing list, and would
like to receive these emails about Emacs pretests, send me an email and
I will add you to the list.

Re: Emacs pretest 24.0.90

[Leo]

On 2011-09-26 11:57 +0800, Chong Yidong wrote:
> This is the first pretest for what will become Emacs 24.1.
> See etc/NEWS for a list of changes since Emacs 23.3.

Thank you for all the hard work to bring this about ;)

Leo

Re: Emacs pretest 24.0.90

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> On 2011-09-26 11:57 +0800, Chong Yidong wrote:
>> This is the first pretest for what will become Emacs 24.1.
>> See etc/NEWS for a list of changes since Emacs 23.3.
>
> Thank you for all the hard work to bring this about ;)

It would be more appropriate to thank the Emacs development team as a
whole.  Of course, the work to get to 24.1 is just begun...

Re: Emacs pretest 24.0.90

[Leo]

On 2011-09-27 02:43 +0800, Chong Yidong wrote:
> It would be more appropriate to thank the Emacs development team as a
> whole.  Of course, the work to get to 24.1 is just begun...

That is what I meant.

Leo

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 25 Sep 2011 23:57:41 -0400
> 
> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
> 
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz

This doesn't build on MS-Windows because the file lib/makefile.w32-in
is missing from the tarball.

After adding that file (from the bzr tree) and rerunning
nt/configure.bat, the build proceeds as expected, and the resulting
binary seems to work fine.

Thanks!

Re: Emacs pretest 24.0.90

[Glenn Morris]

Eli Zaretskii wrote:

> This doesn't build on MS-Windows because the file lib/makefile.w32-in
> is missing from the tarball.

Now added to make-dist.

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Mon, Sep 26, 2011 at 09:43, Eli Zaretskii <eliz@gnu.org> wrote:

> After adding that file (from the bzr tree) and rerunning
> nt/configure.bat, the build proceeds as expected, and the resulting
> binary seems to work fine.

Same here. It both builds and bootstraps OK on a Windows 7 Home
Premium, using gcc (GCC) 3.4.5 (mingw-vista special r3).

    Juanma

Re: Emacs pretest 24.0.90

[Neal Becker]

Chong Yidong wrote:

> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
> 
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz
> 
> This is the first pretest for what will become Emacs 24.1.
> See etc/NEWS for a list of changes since Emacs 23.3.
> 

Can we post etc/NEWS somewhere so we can see it without d/l all of emacs24.1?

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Neal Becker <ndbecker2@gmail.com>
> Date: Mon, 26 Sep 2011 07:12:17 -0400
> 
> Can we post etc/NEWS somewhere so we can see it without d/l all of emacs24.1?

You can see it here:

   http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/etc/NEWS

Re: Emacs pretest 24.0.90

[Kevin Rodgers]

On 9/26/11 5:36 AM, Eli Zaretskii wrote:
>> From: Neal Becker<ndbecker2@gmail.com>
>> Date: Mon, 26 Sep 2011 07:12:17 -0400
>>
>> Can we post etc/NEWS somewhere so we can see it without d/l all of emacs24.1?
>
> You can see it here:
>
>     http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/etc/NEWS

Is this a typo:

Buffers RTL text should look exactly the same as before.
        ^
        with no

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Kevin Rodgers <kevin.d.rodgers@gmail.com>
> Date: Wed, 12 Oct 2011 22:50:06 -0600
> 
> On 9/26/11 5:36 AM, Eli Zaretskii wrote:
> >> From: Neal Becker<ndbecker2@gmail.com>
> >> Date: Mon, 26 Sep 2011 07:12:17 -0400
> >>
> Is this a typo:
> 
> Buffers RTL text should look exactly the same as before.
>         ^
>         with no

Yes, of course.  Thanks for catching it.  I fixed it.

Re: Emacs pretest 24.0.90

[Lars Magne Ingebrigtsen]

By the way, do we have any schedule for when 24.1 is going to be
released?  I mean, we obviously don't have any firm deadline, but what
are we aiming for?  Early 2012 or something?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 26 Sep 2011 18:53:43 +0200
> 
> By the way, do we have any schedule for when 24.1 is going to be
> released?  I mean, we obviously don't have any firm deadline, but what
> are we aiming for?  Early 2012 or something?

See

   http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html

Re: Emacs pretest 24.0.90

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> See
>
>    http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html

But that was in May.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Emacs pretest 24.0.90

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> See
>>
>>    http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html
>
> But that was in May.  :-)

FWIW, the pretest for 23.1 took six months, but IIRC that had a longer
development period prior to the pretest.  We'll see.

Re: Emacs pretest 24.0.90

[Bastien]

Chong Yidong <cyd@stupidchicken.com> writes:

> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
>
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz
>
> This is the first pretest for what will become Emacs 24.1.
> See etc/NEWS for a list of changes since Emacs 23.3.

Yes, kudos for the hard work!

-- 
 Bastien

Re: Emacs pretest 24.0.90

[Rasmus]

> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:

Thank you. 

> Thank you for helping to test Emacs.

Thanks to everyone contributing to GNU Emacs.

-- 
Sent from my Emacs

draft for DEL key poll

[Richard Stallman]

I'm planning the poll about DEL.  Here is a draft for comments.  (I
will also write a poll about completion.)



In Emacs 24, now in pretest, a change is being considered for DEL
(often the Backspace key) and the Delete function key.  When there is
an active region, they would delete the region instead of just one
character.  This is enabled by default in the current pretest, so
building and using the pretest is a way to test it.

Are you in favor of this change?  How strongly do you feel
about the matter?

We don't want to just "count votes" -- we want to understand
how this affects users.  So if you care about the issue,
please tell us how the change affects your editing.

What are the cases where you find it helpful?

What are the cases where you find it inconvenient?

How would you describe your level of Emacs experience?

Please send your responses to emacs-delete-poll@gnu.org.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: draft for DEL key poll

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>I'm planning the poll about DEL.  Here is a draft for comments.  (I
>will also write a poll about completion.)
>
>In Emacs 24, now in pretest, a change is being considered for DEL
>(often the Backspace key) and the Delete function key.  When there is
>an active region, they would delete the region instead of just one
>character.  This is enabled by default in the current pretest, so
>building and using the pretest is a way to test it.
>
>Are you in favor of this change?  How strongly do you feel
>about the matter?
>
>We don't want to just "count votes" -- we want to understand
>how this affects users.  So if you care about the issue,
>please tell us how the change affects your editing.
>
>What are the cases where you find it helpful?
>
>What are the cases where you find it inconvenient?
>
>How would you describe your level of Emacs experience?
>
>Please send your responses to emacs-delete-poll@gnu.org.

It would be great to have some elisp I could evaluate to test this
change before I vote in a poll about it.

-K

Re: draft for DEL key poll

[Kim F. Storm]

Karl Fogel <kfogel@red-bean.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>>I'm planning the poll about DEL.  Here is a draft for comments.  (I
>>will also write a poll about completion.)
>>
>>In Emacs 24, now in pretest, a change is being considered for DEL
>>(often the Backspace key) and the Delete function key.  When there is
>>an active region, they would delete the region instead of just one
>>character.  This is enabled by default in the current pretest, so
>>building and using the pretest is a way to test it.

>
> It would be great to have some elisp I could evaluate to test this
> change before I vote in a poll about it.

Actually, if you use cua-mode, DEL and BS have always behaved like this!
Maybe this fact should be mentioned in the poll, so users of cua-mode
are not confused when trying to determine what's changed (since nothing
changed).

I guess cua-mode need some testing under 24.1 in this respect
(in particular, cua-mode saves the deleted text in register "0",
which I strongly prefer to messing with the kill-ring).

-- 
Kim F. Storm  http://www.cua.dk

Re: draft for DEL key poll

[Stefan Reichör]

no-spam@cua.dk (Kim F. Storm) writes:

> Karl Fogel <kfogel@red-bean.com> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>>I'm planning the poll about DEL.  Here is a draft for comments.  (I
>>>will also write a poll about completion.)
>>>
>>>In Emacs 24, now in pretest, a change is being considered for DEL
>>>(often the Backspace key) and the Delete function key.  When there is
>>>an active region, they would delete the region instead of just one
>>>character.  This is enabled by default in the current pretest, so
>>>building and using the pretest is a way to test it.
>
>>
>> It would be great to have some elisp I could evaluate to test this
>> change before I vote in a poll about it.
>
> Actually, if you use cua-mode, DEL and BS have always behaved like this!
> Maybe this fact should be mentioned in the poll, so users of cua-mode
> are not confused when trying to determine what's changed (since nothing
> changed).
>
> I guess cua-mode need some testing under 24.1 in this respect
> (in particular, cua-mode saves the deleted text in register "0",
> which I strongly prefer to messing with the kill-ring).

When using cua rectangle mode (start with C-RET), DEL does not delete the selection.
It just deletes one character and disables the selection.
This is often annoying. Is this a bug or a design feature?

I consider it a bug.


Stefan.

Re: draft for DEL key poll

[Richard Stallman]

    Actually, if you use cua-mode, DEL and BS have always behaved like this!

CUA mode changes a lot more too, right?
We should avoid giving the idea that enabling CUA mode is
a way to try this out.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: draft for DEL key poll

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Actually, if you use cua-mode, DEL and BS have always behaved like this!
>
> CUA mode changes a lot more too, right?
Right.

> We should avoid giving the idea that enabling CUA mode is
> a way to try this out.

I didn't suggest that - but since users of cua-mode are already
accustomed to the proposed new behaviour, maybe you could note that
cua-mode users should ignore the poll, as they are not affected by the
change.

-- 
Kim F. Storm  http://www.cua.dk

Re: draft for DEL key poll

[Stefan Monnier]

> I didn't suggest that - but since users of cua-mode are already
> accustomed to the proposed new behaviour, maybe you could note that
> cua-mode users should ignore the poll, as they are not affected by the
> change.

We could mention that this change makes standard a subset of the
behavior provided by delete-selection-mode, pc-selection-mode, and
cua-mode, indeed.


        Stefan

Re: draft for DEL key poll

[Richard Stallman]

    We could mention that this change makes standard a subset of the
    behavior provided by delete-selection-mode, pc-selection-mode, and
    cua-mode, indeed.

I mentioned that.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: draft for DEL key poll

[Richard Stallman]

    It would be great to have some elisp I could evaluate to test this
    change before I vote in a poll about it.

You can test it by building the pretest.  Maybe someone could extract
a patch to test it, but testing it that way would require more
knowledge than building a pretest, so it might not help much.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

disable delete-selection-mode? (was: Re: draft for DEL key poll)

[chad]

I had a question about the poll wording (should it mention
deactivating the region?), but I wanted to check the behavior without
delete-selection-mode, to verify that my memory of the old default was
correct.  Running emacs -q from this morning's bzr HEAD, I can't find
a way to turn off the new behavior; an active region is deleted
regardless of delete-selection-mode.  This isn't the behavior I see with
my os-default emacs 22.1 install. What am I missing?

Thanks,
*Chad

On Sep 26, 2011, at 2:12 PM, Richard Stallman wrote:

> I'm planning the poll about DEL.  Here is a draft for comments.  (I
> will also write a poll about completion.)

Re: disable delete-selection-mode?

[Glenn Morris]

chad wrote:

> I had a question about the poll wording (should it mention
> deactivating the region?), but I wanted to check the behavior without
> delete-selection-mode, to verify that my memory of the old default was
> correct.  Running emacs -q from this morning's bzr HEAD, I can't find
> a way to turn off the new behavior; an active region is deleted
> regardless of delete-selection-mode.  This isn't the behavior I see with
> my os-default emacs 22.1 install. What am I missing?

The NEWS file (it's delete-active-region).

Re: disable delete-selection-mode? (was: Re: draft for DEL key poll)

[Richard Stallman]

    I had a question about the poll wording (should it mention
    deactivating the region?),

Would you please state your question at greater length?
I can't understand it from that.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: draft for DEL key poll

[Juri Linkov]

> I'm planning the poll about DEL.  Here is a draft for comments.

Please include also a related important question:

When there is an active region, a self-inserting character
should delete the region before the character is inserted
by default?

Re: draft for DEL key poll

[Richard Stallman]

    When there is an active region, a self-inserting character
    should delete the region before the character is inserted
    by default?

Ok, I will ask about this other change too.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: draft for DEL key poll

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> In Emacs 24, now in pretest, a change is being considered for DEL
> (often the Backspace key) and the Delete function key.  When there is
> an active region, they would delete the region instead of just one
> character.  This is enabled by default in the current pretest, so
> building and using the pretest is a way to test it.

This description fails to explain the underlying logic behind the
change.

If an active region is made with the mouse, and with shift-selection,
the DEL key deletes it.  This behavior is non-negotiable as a default,
as it is the standard behavior of graphical applications on modern GUI
platforms and there is no good reason for Emacs to violate it.

Some Emacs commands perform a certain operation on the region when it is
active.  In general, this "act on region" behavior does not draw a
distinction between a region made with the mouse (or shift-selection)
and a region made "normally" (e.g. by C-SPC followed by point motion).
In previous Emacs releases, a special exception was made for the DEL and
delete keys.  This exception has now been dropped.

Anyone who argues that DEL ought not to delete a "normal" active region
should provide a convincing explanation of why DEL should be treated
differently from other Emacs commands that act on active regions.

Re: draft for DEL key poll

[Richard Stallman]

    This description fails to explain the underlying logic behind the
    change.

It is not needed.  The purpose of the poll is to ask people like or
dislike, and why.  It isn't supposed to argue in favor of the feature.

    Anyone who argues that DEL ought not to delete a "normal" active region
    should provide a convincing explanation of why DEL should be treated
    differently from other Emacs commands that act on active regions.

DEL is a basic and frequent command, so it should make distinctions as
is convenient for users, including special cases when that's what's
convenient.  Uniformity is not the priority for commands such as this.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: draft for DEL key poll

[James Cloos]

>>>>> "CY" == Chong Yidong <cyd@stupidchicken.com> writes:

CY> Some Emacs commands perform a certain operation on the region when
CY> it is active.  In general, this "act on region" behavior does not
CY> draw a distinction between a region made with the mouse (or
CY> shift-selection) and a region made "normally" (e.g. by C-SPC
CY> followed by point motion).  In previous Emacs releases, a special
CY> exception was made for the DEL and delete keys.  This exception has
CY> now been dropped.

(It has been long enough since region highlighting arrived that
I've forgotten what setting I used to require a double-tap to create
highlighted regions.  And grep(1)ing my custom file didn't "highlight"
the amswer.  (Sorry for the pun.))

Is is the case that active region == highlighted region?

Ie, if emacs is configured such that C-SPC must be hit twice to
highlight the region, does that imply that when a region is not
highlighted that DEL will not delete it?

Allowing DEL to delete or seft-insert to replace a highlighted region
is one thing.  Allowing them to delete a non-highlighted region, OTOH,
is -- or should be -- a non-starter.

And I still think that regions so deleted should be on the kill-ring.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: draft for DEL key poll

[Alan Mackenzie]

On Mon, Sep 26, 2011 at 08:52:20PM -0400, Chong Yidong wrote:
> Richard Stallman <rms@gnu.org> writes:

> > In Emacs 24, now in pretest, a change is being considered for DEL
> > (often the Backspace key) and the Delete function key.  When there is
> > an active region, they would delete the region instead of just one
> > character.  This is enabled by default in the current pretest, so
> > building and using the pretest is a way to test it.

> This description fails to explain the underlying logic behind the
> change.

> If an active region is made with the mouse, and with shift-selection,
> the DEL key deletes it.  This behavior is non-negotiable as a default,
> as it is the standard behavior of graphical applications on modern GUI
> platforms and there is no good reason for Emacs to violate it.

There are several good reasons, otherwise Richard wouldn't be initiating
a poll about it.

I sincerely hope we won't be introducing too many more behaviours which
are "standard" in modern GUIs.

> Some Emacs commands perform a certain operation on the region when it is
> active.  In general, this "act on region" behavior does not draw a
> distinction between a region made with the mouse (or shift-selection)
> and a region made "normally" (e.g. by C-SPC followed by point motion).
> In previous Emacs releases, a special exception was made for the DEL and
> delete keys.  This exception has now been dropped.

I cannot let you get away with this epistemological conflation.  These
other commands do not act _ON_ the region.  They act _IN_ the region.
I.e., they do their normal thing in a portion of the buffer.  You've
utterly changed the meaning of `delete-character-forward', making it act
ON a region rather than on a character.  The behaviour of DEL and delete
was not previously an exception - they did their normal thing at the
boundary of the region.

> Anyone who argues that DEL ought not to delete a "normal" active region
> should provide a convincing explanation of why DEL should be treated
> differently from other Emacs commands that act on active regions.

See above.  DEL should keep its normal meaning in the presence of a
region, just like most other commands do.

As a matter of interest, in the proposed default configuration, how does
one delete a single character at a boundary of an "active" region?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: draft for DEL key poll

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

Hi Alan,

> I sincerely hope we won't be introducing too many more behaviours
> which are "standard" in modern GUIs.

Yes, I hope we incorporate (or invent) only behaviors that make sense
and improve editing.  And in this concrete case (or, say, comment-dwim,
M-;), I actually like this special behavior.

> > Some Emacs commands perform a certain operation on the region when
> > it is active.  In general, this "act on region" behavior does not
> > draw a distinction between a region made with the mouse (or
> > shift-selection) and a region made "normally" (e.g. by C-SPC
> > followed by point motion).  In previous Emacs releases, a special
> > exception was made for the DEL and delete keys.  This exception has
> > now been dropped.
>
> I cannot let you get away with this epistemological conflation.  These
> other commands do not act _ON_ the region.  They act _IN_ the region.
> delete was not previously an exception - they did their normal thing
> at the boundary of the region.

Well, there's no way to be *not* at the boundary of the region, right?
So there couldn't be any special behavior if at the region boundaries
any command had to act "normally."

> As a matter of interest, in the proposed default configuration, how
> does one delete a single character at a boundary of an "active"
> region?

I deactivate the region (C-g), delete the character (DEL), and
reactivate the region with `C-x C-x'.  But this situation occurs (for
me) much less frequently than the situation where I want to delete the
complete active region, so I'm happy that I can now simply hit DEL
instead of C-w.

Bye,
Tassilo

Re: draft for DEL key poll

[Lennart Borgman]

On Wed, Sep 28, 2011 at 10:26, Tassilo Horn <tassilo@member.fsf.org> wrote:
> Alan Mackenzie <acm@muc.de> writes:
>
> Hi Alan,
>
>> I sincerely hope we won't be introducing too many more behaviours
>> which are "standard" in modern GUIs.
>
> Yes, I hope we incorporate (or invent) only behaviors that make sense
> and improve editing.  And in this concrete case (or, say, comment-dwim,
> M-;), I actually like this special behavior.

So we are into this discussion again. ;-)

Please remember that for most newcommers the standard behaviour is
what makes sense. Whatever you yourself think about that.

Re: draft for DEL key poll

[chad]

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


On Sep 28, 2011, at 12:54 AM, Alan Mackenzie wrote:
> 
> As a matter of interest, in the proposed default configuration, how does
> one delete a single character at a boundary of an "active" region?

If ou want to act on a single character, why did you activate the region?  
(assuming that the region isn't that single character, of course).

*Chad


[-- Attachment #2: Type: text/html, Size: 683 bytes --]

Re: draft for DEL key poll

[Richard Stallman]

    If ou want to act on a single character, why did you activate the region?  

Perhaps because you wanted to go to the other side of it with C-x C-x,
is the usual reason in my case.

Another reason is, you want to do something to the region, so you mark
it, but then you decide to first insert some text at the end of it.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: draft for DEL key poll

[chad]

On Sep 29, 2011, at 3:49 AM, Richard Stallman wrote:

>    If ou want to act on a single character, why did you activate the region?  
> 
> Perhaps because you wanted to go to the other side of it with C-x C-x,
> is the usual reason in my case.
> 
> Another reason is, you want to do something to the region, so you mark
> it, but then you decide to first insert some text at the end of it.

So, only in situations where you explicitly don't want to activate the region?
Does it often happen that you change your mind about activating the 
region? The C-x C-x case happens to me also, but rarely, and I find that
`C-x C-x C-x C-x' is comfortable enough in those cases.

*Chad

Re: draft for DEL key poll

[Andrew W. Nosenko]

On Thu, Sep 29, 2011 at 20:56, chad <yandros@mit.edu> wrote:
>
> On Sep 29, 2011, at 3:49 AM, Richard Stallman wrote:
>
>>    If ou want to act on a single character, why did you activate the region?
>>
>> Perhaps because you wanted to go to the other side of it with C-x C-x,
>> is the usual reason in my case.
>>
>> Another reason is, you want to do something to the region, so you mark
>> it, but then you decide to first insert some text at the end of it.
>
> So, only in situations where you explicitly don't want to activate the region?
> Does it often happen that you change your mind about activating the
> region? The C-x C-x case happens to me also, but rarely, and I find that
> `C-x C-x C-x C-x' is comfortable enough in those cases.

How repeating C-x C-x helps you to deactivate region (and thus help it
to survive after DEL)?  In my case it still to be activated regardless
on the amount of "C-x C-x" repeatings.

About "rarely": do you understand that now, with current defaults, it
is only one way to safe using DEL in the macro -- explicitly mark the
intended to be deleted character by region and only then delete it?
Otherwise there my occur already activated region and you will delete
not the single character but the whole half of buffer.  Just by
occasion and the Murphy Law.

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: draft for DEL key poll

[chad]

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

On Sep 29, 2011, at 4:17 PM, Andrew W. Nosenko wrote:
> On Thu, Sep 29, 2011 at 20:56, chad <yandros@mit.edu> wrote:
>> On Sep 29, 2011, at 3:49 AM, Richard Stallman wrote:
>>> 
>>> Perhaps because you wanted to go to the other side of it with C-x C-x,
>>> is the usual reason in my case. […]
>> 
>> […] The C-x C-x case happens to me also, but rarely, and I find that
>> `C-x C-x C-x C-x' is comfortable enough in those cases.

> How repeating C-x C-x helps you to deactivate region (and thus help it
> to survive after DEL)?  In my case it still to be activated regardless
> on the amount of "C-x C-x" repeatings.

My apologies; I was still using some experimental code that deactivated
the region on any C-x C-x but the first (as a side-effect to allowing a prefix
arg to toggle transient-mark-mode). Mea culpa.

> About "rarely": do you understand that now, with current defaults, it
> is only one way to safe using DEL in the macro -- explicitly mark the
> intended to be deleted character by region and only then delete it?
> Otherwise there my occur already activated region and you will delete
> not the single character but the whole half of buffer.  Just by
> occasion and the Murphy Law.

I assume that you mean keyboard macro here, yes?  This usage had not 
occurred to me, as I use elisp far more often than keyboard macros, and
don't use macros for destructive things like DEL.  Perhaps this is why the 
new code works on delete-char-forward and delete-char-backward but 
explicitly not delete-char?  (I admit that I was puzzled by that choice.)

*Chad





[-- Attachment #2: Type: text/html, Size: 2658 bytes --]

Re: draft for DEL key poll

[Richard Stallman]

    So, only in situations where you explicitly don't want to activate the region?

I don't generally care whether the region is active -- I set
mark-even-if-inactive to t.  I often use C-x C-x to see or adjust the
other side of the region.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: draft for DEL key poll

[Eli Zaretskii]

> Date: Fri, 30 Sep 2011 17:03:36 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> I don't generally care whether the region is active -- I set
> mark-even-if-inactive to t.

t is the default value of that variable nowadays.

Re: draft for DEL key poll

[Andreas Röhler]

Am 30.09.2011 23:22, schrieb Eli Zaretskii:
>> Date: Fri, 30 Sep 2011 17:03:36 -0400
>> From: Richard Stallman<rms@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> I don't generally care whether the region is active -- I set
>> mark-even-if-inactive to t.
>
> t is the default value of that variable nowadays.
>
>

Hi,

sounds like a redundancy for me:

*Non-nil means you can use the mark even when inactive.
This option makes a difference in Transient Mark mode.
When the option is non-nil, deactivation of the mark
turns off region highlighting, but commands that use the mark
behave as if the mark were still active.


IMHO there are two cases to decide:

- if exists a difference between point and mark, ie the region exists

- the region is highlighted or not

two functions resp. variables are enough for indicating this

region-active-p
transient-mark-mode.

all the other stuff introduces rather confusion than being helpful AFAIU

Cheers,

Andreas

Re: draft for DEL key poll

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> (I will also write a poll about completion.)

Such a poll will not be useful.  While tweaks that can be made to the
behavior of the partial completion methods, such as making it treat
hidden buffers better (Bug#9598), such tweaks hardly require a poll.

As for the outright removal of partial completion, I disagree with such
a change; since its introduction in Emacs 23, it has proven to be a
useful feature that does the right thing in almost all circumstances.
It's easy for those who disagree with this feature to disable it.

Re: draft for DEL key poll

[Richard Stallman]

    As for the outright removal of partial completion, I disagree with such
    a change; since its introduction in Emacs 23, it has proven to be a
    useful feature that does the right thing in almost all circumstances.
    It's easy for those who disagree with this feature to disable it.

Let's see what the users think of this change.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Emacs pretest 24.0.90

[Ota, Takaaki]

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

Build fails under mingw environment.  Attached is the log from "make
bootstrap".

-Tak

Sun, 25 Sep 2011 20:57:41 -0700: Chong Yidong <cyd@stupidchicken.com> wrote:

> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
> 
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz
> 
> This is the first pretest for what will become Emacs 24.1.
> See etc/NEWS for a list of changes since Emacs 23.3.
> 
> Please send me an email reporting success or failure on your build
> platform.  Please report any bugs that you come across via
> M-x report-emacs-bugs, or email bug-gnu-emacs@gnu.org.
> For questions, email emacs-devel@gnu.org.
> 
> Thank you for helping to test Emacs.
> 
> 
> Note: this email is also sent via BCC to the list of Emacs pretesters.
> If you are not subscribed to the emacs-devel mailing list, and would
> like to receive these emails about Emacs pretests, send me an email and
> I will add you to the list.
> 

[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 4765 bytes --]

[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
mkdir "oo-spd"
mkdir "oo-spd/i386"
echo oo-spd/i386 > stamp_BLD
gcc -I. -c -gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2     -Ic:/d/pub/emacs/include  -o oo-spd/i386/addsection.o addsection.c
gcc -o oo-spd/i386/addsection.exe \
		   -gdwarf-2 -g3  -mno-cygwin -Lc:/d/pub/emacs/lib oo-spd/i386/addsection.o   -luser32
gcc -I. -c -gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2     -Ic:/d/pub/emacs/include  -o oo-spd/i386/cmdproxy.o cmdproxy.c
gcc -o oo-spd/i386/cmdproxy.exe \
		   -gdwarf-2 -g3  -mno-cygwin -Lc:/d/pub/emacs/lib oo-spd/i386/cmdproxy.o   -luser32
make   -C ../lisp bootstrap-clean
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lisp'
rm /c/d/pub/emacs/emacs-24.0.90/lisp/loaddefs.el
make -w bootstrap-clean-SH
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[2]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lisp'
for dir in . calc calendar emacs-lisp emulation erc eshell gnus international language mail mh-e net nxml org play progmodes textmodes url vc cedet cedet/ede cedet/semantic cedet/srecode cedet/semantic/analyze cedet/semantic/bovine cedet/semantic/decorate cedet/semantic/symref cedet/semantic/wisent term obsolete; do rm -f $dir/*.elc $dir/*/*.elc $dir/*/*/*.elc; done
make[2]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/lisp'
make[1]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/lisp'
make   -C ../src clean
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/src'
rm "s/*.h~" "m/*.h~"
rm: cannot lstat `s/*.h~': No such file or directory
rm: cannot lstat `m/*.h~': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm 
rm: missing operand
Try `rm --help' for more information.
make[1]: [clean] Error 1 (ignored)
rm -r oo-spd
rm: cannot lstat `oo-spd': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm stamp_BLD gl-stamp globals.h
rm: cannot lstat `stamp_BLD': No such file or directory
rm: cannot lstat `gl-stamp': No such file or directory
rm: cannot lstat `globals.h': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm buildobj.h
rm: cannot lstat `buildobj.h': No such file or directory
make[1]: [clean] Error 1 (ignored)
make[1]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/src'
make   -C ../lib-src clean make-docfile
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lib-src'
rm DOC* 
rm: cannot lstat `DOC*': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm ctags.c
rm: cannot lstat `ctags.c': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm -r oo-spd
rm: cannot lstat `oo-spd': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm stamp_BLD
rm: cannot lstat `stamp_BLD': No such file or directory
make[1]: [clean] Error 1 (ignored)
mkdir "oo-spd"
mkdir "oo-spd/i386"
echo oo-spd/i386 > stamp_BLD
gcc -I. -c -gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2     -Ic:/d/pub/emacs/include -DWINDOWSNT -DDOS_NT -DNO_LDAV=1 -DNO_ARCHIVES=1 -DHAVE_CONFIG_H=1 -I../lib -I../nt/inc -I../src -o oo-spd/i386/make-docfile.o make-docfile.c
gcc -I. -c -gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2     -Ic:/d/pub/emacs/include -DWINDOWSNT -DDOS_NT -DNO_LDAV=1 -DNO_ARCHIVES=1 -DHAVE_CONFIG_H=1 -I../lib -I../nt/inc -I../src -o oo-spd/i386/ntlib.o ntlib.c
gcc -o oo-spd/i386/make-docfile.exe  -gdwarf-2 -g3  -mno-cygwin -Lc:/d/pub/emacs/lib oo-spd/i386/make-docfile.o oo-spd/i386/ntlib.o   -ladvapi32
make[1]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/lib-src'
make   -C ../lib clean all
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lib'
make[1]: *** No rule to make target `clean'.  Stop.
make[1]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/lib'
make: *** [bootstrap-gmake] Error 2

Re: Emacs pretest 24.0.90

[Glenn Morris]

"Ota, Takaaki" wrote:

>> Please send me an email reporting success or failure on your build
>> platform.  Please report any bugs that you come across via
>> M-x report-emacs-bugs, or email bug-gnu-emacs@gnu.org.
[...]
> make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lib'
> make[1]: *** No rule to make target `clean'.  Stop.

http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00617.html

Re: Emacs pretest 24.0.90

[Ota, Takaaki]

Thanks for responding to the old news.  It indeed builds now after
adding lib/makefile.w32-in.

-Tak

Mon, 26 Sep 2011 16:58:32 -0700: Glenn Morris <rgm@gnu.org> wrote:

> "Ota, Takaaki" wrote:
> 
> >> Please send me an email reporting success or failure on your build
> >> platform.  Please report any bugs that you come across via
> >> M-x report-emacs-bugs, or email bug-gnu-emacs@gnu.org.
> [...]
> > make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lib'
> > make[1]: *** No rule to make target `clean'.  Stop.
> 
> http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00617.html
> 

RE: Emacs pretest 24.0.90

[Drew Adams]

> Sent: Sunday, September 25, 2011 8:58 PM
> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz

Is there a Windows build available via HTTP?

RE: Emacs pretest 24.0.90

[Drew Adams]

> Sent: Friday, September 30, 2011 5:23 PM
> > Sent: Sunday, September 25, 2011 8:58 PM
> > Emacs pretest 24.0.90 is now available for download via FTP, at the
> > following location:
> >   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz
> 
> Is there a Windows build available via HTTP?

ping.

The last Windows build published by Sean was from 2011-09-19.  I haven't found a
build for the pretest.  Is there one (available using HTTP)?

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/3/2011 10:11 AM, Drew Adams wrote:

> The last Windows build published by Sean was from 2011-09-19.  I haven't found a
> build for the pretest.  Is there one (available using HTTP)?

Sean said he didn't have internet access for a couple of weeks. He will 
provide a build as soon as he is able I assume.

Christoph

RE: Emacs pretest 24.0.90

[Drew Adams]

> > The last Windows build published by Sean was from 
> > 2011-09-19.  I haven't found a build for the pretest.
> > Is there one (available using HTTP)?
> 
> Sean said he didn't have internet access for a couple of 
> weeks. He will provide a build as soon as he is able I assume.

I see.  I guess the pretest will be posted, when available, at
http://alpha.gnu.org/gnu/emacs/pretest/windows/

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/3/2011 5:42 PM, Drew Adams wrote:

> I see.  I guess the pretest will be posted, when available, at
> http://alpha.gnu.org/gnu/emacs/pretest/windows/

That's the plan, I think.

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>> Is there a Windows build available via HTTP?
>
> ping.
>
> The last Windows build published by Sean was from 2011-09-19.  I haven't found a
> build for the pretest.  Is there one (available using HTTP)?

FWIW: lately, I'm able to build Emacs easily on my system (Windows 7).

Here's my simple recipe:

0. Prerequisites:
0.1. Install bzr (if you are going to pull the sources from a bzr branch).
0.2. Install mingw (with the msys package).
0.3. Create a file "mingw-start.cmd" with the content described in [a].

1. Get the sources you want to build from ("bzr pull" or your favorite way).
2. Open a Windows console (cmd.exe).
3. run "cd C:\emacs\trunk\nt". [b].
4. run "configure --without-xpm --without-png --without-jpeg
--without-tiff --without-gif".
5. run "make bootstrap". [c].
6. run "make info". [c]
7. run "make install". [c]

That's all.  I hope it helps.


--- Footnotes: ---

[a] File "mingw-console.cmd":
------ begin of file -----------------------------
@set PATHMINGW=C:\MinGW\bin;C:\MinGW\msys\1.0\bin
@set PATHBAZAAR=C:\Program Files (x86)\Bazaar
@set PATH=%PATHMINGW%;%PATHBAZAAR%;%PATH%
@cmd
------ end of file -------------------------------
Substitute:
* "C:\MinGW" with the directory where you've installed mingw(+msys).
* "C:\Program Files (x86)\Bazaar" with the directory where you've
installed bazaar.

[b] Substitute "C:\emacs\trunk" with the directory where you've got
the emacs source tree.

[c] This starts a make process.  Unfortunately, sometimes the process
stops because it spawns a child "cmd.exe" session (I don't know why).
In these cases, I've seen that the solution is simply to exit from
that session (run "exit").  As many of you know, this problem can be
solved if you substitute msys with various utilities from the GnuWin
project.  IMO this is a pity, because msys is well integrated into the
mingw-get package manager, and thus seems to be a better alternative.

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 12:18:19 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
> 
> [c] This starts a make process.  Unfortunately, sometimes the process
> stops because it spawns a child "cmd.exe" session (I don't know why).

It's a problem with the MSYS Make and MSYS Bash.  They convert
command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
fails miserably when the original command-line argument is not a file
name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
nt/INSTALL, which doesn't recommend MSYS for this very reason.

> IMO this is a pity, because msys is well integrated into the
> mingw-get package manager, and thus seems to be a better alternative.

Did you try the MinGW installer, here:

   http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20110802/mingw-get-inst-20110802.exe/download

I never tried it, but perhaps it also does a good job, and will give
you a working MinGW environment without MSYS.

Re: Emacs pretest 24.0.90

[Dani Moncayo]

On Wed, Oct 12, 2011 at 12:25, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Did you try the MinGW installer, here:
>
>   http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20110802/mingw-get-inst-20110802.exe/download
>

Yes, that is the installer (and the version) I used to install my
current MinGW environment.

> I never tried it, but perhaps it also does a good job, and will give
> you a working MinGW environment without MSYS.

But the Emacs build process needs some utilities like "rm", "cp" or
"make" that aren't part of MinGW but MSYS (the are in the
"MinGW\msys\1.0\bin" directory).  So, I would have to borrow them from
another place (e.g. GnuWin).

Therefore, what I say is that it would be great if the version of
"make" that comes with MSYS didn't have the problem I (and you) said,
because then, we'd have a easy to use and monolithic environment to
build Emacs on Windows.

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Wed, Oct 12, 2011 at 13:28, Dani Moncayo <dmoncayo@gmail.com> wrote:

> Therefore, what I say is that it would be great if the version of
> "make" that comes with MSYS didn't have the problem I (and you) said,

But MSYS' make does not have any "problem". It works well for its
purpose: to build MinGW packages. MSYS is not, and has never been,
intended as a generic "Unix tools package for Windows". That's what
GnuWin32 is for.

    Juanma

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>> Therefore, what I say is that it would be great if the version of
>> "make" that comes with MSYS didn't have the problem I (and you) said,
>
> But MSYS' make does not have any "problem". It works well for its
> purpose: to build MinGW packages. MSYS is not, and has never been,
> intended as a generic "Unix tools package for Windows". That's what
> GnuWin32 is for.

From "http://www.mingw.org/wiki/MSYS":

  MSYS is a collection of GNU utilities such as bash, make, gawk and
grep to allow
  building of applications and programs which depend on traditionally UNIX tools
  to be present. It is intended to supplement MinGW and the
deficiencies of the cmd shell.

This description doesn't seems to be the same as yours:  "to allow
building of applications and programs" not "to build MinGW packages".

As I said, I'm able to successfully build the latest Emacs trunk on
Windows using exclusively MinGW and MSYS, which are both conveniently
integrated into a package manager (mingw-get).  The only obstacle is
the one already explained, which apparently has a very simple
workaround (already explained too).

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Wed, Oct 12, 2011 at 14:07, Dani Moncayo <dmoncayo@gmail.com> wrote:

> From "http://www.mingw.org/wiki/MSYS":
>
>  MSYS is a collection of GNU utilities such as bash, make, gawk and
> grep to allow
>  building of applications and programs which depend on traditionally UNIX tools
>  to be present. It is intended to supplement MinGW and the
> deficiencies of the cmd shell.

In other words, it would be perhaps useful to build a POSIX Emacs on
Windows, less so to build the Emacs port, which doesn't really depend
on "traditional UNIX tools" apart of make and a few simple file tools
like mv and cp. The description you quote is talking about autoconf,
etc.

That said, MSYS was created to build MinGW tools. If they now
advertise it as a general tool to build "programs which depend on
traditionally UNIX tools", they are competing with Cygwin...

> As I said, I'm able to successfully build the latest Emacs trunk on
> Windows using exclusively MinGW and MSYS

Which means that you are using MinGW, and a few tools from MSYS. If
that works for you, I'm glat to hear it. But I wouldn't recommend it
to anyone.

Just out of curiosity, are you able to build the Emacs info files with
MSYS' makeinfo?

    Juanma

Re: Emacs pretest 24.0.90

[Dani Moncayo]

> Just out of curiosity, are you able to build the Emacs info files with
> MSYS' makeinfo?

Yes.  "make info" apparently runs successfully, and I can browse from
my Emacs the manuals shipped with it.  Perfectly well.


-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

> Yes.  "make info" apparently runs successfully, and I can browse from
> my Emacs the manuals shipped with it.  Perfectly well.

I'm assuming this will be with a recent release of MinGW/MSYS, and so
makeinfo 4.13. Curious.

    Juanma

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>> Yes.  "make info" apparently runs successfully, and I can browse from
>> my Emacs the manuals shipped with it.  Perfectly well.
>
> I'm assuming this will be with a recent release of MinGW/MSYS, and so
> makeinfo 4.13. Curious.

Yes:
  C:\Users\Dani>makeinfo --version
  makeinfo (GNU texinfo) 4.13


-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 12 Oct 2011 14:29:10 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, drew.adams@oracle.com, 
> 	emacs-devel@gnu.org
> 
> > Yes.  "make info" apparently runs successfully, and I can browse from
> > my Emacs the manuals shipped with it.  Perfectly well.
> 
> I'm assuming this will be with a recent release of MinGW/MSYS, and so
> makeinfo 4.13. Curious.

There's nothing wrong with makeinfo 4.13 on Windows.  It's just that
the binary provided by GnuWin32 is broken.

If you have MSYS, you can build Texinfo 4.13 yourself.  I did that,
and the resulting makeinfo.exe "just works".  I don't remember if I
needed any Windows specific changes to build it.  (My primary interest
was to have a working info.exe, which does need changes.  I'm almost
there, btw.)

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Wed, Oct 12, 2011 at 15:19, Eli Zaretskii <eliz@gnu.org> wrote:

> There's nothing wrong with makeinfo 4.13 on Windows.  It's just that
> the binary provided by GnuWin32 is broken.

I remember having trouble running the MSYS one, too. But it was a
while ago, and as my current setup works, I don't really want to go
trying new releases or compiling my own unless forced to.

    Juanma

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 14:07:46 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, drew.adams@oracle.com, 
> 	emacs-devel@gnu.org
> 
> >From "http://www.mingw.org/wiki/MSYS":
> 
>   MSYS is a collection of GNU utilities such as bash, make, gawk and
> grep to allow
>   building of applications and programs which depend on traditionally UNIX tools
>   to be present. It is intended to supplement MinGW and the
> deficiencies of the cmd shell.
> 
> This description doesn't seems to be the same as yours:  "to allow
> building of applications and programs" not "to build MinGW packages".

Nevertheless, Juanma is right.  To be more precise, MSYS is a package
to build MinGW ports of software whose build needs to run the Posix
`configure' shell script and whose Makefiles require a Posix shell.

Emacs is not in that category, because it has a Windows configure.bat
script to configure it and Windows makefile.w32-in Makefiles that do
not require a Posix shell.

Re: Emacs pretest 24.0.90

[Stefan Monnier]

> Emacs is not in that category, because it has a Windows configure.bat
> script to configure it and Windows makefile.w32-in Makefiles that do
> not require a Posix shell.

Would MinGW+MSYS work to build Emacs if Emacs adapted its autoconf
script to handle Windows as well?


        Stefan

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dani Moncayo <dmoncayo@gmail.com>,  lekktu@gmail.com,  cyd@stupidchicken.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Wed, 12 Oct 2011 08:46:50 -0400
> 
> > Emacs is not in that category, because it has a Windows configure.bat
> > script to configure it and Windows makefile.w32-in Makefiles that do
> > not require a Posix shell.
> 
> Would MinGW+MSYS work to build Emacs if Emacs adapted its autoconf
> script to handle Windows as well?

Yes, it will.

However, installing MSYS means installing a large number of programs
and DLLs, and people who already have a working MinGW development
environment that doesn't include MSYS will need to be extra careful
when doing such an installation, to avoid breaking their main
development environment.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 13:28:48 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: cyd@stupidchicken.com, drew.adams@oracle.com, emacs-devel@gnu.org
> 
> On Wed, Oct 12, 2011 at 12:25, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Did you try the MinGW installer, here:
> >
> >   http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20110802/mingw-get-inst-20110802.exe/download
> >
> 
> Yes, that is the installer (and the version) I used to install my
> current MinGW environment.
> 
> > I never tried it, but perhaps it also does a good job, and will give
> > you a working MinGW environment without MSYS.
> 
> But the Emacs build process needs some utilities like "rm", "cp" or
> "make" that aren't part of MinGW but MSYS (the are in the
> "MinGW\msys\1.0\bin" directory).

Are you sure?  This page

  http://sourceforge.net/projects/mingw/files/MinGW/make/

claims that "make" _is_ included.

"rm" and "cp" are part of Coreutils, a single package that you need to
download from GnuWin32 (it may require a few DLLs that are used by
Coreutils).

> Therefore, what I say is that it would be great if the version of
> "make" that comes with MSYS didn't have the problem I (and you) said,
> because then, we'd have a easy to use and monolithic environment to
> build Emacs on Windows.

The MSYS Make cannot not have this problem, because file-name
translation is at the core of MSYS operation.  Without it, most of
MSYS's raison d'etre is gone.

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/12/2011 4:25 AM, Eli Zaretskii wrote:

>> [c] This starts a make process.  Unfortunately, sometimes the process
>> stops because it spawns a child "cmd.exe" session (I don't know why).
>
> It's a problem with the MSYS Make and MSYS Bash.  They convert
> command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
> fails miserably when the original command-line argument is not a file
> name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
> nt/INSTALL, which doesn't recommend MSYS for this very reason.

I see this problem even without using MSYS. I am using TDM-GCC with gcc 
4.5.2 and make 3.82 and GnuWin tools. Every so often my nightly build 
stalls and fails with an `Access denied' error. It looks like it spawns 
a child cmd.exe right before. I googled and someone said make might trip 
up during parallel compilation so I force it with `-j 1' for testing. It 
still fails now and then. I will capture the exact error message and the 
context next time it happens.

Christoph

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 06:52:09 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: emacs-devel@gnu.org, dmoncayo@gmail.com
> 
> On 10/12/2011 4:25 AM, Eli Zaretskii wrote:
> 
> >> [c] This starts a make process.  Unfortunately, sometimes the process
> >> stops because it spawns a child "cmd.exe" session (I don't know why).
> >
> > It's a problem with the MSYS Make and MSYS Bash.  They convert
> > command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
> > fails miserably when the original command-line argument is not a file
> > name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
> > nt/INSTALL, which doesn't recommend MSYS for this very reason.
> 
> I see this problem even without using MSYS. I am using TDM-GCC with gcc 
> 4.5.2 and make 3.82 and GnuWin tools. Every so often my nightly build 
> stalls and fails with an `Access denied' error.

I think this is an entirely different problem.  The problem with MSYS
manifests itself in a cmd.exe window that opens and sits there waiting
for input.

> It looks like it spawns 
> a child cmd.exe right before. I googled and someone said make might trip 
> up during parallel compilation so I force it with `-j 1' for testing. It 
> still fails now and then. I will capture the exact error message and the 
> context next time it happens.

Yes, more details are needed to analyze this.

Re: Emacs pretest 24.0.90

[Dave Abrahams]

on Wed Oct 12 2011, Eli Zaretskii <eliz-AT-gnu.org> wrote:

>> Date: Wed, 12 Oct 2011 12:18:19 +0200
>
>> From: Dani Moncayo <dmoncayo@gmail.com>
>> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
>> 
>> [c] This starts a make process.  Unfortunately, sometimes the process
>> stops because it spawns a child "cmd.exe" session (I don't know why).
>
> It's a problem with the MSYS Make and MSYS Bash.  They convert
> command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
> fails miserably when the original command-line argument is not a file
> name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
> nt/INSTALL, which doesn't recommend MSYS for this very reason.

Most options in Windows work if you use "-" instead of "/".  If you use
"-" in your Makefile you can avoid triggering this issue.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Dave Abrahams <dave@boostpro.com>
> Date: Wed, 12 Oct 2011 10:21:18 -0400
> 
> > It's a problem with the MSYS Make and MSYS Bash.  They convert
> > command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
> > fails miserably when the original command-line argument is not a file
> > name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
> > nt/INSTALL, which doesn't recommend MSYS for this very reason.
> 
> Most options in Windows work if you use "-" instead of "/".  If you use
> "-" in your Makefile you can avoid triggering this issue.

Not in this case: cmd.exe does not accept -c, only /c.

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>>> Is there a Windows build available via HTTP?
>>
>> ping.
>>
>> The last Windows build published by Sean was from 2011-09-19.  I haven't found a
>> build for the pretest.  Is there one (available using HTTP)?
>

Here's my recipe again, with a couple of fixes (in steps #0.3 and #2):

0. Prerequisites:
0.1. Install bzr (if you are going to pull the sources from a bzr branch).
0.2. Install mingw (with the msys package).
0.3. Create a file "mingw-console.cmd" with the content described in [a].

1. Get the sources you want to build from ("bzr pull" or your favorite way).
2. Invoke the "mingw-console.cmd" script (to open a console where
we'll run the following commands).
3. run "cd C:\emacs\trunk\nt". [b].
4. run "configure --without-xpm --without-png --without-jpeg
--without-tiff --without-gif".
5. run "make bootstrap". [c].
6. run "make info". [c]
7. run "make install". [c]

That's all.  I hope it helps.


--- Footnotes: ---

[a] File "mingw-console.cmd":
------ begin of file -----------------------------
@set PATHMINGW=C:\MinGW\bin;C:\MinGW\msys\1.0\bin
@set PATHBAZAAR=C:\Program Files (x86)\Bazaar
@set PATH=%PATHMINGW%;%PATHBAZAAR%;%PATH%
@cmd
------ end of file -------------------------------
Substitute:
* "C:\MinGW" with the directory where you've installed mingw(+msys).
* "C:\Program Files (x86)\Bazaar" with the directory where you've
installed bazaar.

[b] Substitute "C:\emacs\trunk" with the directory where you've got
the emacs source tree.

[c] This starts a make process.  Unfortunately, sometimes the process
stops because it spawns a child "cmd.exe" session (I don't know why).
In these cases, I've seen that the solution is simply to exit from
that session (run "exit").  As many of you know, this problem can be
solved if you substitute msys with various utilities from the GnuWin
project.  IMO this is a pity, because msys is well integrated into the
mingw-get package manager, and thus seems to be a better alternative.

-- 
Dani Moncayo

RE: Emacs pretest 24.0.90

[Drew Adams]

> > The last Windows build published by Sean was from 
> > 2011-09-19.  I haven't found a build for the pretest.
> > Is there one (available using HTTP)?
> 
> FWIW: lately, I'm able to build Emacs easily on my system (Windows 7).

So please publish it at 
http://alpha.gnu.org/gnu/emacs/pretest/windows/

In the past, GNU Emacs has always posted a Windows binary for the pretest,
typically a few days after the pretest announcement.  It's now been almost a
month since the last binary was made available, and a couple weeks since the
pretest was announced (9/25).

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>> > The last Windows build published by Sean was from
>> > 2011-09-19.  I haven't found a build for the pretest.
>> > Is there one (available using HTTP)?
>>
>> FWIW: lately, I'm able to build Emacs easily on my system (Windows 7).
>
> So please publish it at
> http://alpha.gnu.org/gnu/emacs/pretest/windows/

I have a zip file with my current build (emacs-trunk-r106057; without
image support).

I would not mind to upload it (if people wants and someone gives me
ftp access), but I think that the lack of image support makes it a bad
candidate for publishing.

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/12/2011 7:48 AM, Drew Adams wrote:

>> FWIW: lately, I'm able to build Emacs easily on my system (Windows 7).
>
> So please publish it at
> http://alpha.gnu.org/gnu/emacs/pretest/windows/
>
> In the past, GNU Emacs has always posted a Windows binary for the pretest,
> typically a few days after the pretest announcement.  It's now been almost a
> month since the last binary was made available, and a couple weeks since the
> pretest was announced (9/25).

Sean, who has been providing the weekly builds and would have provided 
the pretest build right away I am sure, does not have access to internet 
right now.

Also, any Windows builds to be published, should be build with the 
`mingw32-make dist' target and all features that are usually provided by 
the weekly builds (image support, gnutls etc.).

If Chong or Stephan want to send me instructions on how to upload the 
builds I will upload the pretest build and weekly builds until Sean is back.

Christoph

Re: Emacs pretest 24.0.90

[Stefan Monnier]

> If Chong or Stephan want to send me instructions on how to upload the builds
> I will upload the pretest build and weekly builds until Sean is back.

That would be great.  But I don't know how the upload process
works.  Chong?


        Stefan

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/12/2011 9:33 PM, Stefan Monnier wrote:
>> If Chong or Stephan want to send me instructions on how to upload the builds
>> I will upload the pretest build and weekly builds until Sean is back.
>
> That would be great.  But I don't know how the upload process
> works.  Chong?

I think Jason used to do this, no? CC'ed.

Christoph

Re: Emacs pretest 24.0.90

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If Chong or Stephan want to send me instructions on how to upload the builds
>> I will upload the pretest build and weekly builds until Sean is back.
>
> That would be great.  But I don't know how the upload process
> works.  Chong?

See step 11 in admin/make-tarball.  Except the files needs to go in the
windows/ subdirectory.

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/13/2011 10:15 AM, Chong Yidong wrote:
> Stefan Monnier<monnier@iro.umontreal.ca>  writes:
>
>>> If Chong or Stephan want to send me instructions on how to upload the builds
>>> I will upload the pretest build and weekly builds until Sean is back.
>>
>> That would be great.  But I don't know how the upload process
>> works.  Chong?
>
> See step 11 in admin/make-tarball.  Except the files needs to go in the
> windows/ subdirectory.

Thanks. I will have a look there.

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/13/2011 4:54 PM, Christoph Scholtes wrote:
> On 10/13/2011 10:15 AM, Chong Yidong wrote:
>> See step 11 in admin/make-tarball. Except the files needs to go in the
>> windows/ subdirectory.
>
> Thanks. I will have a look there.

As soon as my GPG key is acknowledged by the GNU ftp folks, I will 
upload the Windows pretest build.

Christoph

RE: Emacs pretest 24.0.90

[Drew Adams]

> If Chong or Stephan want to send me instructions on how to upload the 
> builds I will upload the pretest build and weekly builds 
> until Sean is back.

That would be great.  Thanks.

RE: Emacs pretest 24.0.90

[Drew Adams]

> c> If Chong or Stephan want to send me instructions on how to 
> c> upload the builds I will upload the pretest build and weekly
> c> builds until Sean is back.
d> 
d> That would be great.  Thanks.

That was a while ago.  Any progress?

d>> In the past, GNU Emacs has always posted a Windows binary for 
d>> the pretest, typically a few days after the pretest announcement.
d>> It's now been almost a month since the last binary was made
d>> available, and a couple weeks since the pretest was announced
d>> (9/25).

It's now been a month since the last Windows binary (9/19), and several weeks
since the pretest was announced (9/25).

Still no Windows binary.

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/18/2011 11:15 AM, Drew Adams wrote:

> It's now been a month since the last Windows binary (9/19), and several weeks
> since the pretest was announced (9/25).
>
> Still no Windows binary.

My GPG key was acknowledged by the GNU ftp people today. I am working on 
the pretest build right now. I will post an announcement to the usual 
places when it is up on the ftp site.

Thank you for the patience.

Christoph

RE: Emacs pretest 24.0.90

[Drew Adams]

> > It's now been a month since the last Windows binary (9/19), 
> > and several weeks since the pretest was announced (9/25).
> >
> > Still no Windows binary.
> 
> My GPG key was acknowledged by the GNU ftp people today.
> I am working on the pretest build right now. I will post
> an announcement to the usual places when it is up on the
> ftp site.  Thank you for the patience.

Good to hear.  Thanks.

Re: Emacs pretest 24.0.90

[Dani Moncayo]

> Also, any Windows builds to be published, should be build with the
> `mingw32-make dist' target and all features that are usually provided by the
> weekly builds (image support, gnutls etc.).

If it is possible, I'd like to know the exact steps involved in such
weekly builds (in order to learn and try to reproduce them in my
system).

TIA.

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Thu, Oct 13, 2011 at 16:28, Dani Moncayo <dmoncayo@gmail.com> wrote:

> If it is possible, I'd like to know the exact steps involved in such
> weekly builds (in order to learn and try to reproduce them in my
> system).

nt/INSTALL should have all required information. If not, please file a
bug detailing what is missing.

    Juanma

Re: Emacs pretest 24.0.90

[nabil-82]

seewhydee wrote:
> 
> Emacs pretest 24.0.90 is now available for download via FTP, at the
> Thank you for helping to test Emacs.
> 
1.) I couldn't install emacs-24.0.90 properly on my notebook - I use Ubuntu
10.04 LTS.
./configure and then make worked. And I could/can run emacs 24 from the
src-directory.

But after "make install" I got 2 Errors:
cd /home/nab/emacs-24.0.90/doc/misc; makeinfo ert.texi
/bin/sh: makeinfo: not found
make[2]: *** [../../info/ert] Fehler 127 /* Fehler is german and means error
*/
make[2]: Verlasse Verzeichnis '/home/nab/emacs-24.0.90/doc/misc' /* verlasse
= leave, Verzeichnis = directory */
make[1]: *** [info-real] Fehler 2
make[1]: Verlasse Verzeichnis '/home/nab/emacs-24.0.90'
make: *** [info] Fehler 2 

2.) I don't if this is relevant. Because I could not complete the
installtion as I wrote... Maybe it's a bug?
: 
Arabic text ist written correctly R2L and also  the accents
(=diacritcs=tashkeel).
But the arabic characters don't appear connected as they should. I tested
several fonts.

 
 

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

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Fri, 7 Oct 2011 12:25:24 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> But after "make install" I got 2 Errors:
> cd /home/nab/emacs-24.0.90/doc/misc; makeinfo ert.texi
> /bin/sh: makeinfo: not found
> make[2]: *** [../../info/ert] Fehler 127 /* Fehler is german and means error
> */
> make[2]: Verlasse Verzeichnis '/home/nab/emacs-24.0.90/doc/misc' /* verlasse
> = leave, Verzeichnis = directory */
> make[1]: *** [info-real] Fehler 2
> make[1]: Verlasse Verzeichnis '/home/nab/emacs-24.0.90'
> make: *** [info] Fehler 2 

You don't have the Texinfo package installed, but that package should
not be needed for building and installing a pretest.  There's already
a file info/ert in the tarball, and it is newer than
doc/misc/ert.texi.

I think the problem is in doc/misc/Makefile.in in this line:

  $(infodir)/ert: ert.texi $(infodir)

$(infodir) should not be a prerequisite of ert.  If you remove
$(infodir) from this line and re-run "configure", does "make install"
run to completion without problems?

> Arabic text ist written correctly R2L and also  the accents
> (=diacritcs=tashkeel).
> But the arabic characters don't appear connected as they should. I tested
> several fonts.

You are missing several libraries that are needed for Arabic shaping.
Here's an excerpt from the file INSTALL that describes these
libraries; you need to install all of the libraries mentioned below to
have Arabic shaping:

  * Complex Text Layout support libraries

  Emacs needs the optional libraries "m17n-db", "libm17n-flt", "libotf"
  to correctly display such complex scripts as Indic and Khmer.
  On some systems, particularly GNU/Linux, these libraries may be
  already present or available as additional packages.  Note that if
  there is a separate `dev' or `devel' package, for use at compilation
  time rather than run time, you will need that as well as the
  corresponding run time package; typically the dev package will contain
  header files and a library archive.  Otherwise, you can download and
  build libraries from sources.

  The sources of these libraries are available by anonymous CVS from
  cvs.m17n.org.

      % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n login
      % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n co m17n-db
      % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n co m17n-lib
      % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n co libotf

  For m17n-lib, if you have problems with making the whole package
  because you lack some other packages on which m17n-lib depends, try to
  configure it with the option "--without-gui".

Re: Emacs pretest 24.0.90

[nabil-82]

I respect the etiquette - but thanks.

It worked. I've installed the packages (Texinfo and the others) und
reinstalled emacs 24. (So, I didn't change anything in 
doc/misc/Makefile.in)



But there is another thing - not a bug. After choosing the
arabic-input-metho I can't put the "eastern-arabic-digits". I get the arabic
ones (so they are called). But in the (eastern) arabic countries they're not
used so often "eastern-arabic" ones. 
arabic: 0 1 2 3 ...
"eastern-arabic": 
٠‎ - ١‎ - ٢‎ - ٣‎ - ٤‎ - ٥‎ - ٦‎ - ٧‎ - ٨‎ - ٩
http://en.wikipedia.org/wiki/Eastern_Arabic_numerals

What I did: I've changed leim/quail/arabic.el  (put the 10 rules for the
eastern arabic digits)
It works - now. Could I have complications later? Is there a better
solution?



Eli Zaretskii wrote:
> 
> You don't have the Texinfo package installed, but that package should
> not be needed for building and installing a pretest.  There's already
> a file info/ert in the tarball, and it is newer than
> doc/misc/ert.texi.
> 
> I think the problem is in doc/misc/Makefile.in in this line:
> 
>   $(infodir)/ert: ert.texi $(infodir)
> 
> 
> 

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

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Sat, 8 Oct 2011 09:38:23 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> After choosing the
> arabic-input-metho I can't put the "eastern-arabic-digits". I get the arabic
> ones (so they are called). But in the (eastern) arabic countries they're not
> used so often "eastern-arabic" ones. 
> arabic: 0 1 2 3 ...
> "eastern-arabic": 
> ٠‎ - ١‎ - ٢‎ - ٣‎ - ٤‎ - ٥‎ - ٦‎ - ٧‎ - ٨‎ - ٩
> http://en.wikipedia.org/wiki/Eastern_Arabic_numerals
> 
> What I did: I've changed leim/quail/arabic.el  (put the 10 rules for the
> eastern arabic digits)
> It works - now. Could I have complications later?

No, I wouldn't expect complications.

> Is there a better solution?

You could type the arabic digits after turning off the input method,
i.e.

  C-\
  type something in Arabic
  C-\
  type digits
  C-\
  type more Arabic

Re: Emacs pretest 24.0.90

[nabil-82]

I think my last Email wasn't clea: I need the eastern-arabic digits. But the
arabic-input-method use the arabic digits, not the eastern ones. That's why
I changed arabic.el.
(And C-\ would not help)

Eli Zaretskii wrote:
> 
> 
>> arabic: 0 1 2 3 ...
>> "eastern-arabic": 
>> ٠‎ - ١‎ - ٢‎ - ٣‎ - ٤‎ - ٥‎ - ٦‎ - ٧‎ - ٨‎ - ٩
>> http://en.wikipedia.org/wiki/Eastern_Arabic_numerals
>> Is there a better solution?
> 
> You could type the arabic digits after turning off the input method,
> i.e.
> 
>   C-\
>   type something in Arabic
>   C-\
>   type digits
>   C-\
>   type more Arabic
> 
> 
> 
> 

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

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Sun, 9 Oct 2011 06:02:50 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> 
> I think my last Email wasn't clea: I need the eastern-arabic digits. But the
> arabic-input-method use the arabic digits, not the eastern ones. That's why
> I changed arabic.el.

Sorry, my misunderstanding.  Feel free to submit your change to
arabic.el for inclusion in Emacs.

Re: Emacs pretest 24.0.90

[Kenichi Handa]

In article <32615869.post@talk.nabble.com>, nabil-82 <sjanjal@web.de> writes:

> But there is another thing - not a bug. After choosing the
> arabic-input-metho I can't put the "eastern-arabic-digits". I get the arabic
> ones (so they are called). But in the (eastern) arabic countries they're not
> used so often "eastern-arabic" ones. 
> arabic: 0 1 2 3 ...
> "eastern-arabic": 
> ٠‎ - ١‎ - ٢‎ - ٣‎ - ٤‎ - ٥‎ - ٦‎ - ٧‎ - ٨‎ - ٩
> http://en.wikipedia.org/wiki/Eastern_Arabic_numerals

> What I did: I've changed leim/quail/arabic.el  (put the 10 rules for the
> eastern arabic digits)
> It works - now. Could I have complications later? Is there a better
> solution?

With that, when you install a new version of Emacs, that
file will be overwritten.  If you want to avoid that, one
way is to define only additional rules in your .emacs as
below:

(quail-use-package "arabic" "quail/arabic")
(quail-define-rules
 ("1" ?١)
 ...)

By the way, if your request is a common one, it is better
that we add the rules for eastern-arabic digits to "arabic"
input method and provide a customizable variable to select
which kind of digits to input.

How the other arabic input methods work?

---
Kenichi Handa
handa@m17n.org

Re: Emacs pretest 24.0.90

[nabil-82]

"Kenichi Handa" writes:

> (quail-use-package "arabic" "quail/arabic")
> (quail-define-rules
> ("1" ?١)
> ...)
Thanks for the tip.

> By the way, if your request is a common one, it is better
> that we add the rules for eastern-arabic digits to "arabic"
> input method and provide a customizable variable to select
> which kind of digits to input.
I think it's a common one! So if it could be possible to add an
arabic-eastern-input-method it would be great.

----
After testing the arabic input method I found another problem.  It's not
emacs-specific. I have it with EVERY bidi-editor in Dos or Unix!  And maybe
a lot of people will not see any problem and say: "That's what I want!"

If I type '1' then '2'  in a "L2R paragraph" I get "12" - as expected of
course.

But if do this with in a "R2L paragraph" (I've tried it in arabic and
hebrew) I get on the scren "12". But this is not "normal". Because the
logical order is 1 then 2. And I'm writing from right to left. So the 1
should be on the right and 2 the should be on the left. So I think "21"
should be correct (for me).

It's disturbing. Because the typing direction for characters is r2l and for
digits is l2r!

And if you have a number at the begin of a line (in a R2L paragraph) let's
say "12" (twelve!) . 2 seems to be the first character! But the first
character (by Ctrl-a) is "1".

As I said you have this problem with every editor. And I see that it is
easier to make it as I think it should be: ALWAYS from right to left,  also
for digits and not only for characters - in the R2L-mode. So they must be a
reason...?

(vim can't bidi. Maybe that's why you don't have this effect there if you
type arabic or hebrew..)
-- 
View this message in context: http://old.nabble.com/Emacs-pretest-24.0.90-tp32537865p32638171.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 06:04:31 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> After testing the arabic input method I found another problem.  It's not
> emacs-specific. I have it with EVERY bidi-editor in Dos or Unix!  And maybe
> a lot of people will not see any problem and say: "That's what I want!"
> 
> If I type '1' then '2'  in a "L2R paragraph" I get "12" - as expected of
> course.
> 
> But if do this with in a "R2L paragraph" (I've tried it in arabic and
> hebrew) I get on the scren "12". But this is not "normal". Because the
> logical order is 1 then 2. And I'm writing from right to left. So the 1
> should be on the right and 2 the should be on the left. So I think "21"
> should be correct (for me).

What you see is correct behavior according to UBA, the Unicode
Bidirectional Algorithm that Emacs implements (as do other bidi-aware
applications).  1, 2, 3, etc. are the so-called "European Numbers",
and they are always displayed left to right, even in a right-to-left
paragraph.  If you want to have it otherwise, you will have to enclose
the numbers in a "right-to-left override", by typing the RIGHT-TO-LEFT
OVERRIDE character before the group of digits and the POP DIRECTIONAL
FORMATTING character after them.

> As I said you have this problem with every editor. And I see that it is
> easier to make it as I think it should be: ALWAYS from right to left,  also
> for digits and not only for characters - in the R2L-mode. So they must be a
> reason...?

The reason is the UBA, it mandates this behavior.  I don't read Arabic
(unfortunately), so I cannot comment on how this behavior fits or
doesn't fit the accepted practice.

Re: Emacs pretest 24.0.90

[nabil-82]

"Eli Zaretskii">
> 1, 2, 3, etc. are the so-called "European Numbers", and they are always
> displayed left to right, even in > a right-to-left paragraph. 
I have the same "problem" if I use the eastern-arab-digits.


> The reason is the UBA, it mandates this behavior.  I don't read Arabic
> (unfortunately), so I cannot comment on how this behavior fits or
> doesn't fit the accepted practice.

You have the same behavior by hebrew. 
 If you have "12" at the begin of a line in a hebrew paragraph. So you SEE
the '2' is first symbol on the right and you're writing from right 2 left:
so it should be the first symbol - but it isn't, it's the second. And moving
the cursor is confusing. It makes the jumps by the begin and end of every
number. 
-- 
View this message in context: http://old.nabble.com/Emacs-pretest-24.0.90-tp32537865p32639893.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 09:58:54 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> 
> "Eli Zaretskii">
> > 1, 2, 3, etc. are the so-called "European Numbers", and they are always
> > displayed left to right, even in > a right-to-left paragraph. 
> I have the same "problem" if I use the eastern-arab-digits.

Yes.  Again, the UBA mandates that.  European numbers and Arabic
numbers (what you call eastern-arab-digits) behave almost the same as
far as the UBA is concerned.  There are differences between them, but
they are very minor.

> You have the same behavior by hebrew. 

But in Hebrew this is expected: numbers are always displayed
left-to-right, no matter if the paragraph is L2R or R2L.

> And moving the cursor is confusing. It makes the jumps by the begin
> and end of every number.

Cursor motion in Emacs is in logical order.  I know that some people
find this confusing, but at least some bidi-aware applications out
there do the same.  It should be possible (although not trivial) to
add visual-order cursor motion to Emacs, but logical-order movement is
a must, and so it was implemented first.

Re: Emacs pretest 24.0.90

[Glenn Morris]

Eli Zaretskii wrote:

> I think the problem is in doc/misc/Makefile.in in this line:
>
>   $(infodir)/ert: ert.texi $(infodir)

I think you're right; fixed in trunk.