(no subject)

(no subject)

[Eli Zaretskii]

	 Tak Ota on Sat, 23 Feb 2002 08:11:49 -0800 (PST))
Subject: Re: ctext-pre-write-conversion barfs
Reply-to: Eli Zaretskii <eliz@is.elta.co.il>
References: <20020222.225355.01365596.Takaaki.Ota@am.sony.com>
	    <9743-Sat23Feb2002104842+0200-eliz@is.elta.co.il> <20020223.081149.60852929.Takaaki.Ota@am.sony.com>
--text follows this line--
> Date: Sat, 23 Feb 2002 08:11:49 -0800 (PST)
> From: Tak Ota <Takaaki.Ota@am.sony.com>
> 
> BTW, I just now tried to save this buffer and noticed that
> ctext-pre-write-conversion was invoked.  It is called 3 times for
> each save-buffer.  Here is the output from describe-coding-system.
> 
> Coding system for saving this buffer:
>   x -- ctext-unix

Could you please find out how come the buffer's encoding got set to
ctext-unix?  It's a very unusual coding system for buffers.
Compound-text is normally used for X selections only.

The reason I'm asking you to look into this is that the assumption
behind the code I wrote for the ctext extensions is that ctext is not
normally used for file I/O.  There are limitations of the pre-write
and post-read conversions that make the modified ctext coding system
inappropriate for reading and writing text to/from multibyte buffers.
If ctext is used for file I/O, I will have to revert the decision to
call the new encoding `ctext', and will find some other name.

So please look into this.  Thanks in advance.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: (no subject)

[Tak Ota]

Yamamoto-san,

We find that there is a small conflict in a recent change made to the
developer version of emacs with the coding system used in Mew package.

Could you answer to the following question?  What I can tell is
mew-mule3.el defines as:

;; ctext for consistency --unibyte, -unix for XEmacs's ^M
(defvar mew-cs-m17n (if (mew-coding-system-p 'ctext-unix) 'ctext-unix 'ctext))

Therefore many buffers in Mew sets ctext-unix as the default coding
system.  However, I have no idea how this decision was made.

-Tak

Sat, 23 Feb 2002 13:51:54 -0500: Eli Zaretskii <eliz@gnu.org> wrote:

> 	 Tak Ota on Sat, 23 Feb 2002 08:11:49 -0800 (PST))
> Subject: Re: ctext-pre-write-conversion barfs
> Reply-to: Eli Zaretskii <eliz@is.elta.co.il>
> References: <20020222.225355.01365596.Takaaki.Ota@am.sony.com>
> 	    <9743-Sat23Feb2002104842+0200-eliz@is.elta.co.il> <20020223.081149.60852929.Takaaki.Ota@am.sony.com>
> --text follows this line--
> > Date: Sat, 23 Feb 2002 08:11:49 -0800 (PST)
> > From: Tak Ota <Takaaki.Ota@am.sony.com>
> > 
> > BTW, I just now tried to save this buffer and noticed that
> > ctext-pre-write-conversion was invoked.  It is called 3 times for
> > each save-buffer.  Here is the output from describe-coding-system.
> > 
> > Coding system for saving this buffer:
> >   x -- ctext-unix
> 
> Could you please find out how come the buffer's encoding got set to
> ctext-unix?  It's a very unusual coding system for buffers.
> Compound-text is normally used for X selections only.
> 
> The reason I'm asking you to look into this is that the assumption
> behind the code I wrote for the ctext extensions is that ctext is not
> normally used for file I/O.  There are limitations of the pre-write
> and post-read conversions that make the modified ctext coding system
> inappropriate for reading and writing text to/from multibyte buffers.
> If ctext is used for file I/O, I will have to revert the decision to
> call the new encoding `ctext', and will find some other name.
> 
> So please look into this.  Thanks in advance.
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[laurent mpeti kabila]

REQUEST FOR URGENT BUSINESS ASSISTANCE
--------------------------------------
Your contact was availed to me by the chamber of
commerce. It was given
to me because of my diplomatic status as I did not
disclose the actual
reasons for which I sought your contact. But I was
assured
That you are reputable and trustworthy if you will be
of assistance. I am Laurent Mpeti Kabila (Jnr) the
second son of
Late President LAURENT DESIRE KABILA the immediate
Past president of the DEMOCRATIC REPUBLIC OF CONGO in
Africa who was
murdered by his opposition through his personal
bodyguards in his bedroom
on Tuesday 16th January, 2001. I have the privilege of
being mandated
by my father colleagues to seek your immediate and
urgent co-operation
to receive into your bank account the sum of US $25m.
(twenty-five million Dollars) and some thousands carats
of Diamond. This
money and treasures was lodged in a vault with a
security firm in
Europe and South-Africa.

SOURCES OF DIAMONDS AND FUND
In August 2000, my father as a defence minister and
president has a
meeting with his cabinet and armychief about the
defence budget for 2000
to 2001 which was US $700m. so he directed one of his
best
friend. Frederic Kibasa Maliba who was a minister of
mines and a political party leader known as the Union
Sacree de, I\x11
opposition radicale et ses allies (USORAL) to buy arms
with US $200m on
5th January 2001; for him to finalized the arm\x12s deal,
my father was
murdered. f.K. Maliba (FKM) and I have decided to keep
the money with a
foreigner after which he will use it to contest for
the political
election. Inspite of all this we have resolved to
present your or your company
for the firm to pay it into your nominated account the
above sum and
diamonds. This transaction should be finalized within
seven (7) working
days and for your co-operation and partnership, we
have unanimously
agreed that you will be entitled to 5.5% of the money
when successfully
receive it in your account. The nature of your
business is not relevant to
the successful execution of this transaction what we
require is your
total co-operation and commitment to ensure 100%
risk-free transaction at
both ends and to protect the persons involved in this
transactio!
n, strict confidence and utmost secrecy is required
even after the
successful conclusion of this transaction. If this
proposal is acceptable
to you, kindly provide me with your personal telephone
and fax through
my E-mail box for immediate commencement of the
 transaction. I count on your honour to keep my
secret, SECRET.

Looking forward for your urgent reply
Thanks.
Best Regards

MPETI L. KABILA (Jnr)

(no subject)

[Free Concert Tickets!]

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


 

TI wants to send you to your favourite concerts for free! 

Simply tell us what kind of music you like and we will notify you when your favourite shows are in your area. TI does not need your name or any other personal information making this a risk free opportunity. Great seats are given away at every show and one lucky subscriber will even get a chance to go backstage.
For more information about this offer click here. To get started immediately, complete the short survey below.
At Ticket Inbox we recognize that your time is valuable. Part of our success is because we adhere to Federal Government regulations on Internet privacy and we deliver on our promise to give you the best concert and event information. 

We welcome your feedback and if at anytime you are not satisfied you can unsubscribe. 


Subscribe now and Never Miss a Beat!
SUBSCRIBE NOW FOR FREE:


Area Code:  201202203204205206207208209210212213214215216217218219224225228229231234239240242246248250251252253254256260262264267268270276281284289301302303304305306307308309310312313314315316317318319320321323330334336337339340345347351352360361386401402403404405406407408409410412413414415416417418419423425434435440441443450469473478479480484501502503504505506507508509510512513514515516517518519520530540541551559561562563567570571573574580585586601602603604605606607608609610612613614615616617618619620623626630631636641646647649650651660661662664670671678682701702703704705706707708709712713714715716717718719720724727731732734740754757758760763765767770772773774775778780781784785786787801802803804805806807808809810812813814815816817818819828830831832843845847848850856857858859860862863864865867868869870876878901902903904905906907908909910912913914915916917918919920925928931936937939940941949952954956970971972973978979980985989

Confirmation email:
 

Music Preferences: 

AlternativeBluesJazz
CountryClassicalChristian
GospelFolkHip Hop/Rap
IndieLatinMetal
New AgeOldiesPop
PunkR&B/SoulReggae
Rock n RollRootsTraditional Pop
WorldtejanoSymphony

 




Home | About | Members | Benefits | Statistics & Events | Modify Your Profile | Contact Us | Promoter Info

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

(no subject)

[Richard Stallman]

I sent this request for the first time about two weeks ago, but I have
not heard from anyone.  I need help to make the new Emacs manual good.
Please do check part of the manual, and then please tell me about it.


I have updated the Emacs Manual for all the features listed in NEWS.
That is, I added documentation of these features--there might be other
parts of the manual that are no longer accurate and need correction.

Can people please try reading a chapter or file of the manual,
looking for anything that is incorrect or ought to be changed?
Whether it is a misspelled word, or incorrect grammar, or unclear
text, or a statement that used to be true but isn't true now,
please report it to me.

Please tell me which chapter or file you read, so I can check
coverage.  If you can do more than one chapter or file,
that would be good too.

Re: (no subject)

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

> I have updated the Emacs Manual for all the features listed in NEWS.

I did not read a chapter in particular, but I searched for
documentation related to fringes and found that the elisp manual
doesn't document the left-fringe and right-fringe frame parameters.

(I read the Emacs 21.3 RC info files, which doesn't seem to be synched
with HEAD, I'm not sure which one you wanted us to read.)

Re: (no subject)

[Richard Stallman]

    I did not read a chapter in particular, but I searched for
    documentation related to fringes and found that the elisp manual
    doesn't document the left-fringe and right-fringe frame parameters.

I haven't updated the Emacs Lisp Manual, just the Emacs Manual.

The version I'd like people to read are the one in the trunk.

(no subject)

[Dhruva Krishnamurthy]

Hi,
 The latest promotion fails to compile on W2K using MinGW32 (gcc) with
 the following message.

with regards,
dhruva

xdisp.c: In function `get_window_cursor_type':
xdisp.c:15330: structure has no member named `x_highlight_frame'
gmake[1]: *** [oo-spd/i386/xdisp.o] Error 1
gmake[1]: Leaving directory `D:/tmp/emacs/emacs/src'
gmake: *** [all-other-dirs-gmake] Error 2


-- 
Dhruva Krishnamurthy
Home: http://www.geocities.com/gnued/

(no subject)

[Thien-Thi Nguyen]

   From: Miles Bader <miles@lsi.nec.co.jp>
   Date: 10 Sep 2002 16:48:40 +0900

   Um, emacs doesn't use curses.

   You probably want to do this at the emacs glyph-matrix level.

sorry, i thought we were talking about text menus.
(however, note the weasle-word "prototyping". :-)

thi

21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

21.1 was released on 2001-10-20, more than a year ago.

21.2 was released on 2002-03-16, almost eight months ago.

We're just on the second pretest of 21.3. I think it's fair to assume
it'll be still a few months (at least two or three) before 21.3 hits the
streets.  Even if we feature-freeze 21.4-to-be at this moment and start
pretesting it like mad, it'll be almost two years since the last
feature-packed release was introduced to the public.  22.1 with Unicode
will be much further yet along the way.

OK, I know that:
 - we don't *have* to be faster than that
 - we prefer quality releases 
 - people really interested in features vs. stability can access the CVS

Still, I wonder if we should try to pack less punch in each release, and
release a bit faster than we're doing today.  I fear that this (totally
apparent, but public perception counts) stagnation can lead people to
other editors, or (worse, although more improbably) more Emacs branching.

Also, it's tough trying to evangelize people when I know that some
much-appreciated features are just in the HEAD and won't see the light
in a year or two...

Of course, I don't know what we should do, other than attracting more
people to Emacs development. Perhaps a tentative schedule like the one
in GCC would be a first step, but I'm not sure.

Or perhaps the problem is only on my mind; in that case, sorry for
taking your time.


                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Stefan Monnier]

> We're just on the second pretest of 21.3. I think it's fair to assume
> it'll be still a few months (at least two or three) before 21.3 hits the
> streets.  Even if we feature-freeze 21.4-to-be at this moment and start
> pretesting it like mad, it'll be almost two years since the last
> feature-packed release was introduced to the public.  22.1 with Unicode
> will be much further yet along the way.
[...]

I obviously agree since I called for a feature freeze a few weeks
(months?) back already.  I also think that 21.2 should have been taken
from the trunk rather than from the RC branch and same thing for 21.3.

This way we'd get new features more quickly into release and we'd get
the trunk code tested more thoroughly as well.

As Dave has explained the bug-fix release 21.3 will still be riddled with
bugs that we have fixed on the trunk months ago.  Maybe it will be a bit
more stable from one particular point of view because it doesn't use any
new code that might introduce new bugs, but I'm definitely not convinced
that it outweighs the number of unfixed non-trivial bugs.


	Stefan

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Mon, 4 Nov 2002, Juanma Barranquero wrote:

> Still, I wonder if we should try to pack less punch in each release, and
> release a bit faster than we're doing today.

As someone who was involved in pretest releases up until 21.2.90, I can 
assure you that the schedule for the releases was not determined by the 
desire to put ``more punch'', but simply by the availability of free time
to make the pretests and solve bugs reported by the pretesters.

> Also, it's tough trying to evangelize people when I know that some
> much-appreciated features are just in the HEAD and won't see the light
> in a year or two...

As long as we keep the scheme whereby bug-fix releases precede the
next development release, the time until the next release from HEAD
is largely determined by the amount of bugs we deem severe enough to
fix, and the available resources to fix them.  The only way to speed that 
up is to have more people working on the release branch.

> Of course, I don't know what we should do, other than attracting more
> people to Emacs development. Perhaps a tentative schedule like the one
> in GCC would be a first step, but I'm not sure.

Personally, I think it'd be a sad day when the quality of the released 
Emacs versions will be anywhere near GCC's.  Since GCC 3.0, I don't 
think there was a released version without a couple of major bugs.  With 
all its limitations, I'd vote for what we have now in Emacs any time.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Mon, 4 Nov 2002, Stefan Monnier wrote:

> I obviously agree since I called for a feature freeze a few weeks
> (months?) back already.

IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
not to release from the branch anymore.  Since there was a decision to 
release 21.3 from the branch, the decision not to feature-freeze followed 
almost automatically.

> I also think that 21.2 should have been taken
> from the trunk rather than from the RC branch and same thing for 21.3.

For 21.3, maybe.  But for 21.2, I disagree.  You effectively suggest to
eliminate bugfix releases, which I think would be wrong: users will have 
no stable versions to rely upon.

> As Dave has explained the bug-fix release 21.3 will still be riddled with
> bugs

FWIW, I think ``riddled with bugs'' is a grave exaggeration.

> Maybe it will be a bit
> more stable from one particular point of view because it doesn't use any
> new code that might introduce new bugs, but I'm definitely not convinced
> that it outweighs the number of unfixed non-trivial bugs.

So do you really think that introduction of significant new features 
doesn't destabilize Emacs?

That is, do you suggest to skip branch releases because they are not more 
stable _in_principle_, or just because we are too inept to make them 
significantly more stable?

Re: 21.2.90 pretest, 21.3, 21.4...

[Karl Eichwalder]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> For 21.3, maybe.  But for 21.2, I disagree.

With 21.1 and 21.2 you can destroy your files easily (even RMS was
bitten once[1]); the ordinary user isn't able to those encoding related
problems on his own.  Thus, please release 21.3 ASAP -- 21.3 is _very_
important for European users.  I don't understand why it takes that
long to release a version fixing these encoding related problems.

I know, resources are limited, but this must not mean to ignore or delay
serious problems.  I also put some time in testing the RC and said it is
better than the previous version; but I cannot test a bug fix release
again and again; I need some features from HEAD for my daily work.

Bug fix releases must happen in a timely manner -- otherwise they take
away to many resources from all of us.

________________
[1] Cf.:
From: Richard Stallman <rms@gnu.org>
Subject: Several serious problems
To: handa@etl.go.jp, spiegel@gnu.org, savannah-hackers@gnu.org
Cc: emacs-devel@gnu.org
Reply-To: rms@gnu.org
Date: Mon, 22 Jul 2002 11:11:35 -0600 (MDT)
Message-Id: <200207221711.g6MHBZo02496@aztec.santafe.edu>

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 5 Nov 2002 07:58:56 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> As someone who was involved in pretest releases up until 21.2.90, I can 
> assure you that the schedule for the releases was not determined by the 
> desire to put ``more punch'', but simply by the availability of free time
> to make the pretests and solve bugs reported by the pretesters.

In the case of the 21.2 and 21.3-to-be releases that's pretty clear, as
they carry no punch (meaning "features") and to all practical effects
apport just stability. (And no, I'm not understressing the immense value
of stability). Also, please don't think I don't value the effort you and
others put in each release. I do.

> As long as we keep the scheme whereby bug-fix releases precede the
> next development release, the time until the next release from HEAD
> is largely determined by the amount of bugs we deem severe enough to
> fix, and the available resources to fix them.  The only way to speed that 
> up is to have more people working on the release branch.

Well, yes. I think the most serious problem right now is the man-power
shortage; I'm not sure how many people is actively contributing, even in
small ways as I do, but we are few (or that's my highly subjective
perception).

Still, we're pretesting 21.3 since... when? March or April, at least?
There's really so big a list of problems with the pretests that we're
taking six months for a bug-fix release?

> Personally, I think it'd be a sad day when the quality of the released 
> Emacs versions will be anywhere near GCC's.  Since GCC 3.0, I don't 
> think there was a released version without a couple of major bugs.  With 
> all its limitations, I'd vote for what we have now in Emacs any time.

Copying some of the procedures does not necessarily mean copying the
errors. Still, I believe that preplanning tentative schedules, even if
we miss then, should help a little. That, and of course convincing
people to focus their attention in the release branch and not the
development one while the release branch is in pretest time... :)

                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 5 Nov 2002 08:05:29 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
> not to release from the branch anymore.  Since there was a decision to 
> release 21.3 from the branch, the decision not to feature-freeze followed 
> almost automatically.

OK, but then, as soon as 21.3 hits the streets, we *should* create a new
release branch, feature-freeze it and start pretesting it. If we want a
shinny new-features release sometime before 2004, I mean. And it's my
*strong* believe we should want it. Like it or not, users and developers
are more attracted if it seems there's movement. I'd bet people out
there things Emacs development is glacial.

> For 21.3, maybe.  But for 21.2, I disagree.  You effectively suggest to
> eliminate bugfix releases, which I think would be wrong: users will have 
> no stable versions to rely upon.

I cannot talk on behalf of Steffan, but at least I, who started the
thread, *don't* suggest such a thing. I suggest schedules.


                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 05 Nov 2002 08:02:42 +0100, Karl Eichwalder <keichwa@gmx.net> wrote:

> I also put some time in testing the RC and said it is
> better than the previous version; but I cannot test a bug fix release
> again and again; I need some features from HEAD for my daily work.
> 
> Bug fix releases must happen in a timely manner -- otherwise they take
> away to many resources from all of us.

To me, that's the crux of it. Yes.


                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Kai Großjohann]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> For 21.3, maybe.  But for 21.2, I disagree.  You effectively suggest to
> eliminate bugfix releases, which I think would be wrong: users will have 
> no stable versions to rely upon.

I do not suggest to eliminate bugfix releases, but IMVHO it would be
useful for the stable branch not to deviate too much from the
development branch (aka head).  Maybe this can be achieved by making
"smaller" releases, where each new release has fewer new features.
(But I realize that this is difficult for the new unicode branch.)

But then, I'm not an experienced developer for big projects like this.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: 21.2.90 pretest, 21.3, 21.4...

[Stefan Monnier]

> > I obviously agree since I called for a feature freeze a few weeks
> > (months?) back already.
> 
> IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
> not to release from the branch anymore.

Why is that ?
Even if we feature freeze it now, 21.4 will not be out before the end
of 2003.  I.e. long after 21.3.

> > I also think that 21.2 should have been taken
> > from the trunk rather than from the RC branch and same thing for 21.3.
> 
> For 21.3, maybe.  But for 21.2, I disagree.  You effectively suggest to
> eliminate bugfix releases, which I think would be wrong: users will have 
> no stable versions to rely upon.

Rather I suggest that we don't have the manpower to have several
active branches at the same time and do a good job with it.
So if we wanted 21.2 to be a really good bug-fix release, we should
have concentrated on bug-fixing while keeping it on the trunk so
that everyone was working on bug-fixing exclusively.

> > As Dave has explained the bug-fix release 21.3 will still be riddled
> > with bugs
> FWIW, I think ``riddled with bugs'' is a grave exaggeration.

It all depends on what you consider as a bug, so I stand by my claim
that it will be riddled with bugs.  Most of them are not of the kind
that segfault and most of them cannot be trivially fixed (i.e.
fixed without a significant risk of introducing other bugs) so even if
we spend another 10 years on "bugfixing" the RC branch, those bugs
will still be there (even tho they might have already been fixed on the
trunk months ago).

> > Maybe it will be a bit
> > more stable from one particular point of view because it doesn't use any
> > new code that might introduce new bugs, but I'm definitely not convinced
> > that it outweighs the number of unfixed non-trivial bugs.
> 
> So do you really think that introduction of significant new features 
> doesn't destabilize Emacs?
> 
> That is, do you suggest to skip branch releases because they are not more
> stable _in_principle_, or just because we are too inept to make them
> significantly more stable?

They are only more stable in cases where there really is a significant
new feature that destabilizes the code base.  E.g. the new redisplay in
Emacs-21, or a unicode-based internal encoding for Emacs-22.
The kinds of changes that took place on the trunk since Emacs-21.1
don't justify the burden of branch-releases.


	Stefan

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Tue, 05 Nov 2002 08:02:42 +0100
> 
> I don't understand why it takes that
> long to release a version fixing these encoding related problems.

What's there to understand?  Something needs to do the job of
preparing the tarballs and making decisions which bugs to fix on the
branch and how.  The available resources (manpower and free time) are
obviously not enough to make timely releases.

In addition, I've lost most of my free time since May and my gnu.org
account a couple of months ago.  Thus a very long gap between the last
pretest and the one before that.  Lately, Francesco kindly agreed to
take over, so we finalyy have another pretest.

> I know, resources are limited, but this must not mean to ignore or delay
> serious problems.

Nobody ignores serious problems, please don't assume such things.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> Date: Tue, 05 Nov 2002 08:56:59 +0100
> From: Juanma Barranquero <lektu@terra.es>
> 
> Still, we're pretesting 21.3 since... when? March or April, at least?
> There's really so big a list of problems with the pretests that we're
> taking six months for a bug-fix release?

I explained elsewhere in this thread that mundane practical problems
caused this delay, in addition to real issues.  I'm sorry that I was
part of the reasons for the delay, but I do have a life.

I'm sure everyone knows that the way to speed up things is to
volunteer to make them happen.

> > Personally, I think it'd be a sad day when the quality of the released 
> > Emacs versions will be anywhere near GCC's.  Since GCC 3.0, I don't 
> > think there was a released version without a couple of major bugs.  With 
> > all its limitations, I'd vote for what we have now in Emacs any time.
> 
> Copying some of the procedures does not necessarily mean copying the
> errors.

I think it does mean that.  But this is a different discussion, so I
suggest we drop it for now.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> Date: Tue, 05 Nov 2002 09:02:01 +0100
> From: Juanma Barranquero <lektu@terra.es>
> 
> OK, but then, as soon as 21.3 hits the streets, we *should* create a new
> release branch, feature-freeze it and start pretesting it.

Yes, I agree.  But I'm no longer involved in the development enough
to make my opinion on this matter count too much.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
> Date: Tue, 05 Nov 2002 13:02:12 +0100
> 
> I do not suggest to eliminate bugfix releases, but IMVHO it would be
> useful for the stable branch not to deviate too much from the
> development branch (aka head).

I agree, but the only good way to achieve that is to release the
bugfix versions faster.

> Maybe this can be achieved by making
> "smaller" releases, where each new release has fewer new features.

That requires a higher degree of control than we have now over what
changes are installed on the trunk.  As long as each change does not
need to be approved before it's installed, I think we cannot guarantee
that some new features are postponed.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Tue, 05 Nov 2002 13:39:40 -0500
> > 
> > IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
> > not to release from the branch anymore.
> 
> Why is that ?
> Even if we feature freeze it now, 21.4 will not be out before the end
> of 2003.  I.e. long after 21.3.

If you suggest to have two pretests running in parallel, I don't think
we can manage that with the available resources.

> Rather I suggest that we don't have the manpower to have several
> active branches at the same time and do a good job with it.
> So if we wanted 21.2 to be a really good bug-fix release, we should
> have concentrated on bug-fixing while keeping it on the trunk so
> that everyone was working on bug-fixing exclusively.

That'd be a step back to the previous development model, I think:
there was no branches, and development would actually stop while bugs
in a major release were fixed.  It's possible to argue that we should
go back, but I thought the current model was supposed to make the
development faster and releases more frequent.

> > > As Dave has explained the bug-fix release 21.3 will still be riddled
> > > with bugs
> > FWIW, I think ``riddled with bugs'' is a grave exaggeration.
> 
> It all depends on what you consider as a bug, so I stand by my claim
> that it will be riddled with bugs.

My objection was to the ``riddled'' part, not to the ``bugs'' part.  I
don't think it's a fair description of the state of the code.

> > That is, do you suggest to skip branch releases because they are not more
> > stable _in_principle_, or just because we are too inept to make them
> > significantly more stable?
> 
> They are only more stable in cases where there really is a significant
> new feature that destabilizes the code base.  E.g. the new redisplay in
> Emacs-21, or a unicode-based internal encoding for Emacs-22.

I think this is too extreme: many changes on the trunk have enough
potential to destabilize the code.  So we obviously disagree.

Look, I'm not against faster development, I just think that with the
current manpower and without a full-time head maintainer we won't be
able to do much better.  We could improve the development on the trunk
or on the branch, but not both.  When I was working on the branch
releases, I felt that the trunk is favored more than the branch, which
IMHO is one reason why the bug-fix releases didn't happen frequently
enough.  (My hope was that we could release 21.2 a month or two after
21.1 and 21.3 a month after 21.2.)

Re: 21.2.90 pretest, 21.3, 21.4...

[Stefan Monnier]

> > > IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
> > > not to release from the branch anymore.
> > 
> > Why is that ?
> > Even if we feature freeze it now, 21.4 will not be out before the end
> > of 2003.  I.e. long after 21.3.
> 
> If you suggest to have two pretests running in parallel, I don't think
> we can manage that with the available resources.

feature-freeze != pretest.

> > Rather I suggest that we don't have the manpower to have several
> > active branches at the same time and do a good job with it.
> > So if we wanted 21.2 to be a really good bug-fix release, we should
> > have concentrated on bug-fixing while keeping it on the trunk so
> > that everyone was working on bug-fixing exclusively.
> 
> That'd be a step back to the previous development model, I think:
> there was no branches, and development would actually stop while bugs
> in a major release were fixed.  It's possible to argue that we should
> go back, but I thought the current model was supposed to make the
> development faster and releases more frequent.

Quite right.  I think we should go back, unless we find enough people
to volunteer.  Although, now that I think about it again, I disagree with
what I said before.  I can't remember precisely enough what stage we were
at when we started 21.2.  So maybe the way we did 21.2 was OK, because
21.1 was major enough to justify a bug-fix-only release.

But for 21.3, if it had been forked from the trunk rather than from RC could
have been overall just as stable as 21.3 is.
So I just think that all releases should be forked from the trunk
rather than from a previous release branch.  I.e. each release branch
leads to one and only one release (barring emacs-19.34 and 19.34a kind
of things, obviously).
That might have made the 21.3 debugging&pretest a bit longer but
would have made it more useful (we would have found some bugs which are
still right now in the trunk, unbeknownst to us) and people would
able to use some of the new features that were implemented two years ago.

The above reasoning might also apply for 21.2, but I can't remember
enough to be sure.

> > > That is, do you suggest to skip branch releases because they are not more
> > > stable _in_principle_, or just because we are too inept to make them
> > > significantly more stable?
> > 
> > They are only more stable in cases where there really is a significant
> > new feature that destabilizes the code base.  E.g. the new redisplay in
> > Emacs-21, or a unicode-based internal encoding for Emacs-22.
> 
> I think this is too extreme: many changes on the trunk have enough
> potential to destabilize the code.  So we obviously disagree.
> 
> Look, I'm not against faster development, I just think that with the
> current manpower and without a full-time head maintainer we won't be
> able to do much better.  We could improve the development on the trunk
> or on the branch, but not both.  When I was working on the branch
> releases, I felt that the trunk is favored more than the branch, which
> IMHO is one reason why the bug-fix releases didn't happen frequently
> enough.  (My hope was that we could release 21.2 a month or two after
> 21.1 and 21.3 a month after 21.2.)

Complete agreement.  I just think it's more important to concentrate
our manpower on the trunk than on the branch.


	Stefan

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 05 Nov 2002 21:54:22 +0300
"Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> I explained elsewhere in this thread that mundane practical problems
> caused this delay, in addition to real issues.  I'm sorry that I was
> part of the reasons for the delay, but I do have a life.

If I´ve made it sound like I was looking for a culprit or disregarding
in any way yours or anyone´s contribution or (sometimes huge) amount of
work in this project, I´m really sorry.  It´s not so.

> I'm sure everyone knows that the way to speed up things is to
> volunteer to make them happen.

Yes, of course. But sometimes it´s not clear what can you volunteer for.
I alredy fix bugs I think I know how to fix, for example.

> I think it does mean that.  But this is a different discussion, so I
> suggest we drop it for now.

OK.

-- 
Juanma Barranquero <lektu@terra.es>

Re: 21.2.90 pretest, 21.3, 21.4...

[Karl Eichwalder]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> What's there to understand?

There are no patch sets to fix a special problem -- all fixes are done
incrementally.  Having patch sets could theoretically allow to fix on
to of 21.2 the encoding problem only.

> Something needs to do the job of preparing the tarballs and making
> decisions which bugs to fix on the branch and how.  The available
> resources (manpower and free time) are obviously not enough to make
> timely releases.

Sure.  I don't want to blame you (or any other release manager)
personally, by no means!  Pre-release candidates should be available
more visibly.

> Nobody ignores serious problems, please don't assume such things.

Yes, but if a problem is rated as serious it might be appropriate to
work on such a problem first and to try to solve it for _all_ Emacs
users.  Maybe, that's just my very personal opinion.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: 21.2.90 pretest, 21.3, 21.4...

[Stefan Monnier]

> > Maybe this can be achieved by making
> > "smaller" releases, where each new release has fewer new features.
> 
> That requires a higher degree of control than we have now over what
> changes are installed on the trunk.  As long as each change does not
> need to be approved before it's installed, I think we cannot guarantee
> that some new features are postponed.

That's not true.  We can and do declare feature freezes and we can
impose them pretty effectively by shaming the poor soul who disobeys
and undoing his change.  It works very well in practice.


	Stefan

Re: 21.2.90 pretest, 21.3, 21.4...

[Richard Stallman]

I think 21.3 may be just a few weeks away.

      I fear that this (totally
    apparent, but public perception counts) stagnation can lead people to
    other editors, or (worse, although more improbably) more Emacs branching.

It is easy enough for people to see in CVS what we are working on.
I don't think this is a real problem.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Tue, 5 Nov 2002, Stefan Monnier wrote:

> > > Even if we feature freeze it now, 21.4 will not be out before the end
> > > of 2003.  I.e. long after 21.3.
> > 
> > If you suggest to have two pretests running in parallel, I don't think
> > we can manage that with the available resources.
> 
> feature-freeze != pretest.

Well, perhaps I misunderstood: what good is it to freeze the trunk unless 
we start a pretest?

> But for 21.3, if it had been forked from the trunk rather than from RC could
> have been overall just as stable as 21.3 is.

IIRC, it was a judgement call, and at the time it sounded like we could 
have 21.3 out the door in less than a month.  Given that assumption, it's 
not clear to me whether the decision was wrong.  (To make it perfectly 
clear, the decision was not mine.)

> So I just think that all releases should be forked from the trunk
> rather than from a previous release branch.

I could agree with that in principle.  But in reality, it could happen 
that the first release you make from the branch is not stable enough, 
and that in the meantime the trunk got several new significant changes 
that make it inappropriate for the next release.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Tue, 5 Nov 2002, Juanma Barranquero wrote:

> > I explained elsewhere in this thread that mundane practical problems
> > caused this delay, in addition to real issues.  I'm sorry that I was
> > part of the reasons for the delay, but I do have a life.
> 
> If I´ve made it sound like I was looking for a culprit or disregarding
> in any way yours or anyone´s contribution or (sometimes huge) amount of
> work in this project, I´m really sorry.  It´s not so.

It's true that I sometimes take offense where others don't, but in this 
case, you have nothing to apologize for: your wording didn't come 
anywhere near any disregard.

I simply wanted to explain why the delay happened.  I truly _am_ sorry 
that my personal life interfered.

> > I'm sure everyone knows that the way to speed up things is to
> > volunteer to make them happen.
> 
> Yes, of course. But sometimes it´s not clear what can you volunteer for.

There are a few mundane tasks involved in a pretest: making the tarballs 
and xdelta's, testing and uploading them, tracking the reports by 
pretesters (like on which systems they built successfully, what 
outstanding bugs are still unsolved, etc.).  When there's a major 
modification in the manuals, there's typically a need to record what 
pages were reviewed and how many times, to ensure coverage.  Etc., etc.

> I alredy fix bugs I think I know how to fix, for example.

If we want more frequent releases from the stable branch, bugs on the 
branch should get priority, or at least there should be enough people 
working on them to ensure they are fixed almost immediately.

Ideally, there should be a new pretest once a week.  We are still very 
far from that goal, I think; anything that helps us move toward that is a 
welcome change.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Tue, 5 Nov 2002, Karl Eichwalder wrote:

> There are no patch sets to fix a special problem -- all fixes are done
> incrementally.  Having patch sets could theoretically allow to fix on
> to of 21.2 the encoding problem only.

Sorry, I don't think I understand what do you mean by ``patch sets''.

AFAIK, Emacs has never released any patches (is there a project that 
does?), only tarballs of new versions where some problems are fixed
(and new exciting ones are added ;-).

> Pre-release candidates should be available more visibly

That already happened, I think: the directory on alpha.gnu where we put 
the pretests is no longer secret or unreadable.  And on top of that, 
there's anon CVS access.  Isn't that enough?

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Tue, 5 Nov 2002, Stefan Monnier wrote:

> > > Maybe this can be achieved by making
> > > "smaller" releases, where each new release has fewer new features.
> > 
> > That requires a higher degree of control than we have now over what
> > changes are installed on the trunk.  As long as each change does not
> > need to be approved before it's installed, I think we cannot guarantee
> > that some new features are postponed.
> 
> That's not true.  We can and do declare feature freezes and we can
> impose them pretty effectively by shaming the poor soul who disobeys
> and undoing his change.

Feature freeze means there are _no_ new features until the thaw; Kai 
suggested a finer control (allow some new features, but not others).

I also have a clear impression that reverting changes is something we 
do only as the last resort (and for a number of good reasons; I don't 
suggest doing that more often!).  I don't remember a single change that 
was reverted because we thought it would destabilize the code, I think 
the few cases of chnage revrsal were all due to known bugs they caused, 
not because we were afraid of unknown bugs.

Re: 21.2.90 pretest, 21.3, 21.4...

[Karl Eichwalder]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Sorry, I don't think I understand what do you mean by ``patch sets''.

1 patch or 1 patch set to fix something well defined that's said to be a
bug; examples out of the blue: disabling fringes, enabling encoding
unification, prevent crash on architecture 'foo', and the like.

> AFAIK, Emacs has never released any patches (is there a project that
> does?),

Linux kernel hackers?

> only tarballs of new versions where some problems are fixed

Yes.  My idea is to prepare those patches mainly for internal release
management purposes (but it wouldn't hurd to make them available on
alpha, too).  Prepare pre-releases as usual, do testing.  Now, when a
serious problem with the already released version pops up, fix just
this problem and release a fixed version immediately.  Than apply the
patch sets again and continues the usual pre-release testing cycle.

Also, there are fixes that don't require extensive testing; either
because they are trivial or because they could affect only a small
fraction of users (does not compile on architecture 'bar').  I'd like
to see released those fixes rather timely.

Hope it's clear what I meant.  If not, just forget about it ;-)

> the directory on alpha.gnu where we put the pretests is no longer
> secret or unreadable.

I wasn't aware of this change, great!  I recommend to announce things
like this more publicly.  PITA, that the gnu announce group is empty
since ages -- as long as you (not you personally) don't fix the
announce channels you don't have a right to complain about the lack of
manpower.

Others wihtin this thread already said: the more activity (useful
releases) you will show to the user and hacker crowed the more you will
attract helpful hands.

Okay, talk is easy.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: 21.2.90 pretest, 21.3, 21.4...

[Kai Großjohann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
>> Date: Tue, 05 Nov 2002 13:02:12 +0100
>> 
>> I do not suggest to eliminate bugfix releases, but IMVHO it would be
>> useful for the stable branch not to deviate too much from the
>> development branch (aka head).
>
> I agree, but the only good way to achieve that is to release the
> bugfix versions faster.

What's the problem with doing more releases from the head and fewer
from the branch?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 05 Nov 2002 22:00:09 +0300, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> That requires a higher degree of control than we have now over what
> changes are installed on the trunk.  As long as each change does not
> need to be approved before it's installed, I think we cannot guarantee
> that some new features are postponed.

Well, that's a matter of self-discipline. Perhaps I'm too optimistic,
but I'd think that just asking for no new features to be checked in for
a while should suffice...

                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 05 Nov 2002 23:49:50 -0500, Richard Stallman <rms@gnu.org> wrote:

> I think 21.3 may be just a few weeks away.

I'm glad to hear that.

> It is easy enough for people to see in CVS what we are working on.

I couldn't count with both my hands the amount of friends I have that use
Emacs routinely, but have never been nowhere near the Emacs CVS, and
*do* have the perception that Emacs releases are few and far between...

Still, I don't know if that's a problem or not. What *is* a problem is
the fact that we are unable (or at least relatively unsuccessful) to
attract more people.

                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Kim F. Storm]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Feature freeze means there are _no_ new features until the thaw; Kai 
> suggested a finer control (allow some new features, but not others).

IMO, a feature freeze on the trunk at the current state would be OK!

There are now so many new features and fixes compared to 21.[1-3], that
starting a pretest cycle for 21.4 from the trunk would be a _good thing_
to start getting all those new features tested (before we add even more
features).

Admittedly, it would halt "development" on the trunk for, say 2-3
months, but what's the purpose of such developments anyway if we
(virtually) never make a release containing those new features?

So I suggest that we announce a date (e.g. Dec 1st) for a trunk
feature freeze and make the first pretest for 21.4 soon thereafter,
with the goal of releasing 21.4 no later than Mar 1st, 2003!

In my experience, the trunk has been very stable for a very long time
[with a few hickups of course], so after the first few pretests, I
would assume that the software would be stable enough for a release,
or at least stable enough that we could make a 21_4 release branch for
ironing out the final issues with the 21.4 release and remove the
feature freeze on the trunk before Mar 1st (or whenever 21.4 will
actually be ready).

Are anyone of you aware of any significant stability (or redisplay)
related bugs that we need to fix before 21.4 ?

Are there any of the on-going tasks which *must be* completed before
we release 21.4 ?

I know we need some work on the manuals for the new features; maybe
the goal of releasing 21.4 soon will also move our focus towards
writing proper documentation for the new features (I know I still have
a few pending tasks in that area).

WDYT ??

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On 06 Nov 2002 13:40:18 +0100, storm@cua.dk (Kim F. Storm) wrote:

> IMO, a feature freeze on the trunk at the current state would be OK!

I agree.

> So I suggest that we announce a date (e.g. Dec 1st) for a trunk
> feature freeze and make the first pretest for 21.4 soon thereafter,
> with the goal of releasing 21.4 no later than Mar 1st, 2003!

I think those are reasonable goals. Dec 1st for the freeze leaves time
enough for those who really *want* to include something in the 21.4 (at
least, if that "something" is not big, and if it is, it would be better
to wait for 21.5 anyway, IMO). That's four months of pretesting at the
bare minimum.  And we can always slip past the deadline... :)

> In my experience, the trunk has been very stable for a very long time
> [with a few hickups of course], so after the first few pretests, I
> would assume that the software would be stable enough for a release,
> or at least stable enough that we could make a 21_4 release branch for
> ironing out the final issues with the 21.4 release and remove the
> feature freeze on the trunk before Mar 1st (or whenever 21.4 will
> actually be ready).

Yes. I agree wrt stability of the trunk. I use 21.3.50 daily in my
production environment.  I don't remember the last time I had a crash;
many months ago. Several times I wasn't able to compile or bootstrap,
but if it compiles, it is rock-solid.

> Are anyone of you aware of any significant stability (or redisplay)
> related bugs that we need to fix before 21.4 ?

I know of two problems. At least one of them is Windows-specific, but I
don't know how to fix it: if you use w32-select-font and get an
*-iso10646-1 font, pasting it into the Registry
(HKLM\Software\GNU\Emacs\Font) garbles Emacs display. It looks like
Emacs isn't aware it's using an Unicode font. That happens both in the
RC and HEAD branches.

The other, related to some changes by Richard a few months ago, is that
the scroll line-by-line doesn't work when you're displaying the
ruler (or any other thing that makes Emacs show partially-visible lines).
In that case scroll always recenter the cursor irrespective of the value
of `scroll-conservatively'. It's a redisplay bug, but minor. Happens
only on the trunk.

> WDYT ??

FWIW, I think that any reasonable mesure to take the new features out to
the public light is good.


                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Wed, 6 Nov 2002, Karl Eichwalder wrote:

> My idea is to prepare those patches mainly for internal release
> management purposes (but it wouldn't hurd to make them available on
> alpha, too).  Prepare pre-releases as usual, do testing.  Now, when a
> serious problem with the already released version pops up, fix just
> this problem and release a fixed version immediately.

You assume that in the meantime no changes were done in the CVS, which is 
normally not the case.

Also, an entirely new tarball for each bug sounds excessive (each one is 
20MB compressed, remember?).

> PITA, that the gnu announce group is empty
> since ages -- as long as you (not you personally) don't fix the
> announce channels you don't have a right to complain about the lack of
> manpower.

I didn't complain.  Someone needs to step forward to fix gnu.announce as 
well.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Wed, 6 Nov 2002, Kai =?iso-8859-1?q?Gro=DFjohann?= wrote:

> > I agree, but the only good way to achieve that is to release the
> > bugfix versions faster.
> 
> What's the problem with doing more releases from the head and fewer
> from the branch?

The desire to have a stable version out there from time to time?

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On 6 Nov 2002, Kim F. Storm wrote:

> IMO, a feature freeze on the trunk at the current state would be OK!
> 
> There are now so many new features and fixes compared to 21.[1-3], that
> starting a pretest cycle for 21.4 from the trunk would be a _good thing_
> to start getting all those new features tested (before we add even more
> features).

That means 2 pretests at once (as long as 21.3 is not released).  I don't 
think we can handle that.

> Admittedly, it would halt "development" on the trunk for, say 2-3
> months, but what's the purpose of such developments anyway if we
> (virtually) never make a release containing those new features?

That's what we did before branches.  I'm not sure we should go back to 
that model.

The reason for the branch was that many developers are interested in 
development much more than they are interested in pretest and other 
mundane tasks which are important for fast releases after the freeze.  
The branch was supposed to give those people an opportunity to check in 
changes even as the pretest was under way.

> Are anyone of you aware of any significant stability (or redisplay)
> related bugs that we need to fix before 21.4 ?

Emacs 21.1 was stable for me more than a year before it was released.  
The pretest phase found problems none of the developers ever saw.  Moral: 
don't make decisions about stability based on what people who read this 
forum tell you.

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Wed, 6 Nov 2002 16:25:04 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> The reason for the branch was that many developers are interested in 
> development much more than they are interested in pretest and other 
> mundane tasks which are important for fast releases after the freeze.  
> The branch was supposed to give those people an opportunity to check in 
> changes even as the pretest was under way.

Sure. But perhaps we should *always* have a pretest active. We are
pretesting 21.3 and developing 21.4. As soon as 21.3 is released, the
very same day, we branch for 21.4 with feature-freeze. Then each people
can decide if they want to help in getting out a "features" version or
continue hackin' new features (or both). And the day 21.4 is announced
we branch for 21.5, etc.

> Emacs 21.1 was stable for me more than a year before it was released.  
> The pretest phase found problems none of the developers ever saw.

Sure. Still, that's unavoidable, so the more time it takes releasing a
pretest, the more it'll be delayed the definitive release.

                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Miles Bader]

On Wed, Nov 06, 2002 at 04:25:04PM +0200, Eli Zaretskii wrote:
> > Are anyone of you aware of any significant stability (or redisplay)
> > related bugs that we need to fix before 21.4 ?
> 
> Emacs 21.1 was stable for me more than a year before it was released.  
> The pretest phase found problems none of the developers ever saw.  Moral: 
> don't make decisions about stability based on what people who read this 
> forum tell you.

For me too (and I normally update from CVS _every single day_), but it's
still a good question I think, because every once in a [long] while a nasty
bug shows up which not everyone may notice, like the scrolling-sometimes-
trashes-the-screen problem that's come and gone for a while (I _think_ that's
fixed, currently, but since it's come back from the dead several times, I'm
ever-so-slightly nervous).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

(no subject)

[Kenichi Handa]

In article <5xbs52oor1.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
> Are there any of the on-going tasks which *must be* completed before
> we release 21.4 ?

(1) I'm working on fixing ps-print and ps-mule so that
non-ASCII characters in a buffer name can also be converted
to correct PostScript code.   I think I can find time to
finish it by the end of this month.

(2) I've just installed an automatic character composition
mechanism in emacs-unicode branch.  It works like font-lock.
I think it is worth back-porting to HEAD because it is very
convenient for such scripts that require complicated
displaying (thai, lao, devanagari, tibetan).  But, It seems
that I don't have enough time to do that.  Aren't there any
volunteer?

(3) Currently, one person is working on Malayalam support in
emacs-unicode.  It is also worth back-poring to HEAD.  But,
as it is just adding a new language support, it may be
possible to add it even after feature freeze.

---
Ken'ichi HANDA
handa@m17n.org

Re: 21.2.90 pretest, 21.3, 21.4...

[Richard Stallman]

    1 patch or 1 patch set to fix something well defined that's said to be a
    bug; examples out of the blue: disabling fringes, enabling encoding
    unification, prevent crash on architecture 'foo', and the like.

This would be extra work, and since we are short-handed, I won't make
any commitment to do this or lead the users to expect this.  If people
want the very latest sources, they can always get them from CVS.

Re: 21.2.90 pretest, 21.3, 21.4...

[Francesco Potorti`]

>IMO, a feature freeze on the trunk at the current state would be OK!

Not a bad idea.

Re: 21.2.90 pretest, 21.3, 21.4...

[Francesco Potorti`]

>That means 2 pretests at once (as long as 21.3 is not released).  I don't 
>think we can handle that.

We could do that as soon as 21.3 is released.

Re: 21.2.90 pretest, 21.3, 21.4...

[Kai Großjohann]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Wed, 6 Nov 2002, Karl Eichwalder wrote:
>
>> My idea is to prepare those patches mainly for internal release
>> management purposes (but it wouldn't hurd to make them available on
>> alpha, too).  Prepare pre-releases as usual, do testing.  Now, when a
>> serious problem with the already released version pops up, fix just
>> this problem and release a fixed version immediately.
>
> You assume that in the meantime no changes were done in the CVS, which is 
> normally not the case.

Maybe it could work like this: version 21.4 is released.  A bug
regarding mumblefoo is found.  Somebody takes 21.4 and fixes the bug
and releases a mumblefoo patch against 21.4.  A bug regarding
frobnicating is found.  Somebody else takes 21.4 and fixes the bug
and releases a frobnicating patch against 21.4.

Each such patch is also applied to the head.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: (no subject)

[Richard Stallman]

    (2) I've just installed an automatic character composition
    mechanism in emacs-unicode branch.  It works like font-lock.
    I think it is worth back-porting to HEAD

Why bother?  We could just wait till we adopt the Unicode changes
and we will get to the same place.

Re: 21.2.90 pretest, 21.3, 21.4...

[Richard Stallman]

I see no reason to aim for a 21.4 release very soon.

Re: (no subject)

[Richard Stallman]

      (while file-exists-p target-file)
	;; Remove the target before writing it, so that any
	;; hard-links continue to point to the old file (this makes
	;; it possible for installed files to share disk space with
	;; the build tree, without causing problems when emacs-lisp
	;; files in the build tree are recompiled).
	(delete-file target-file))

    This is a hack for developers, and shouldn't be in the releases, in my
    opinion. For example, it trashes the .elc file permissions, not to
    speak about symlinks, etc.

I think we need to keep this feature.

Re: (no subject)

[shuki_duv]

Richard Stallman <rms@gnu.org> wrote:
>>    (while file-exists-p target-file)
>> 	;; Remove the target before writing it, so that any
>> 	;; hard-links continue to point to the old file (this makes
>> 	;; it possible for installed files to share disk space with
>> 	;; the build tree, without causing problems when emacs-lisp
>> 	;; files in the build tree are recompiled).
>> 	(delete-file target-file))
>> 
>>    This is a hack for developers, and shouldn't be in the releases, in
>>    my opinion. For example, it trashes the .elc file permissions, not
to
>>    speak about symlinks, etc.
> 
> I think we need to keep this feature.

Of what use is it to users (as opposed to the developers)? On the other
hand, for example, I am maintaining an emacs configuration which is in
widespread use (via -u). My umask is 077, and whenever I recompile a file,
I need to change its .elc counterpart permissions back.

You could say that I should change the recompiling function, but in my
opinion, the UNIX way of rewriting files is in no need of questionable
improvements like these. At the least, one could ensure that the number of
hardlinks is more than one before erasing target-file.

Also, what if target-file is a symlink? In my opinion, this feature only
confuses matters.

Best regards,
Shuki

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: (no subject)

[Miles Bader]

On Tue, Aug 12, 2003 at 06:11:23AM -0700, shuki_duv@yahoo.com wrote:
> Of what use is it to users (as opposed to the developers)?

Even if one were to accept that the distinction were relevant, how, pray
tell, does emacs know which you are?  The very fact that you're compiling .el
file multiple times suggests that you, in fact, are actually more like a
`developer.'

In any case, I think the point is that emacs simply doesn't know what you
want, and can't, unless you tell it.  Perhaps something like a
`byte-compile-overwrite-output-file' could be added to do what you want.

> On the other hand, for example, I am maintaining an emacs configuration
> which is in widespread use (via -u). My umask is 077, and whenever I
> recompile a file, I need to change its .elc counterpart permissions back.

Writing a new file (as opposed to overwriting the old one) is very common
in unix tools (especially in emacs).  If you have set up your environment so
that this doesn't do what you want, you have to deal with the result yourself
(it's not like it's hard).

> Also, what if target-file is a symlink? In my opinion, this feature only
> confuses matters.

Relying on writing files through a symlink is similarly something you can't
rely on; you simply shouldn't do that in general.

-Miles
-- 
We live, as we dream -- alone....

Re: (no subject)

[Thien-Thi Nguyen]

<shuki_duv@yahoo.com> writes:

   Of what use is it to users (as opposed to the developers)?

users opposing programmers is opposite of emacs' (and one could say
fsf's) appeal.  IME people who can't see it this way tend to make life
more difficult for those who can.

   Also, what if target-file is a symlink? In my opinion, this feature
   only confuses matters.

luckily, although matters may be confusing, in the end it is each person
who is or is not confused, individually.  i wouldn't wish my confusion
on anyone; i worked hard to acquire it!

thi

(no subject)

[george mbulu]

Dear friend
 
As you read this, I don't want you to feel sorry for
me, because, I believe everyone will die someday.
 
My name is  George Mbulu, a merchant in Dubai, in the
U.A.E.I have been diagnosed with Esophageal cancer
which was discovered very late, due to my laxity in
carrying for my health. It has defiled all forms of
medicine, and right now I have only about a few
months to live, according to medical experts.
I have not particularly lived my life so well, as I
never really cared for anyone not even myself but my
business. Though I am very rich, I was never
generous, I was always hostile to people and only
focus on my business as that was the only thing I
cared for. But now I regret all this as I now know
that there is more to life than just wanting to have
or make all the money in the world.
I believe when God gives me a second chance to come
to this world I would live my life a different way
from how I have lived it. Now that God ! has called
me, I have willed and given most of my properties
and assets to my immediate and extended family
members and as well as a few close friends.
I want God to be merciful to me and accept my soul
and so, I have decided to give alms to charity
organizations, as I want this to be one of the last
good deeds I do on earth. So far, I have distributed
money to some charity organizations in the U.A.E,
Algeria and Malaysia. Now that my health has
deteriorated so badly, I cannot do this my self any
more. I once asked members of my family to close one
of my accounts and distribute the money which I have
there to charity organization in Bulgaria and
Pakistan, they refused and kept the money to
themselves. Hence, I do not trust them anymore, as
they seem not to be contended with what I have left
for them.
The last of my money which no one knows of is the
huge cash deposit of twenty four million dollars
that I have with a security company in Amsterdam Holland.The name of the company is coin securities compies in Holland.
I will want you to help me col lect this deposit and
dispatched it to charity organizations.You can reach me on:georgembulu@yahoo.com
I have set aside 10% for you for your time and
patience.
 
God be with you.
 
George

NB:IT IS ONLY YOU AND I KNOW WHAT IS THE CONTENT OF THE TRUNKBOX.
 
 


___________________________________________________
Check-out GO.com
GO get your free GO E-Mail account with expanded storage of 6 MB!
http://mail.go.com

(no subject)

[Luc Teirlinck]

The changes in:

2003-11-16  Jan Djarv  <jan.h.d@swipnet.se>

do not seem to take the native scrollbar into account.  Configuring
without options works fine, but after:

./configure --without-toolkit-scroll-bars

bootstrapping still works fine, but when trying to start Emacs, I get
an immediate segfault:

[bash2.05b.0 ~ 3 1] gdb emacs-21.3.50
(gdb) run
Starting program: /usr/local/bin/emacs-21.3.50 

Program received signal SIGSEGV, Segmentation fault.
0x080bc5ff in x_window_to_scroll_bar (display=0x85f5ab8,
window_id=60817438)
    at xterm.c:3880
3880         if (FRAME_X_DISPLAY (XFRAME (frame)) != display)
(gdb) 


I do not know the code in question well enough to fix this myself.

Sincerely,

Luc.

Re: (no subject)

[Jan D.]

> The changes in:
> 
> 2003-11-16  Jan Djarv  <jan.h.d@swipnet.se>
> 
> do not seem to take the native scrollbar into account.  Configuring
> without options works fine, but after:
> 
> ./configure --without-toolkit-scroll-bars
> 
> bootstrapping still works fine, but when trying to start Emacs, I get
> an immediate segfault:
> 
> [bash2.05b.0 ~ 3 1] gdb emacs-21.3.50
> (gdb) run
> Starting program: /usr/local/bin/emacs-21.3.50 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x080bc5ff in x_window_to_scroll_bar (display=0x85f5ab8,
> window_id=60817438)
>     at xterm.c:3880
> 3880         if (FRAME_X_DISPLAY (XFRAME (frame)) != display)
> (gdb) 
> 

This was trying to fix the very rare case where you get
identical window id from two X displays.

I have checked in a better fix.  There are too many configurations to
test. :-(

Thanks,


	Jan D.

(no subject)

[Lutz Julianne]

[-- Attachment #1.1: Type: text/plain, Size: 221 bytes --]

pappy doberman siren ratty conjugacy daze 
delinquent counterproposal aliphatic lute rotogravure autotransformer whitlock cologne hoard 
freudian eighth hinman deaden occident crossover auditory morsel kitten calculable 

[-- Attachment #1.2: Type: text/html, Size: 2661 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Walden Teri]

[-- Attachment #1.1: Type: text/plain, Size: 149 bytes --]

chicanery compleat folk rabies howell adrienne rim 
bindle corral rhodolite compliment emphatic translate henderson 
atkins okay raven extroversion 

[-- Attachment #1.2: Type: text/html, Size: 2574 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[admail.direct]

  from mail.unsubscribenow.org with eGlobal Planet (MMS ver1.6)
Message-ID: <eGlobal Planet Shanghai TuXiang China>
From: "UnsubscribeNow.org" <admail.direct@unsubscribenow.org>
Reply-To: "UnsubscribeNow.org" <admail.direct@unsubscribenow.org>
To: emacs-devel@gnu.org
Subject: Fw: ADV: IMPORTANT: your email address is circulating...
Date: Tue, 03 Feb 2004 02:21:28 +0500
X-Mailer: eGlobal Planet (MMS ver1.6)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="--274836256165949156"
X-Priority: 1
X-MSMail-Priority: High

----274836256165949156
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1=
">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<CENTER>
<TABLE style=3D"WIDTH: 551px; HEIGHT: 179px" width=3D551 align=3Dcenter bo=
rder=3D0>
  <TBODY>
  <TR>
    <TD vAlign=3Dbottom colSpan=3D2 height=3D41>
      <DIV align=3Dcenter>&nbsp;</DIV>
      <DIV align=3Dleft><FONT face=3DArial size=3D2><FONT 
      face=3DTahoma color=3D#006699><STRONG>[UnsubscribeNow.org OLX Public=
 Service Announcement 
      ADV# 56T1002]</STRONG></FONT></FONT></DIV>
      <DIV align=3Dcenter><FONT face=3DArial color=3D#006699 size=3D2></FO=
NT>&nbsp;</DIV>
      <DIV align=3Dcenter>
      <HR style=3D"WIDTH: 300pt" align=3Dcenter width=3D400 SIZE=3D2>
      </DIV>
      <DIV align=3Dcenter><FONT face=3DTahoma size=3D2></FONT><FONT face=3D=
Tahoma 
      color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
      <DIV align=3Dleft><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#006699 
      size=3D2><STRONG>If you've received this message</STRONG> - then you=
r 
      email address has been screened</FONT></DIV>
      <DIV align=3Dleft><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#006699 
      size=3D2>circulating on pornography and spam related mailing lists. =

      <FONT face=3D"Arial, Helvetica, sans-serif" color=3D#006699 
      size=3D2>UnsubscribeNow.org</FONT></FONT></DIV>
      <DIV align=3Dleft><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#006699 
      size=3D2><FONT face=3D"Arial, Helvetica, sans-serif" color=3D#006699=
 
      size=3D2>screens junk-email circulating online and registers
      their 'remove-me'</FONT><FONT face=3DArial color=3D#006699 size=3D2>=
 links into 
      the</FONT></DIV><DIV align=3Dleft><FONT face=3DArial color=3D#006699=
 size=3D2>
      UnsubscribeNow.org 'remove-me' database.
      <DIV align=3Dleft><FONT face=3DArial color=3D#006699 size=3D2></FONT=
>&nbsp;</DIV>
      <DIV align=3Dleft><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#006699 
      size=3D2>To learn how we help clear and 'Opt-out' your email address=
es online,
      </FONT><FONT face=3D"Arial, Helvetica, sans-serif" color=3D#006699 s=
ize=3D2>
      </FONT><FONT face=3D"Arial, Helvetica, sans-serif" color=3D#006699 
      size=3D2>visit </FONT><FONT face=3D"Arial, Helvetica, sans-serif" 
      color=3D#006699 size=3D2>us at <A 
      href=3D"http://www.unsubscribenow.org">www.UnsubscribeNow.org</A></F=
ONT></DIV>
      <DIV align=3Dleft><a href=3D"http://www.unsubscribenow.org"><img
      src=3D"http://www.unsubscribe-now.net/eml_usn.gif" width=3D"460" hei=
ght=3D"60"
      border=3D"0"></a></DIV>
  <TR>
    <TD vAlign=3Dcenter colSpan=3D2>
      <DIV align=3Dleft><FONT face=3DVerdana size=3D1 color=3D#000000><STR=
ONG>
      Please Forward.... To ensure removal from future online notification=
s,
      <a href=3D'http://www.unsubscribe-now.net/global_remove/'>Remove Now=
</a>
      </STRONG></FONT></DIV>
      <DIV align=3Dleft><FONT face=3DVerdana size=3D1 color=3D#006699>
      Messaging provided by: eGlobal Planet, 244 Madison Ave, #456, New Yo=
rk, NY 10016
      </FONT></DIV>
      <DIV align=3Dleft><FONT face=3DVerdana size=3D1 color=3D#006699>
      <a href=3D'http://www.unsubscribenow.org/support_privacy.php'>Privac=
y Policy</a>
      This message is a US Federal CAN Spam compliant advertisement. 
      </STRONG></FONT></DIV>
      <DIV align=3Dleft><STRONG><FONT face=3DVerdana 
      size=3D1></FONT></STRONG></A></DIV></TD></TR>
</TBODY></TABLE></CENTER>

----274836256165949156--

(no subject)

[Alyson]

[-- Attachment #1.1: Type: text/plain, Size: 224 bytes --]

saturable afflict brassy phrasemake imprimatur consecutive octane innards 
augean gusset corinth optoelectronic artifice bewilder mycology ibis pong integument 
stupid fenugreek pairwise diathermy claudio dichotomy melanin 

[-- Attachment #1.2: Type: text/html, Size: 709 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Delores Bacon]

[-- Attachment #1.1: scribble capstan acquiescent --]
[-- Type: text/html, Size: 2759 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Nicole Delarosa]

[-- Attachment #1.1: proficient brunch amino --]
[-- Type: text/html, Size: 3126 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Dhruva Krishnamurthy]

Hello,
 "nmake info" (and gmake info) fails on GNU Emacs CVS HEAD using MSVC6
 (MinGW32).
The problem is in:
1. cd emacs/man
2. nmake info (gmake info)

The error is:
for the command "./../nt/multi-install-info.bat", "." which represents
the current direcotry is not interpreted as it should be and gives an
error. 

    '.' is not recognized as an internal or external command,
    operable program or batch file.

Changing the above command to : ".\..\nt\multi-install-info.bat" works
for both nmake and gmake!

Here is the diff of original versus modified (is this the standard?):
emacs/man/makefile.w32-in

*** \tmp\cvs\emacs\man\makefile.w32-in  Mon May  3 16:51:32 2004
--- ..\man\makefile.w32-in      Tue May  4 12:21:54 2004
*************** infodir = $(srcdir)/../info
*** 30,36 ****

  # The makeinfo program is part of the Texinfo distribution.
  MAKEINFO = makeinfo
! MULTI_INSTALL_INFO = $(srcdir)/../nt/multi-install-info.bat
  INFO_TARGETS = $(infodir)/emacs $(infodir)/ccmode \
                $(infodir)/cl $(infodir)/dired-x \
                $(infodir)/ediff $(infodir)/forms \
--- 30,36 ----

  # The makeinfo program is part of the Texinfo distribution.
  MAKEINFO = makeinfo
! MULTI_INSTALL_INFO = $(srcdir)\..\nt\multi-install-info.bat
  INFO_TARGETS = $(infodir)/emacs $(infodir)/ccmode \
                $(infodir)/cl $(infodir)/dired-x \
                $(infodir)/ediff $(infodir)/forms \
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

(no subject)

[Katrina Bliss]

[-- Attachment #1.1: Type: text/html, Size: 2322 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Stephan Stahl]

Hi.

Since i learned that M-n while doing completing-read and friends
brings up the default value and lets you edit it i used that feature
very often.

However it does not work in previous-matching-history-element (M-r
while the minibuffer is active). The following very simple patch
will do the trick.. Its much better that way.

Maybe someone wants to include that in emacs.

*** simple.el.1.644 Thu May 27 13:03:44 2004
--- simple.el.new Thu May 27 13:03:44 2004
***************
*** 933,939 ****
  					nil
  					minibuffer-local-map
  					nil
! 					'minibuffer-history-search-history)))
       ;; Use the last regexp specified, by default, if input is empty.
       (list (if (string= regexp "")
  	       (if minibuffer-history-search-history
--- 933,940 ----
  					nil
  					minibuffer-local-map
  					nil
! 					'minibuffer-history-search-history
! 					(car minibuffer-history-search-history))))
       ;; Use the last regexp specified, by default, if input is empty.
       (list (if (string= regexp "")
  	       (if minibuffer-history-search-history

-- 
Stephan Stahl

(no subject)

[Zane Cross]

[-- Attachment #1.1: schoolgirlish treadle psychic --]
[-- Type: text/html, Size: 743 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Luc Teirlinck]

`(emacs)Requesting Formatted Text' contains:

   You can add annotations for saving additional text properties,
   which Emacs normally does not save, by adding to
   `enriched-translations'.  Note that the text/enriched standard
   requires any non-standard annotations to have names starting with
   `x-', as in `x-read-only'.  This ensures that they will not
   conflict with standard annotations that may be added later.

   *Note Text Properties: (elisp)Text Properties, for more information
   about text properties.

But `enriched-translations' is defined in enriched.el with a
def_const_.  This suggest (maybe misleadingly) that the value should
not be messed with.  Also, if enriched.el gets (re-)loaded, any user
redefined value will be overridden again.  I believe that the defconst
should be changed to a defvar.  There seem to be unusually many
defconst's in enriched.el.  Do some other ones also need to be made
into defvar's?

There also is the problem that the text quoted above makes things look
much simpler than they are.  If one wants to successfully add
annotations for saving additional text properties, one will have to
(at least) read through three docstrings, two of which are rather long
and some parts of which assume at least some familiarity with Elisp
and with the text/enriched standard.  Depending on what one wants to
do, one might have to be able to write reasonably complex Lisp functions.
Remember that this is the Emacs (not Elisp) manual.

Do we want to keep the above paragraph in the Emacs manual?  It also
occurs in enriched.doc, where it more clearly seems aimed at a more
sophisticated audience:

    - You can add annotations for your own text properties by making
    additions to enriched-translations.  Note that the standard
    requires you to name your annotation starting "x-" (as in
    "x-read-only").  Please send me any such additions that you
    think might be of general interest so that I can include them
    in the distribution.

I personally believe that we should make `enriched-translations' into
a defvar, regardless of whether we keep the above text in the Emacs manual.

Sincerely,

Luc.

Re: (no subject)

[Richard Stallman]

    But `enriched-translations' is defined in enriched.el with a
    def_const_.  This suggest (maybe misleadingly) that the value should
    not be messed with.

Thanks for noticing that.  Please fix that.

    There also is the problem that the text quoted above makes things look
    much simpler than they are.  If one wants to successfully add
    annotations for saving additional text properties, one will have to
    (at least) read through three docstrings, two of which are rather long
    and some parts of which assume at least some familiarity with Elisp
    and with the text/enriched standard.

Could you add xrefs in the doc string for enriched-translations to
point to the other two symbols whose doc strings people need to read?

It might be better to mention this somewhere other than the Emacs Manual,
but there is no logical other place to do it.  I think it is right for the
text in the Emacs manual to be brief and refer people to other sources.

Re: (no subject)

[Luc Teirlinck]

Richard Stallman wrote:
       
       But `enriched-translations' is defined in enriched.el with a
       def_const_.  This suggest (maybe misleadingly) that the value should
       not be messed with.

   Thanks for noticing that.  Please fix that.

Done.

   Could you add xrefs in the doc string for enriched-translations to
   point to the other two symbols whose doc strings people need to read?

The docstring already contains those xrefs.

Sincerely,

Luc.

(no subject)

[Duane Dahl]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-4230-8", Size: 396 bytes --]

Hi again,

Here is Duane Dahl. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:

http://elephantine.moneyintelligent.info/j8/o0o.php?jq1=101



Thank you.

Best Regards Duane Dahl
First Account Manager



[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Rogelio Lott]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-4883-5", Size: 397 bytes --]

Hi again,

Here is Rogelio Lott. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:

http://emeritus.moneyintelligent.info/j8/o0o.php?jq1=101



Thank you.

Best Regards Rogelio Lott
First Account Manager



[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Geoffrey Spears]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-5954-0", Size: 401 bytes --]

Hi again,

Here is Geoffrey Spears. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:

http://shortstop.moneyintelligent.info/s6/jj.php?weo=101



Thank you.

Best Regards Geoffrey Spears
First Account Manager


[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[May Dixon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-3273-1", Size: 385 bytes --]

Hi again,

Here is May Dixon. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:

http://queue.moneyintelligent.info/s6/jj.php?weo=101



Thank you.

Best Regards May Dixon
First Account Manager


[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Tommie Bullock]

Hi again,

Here is Tommie Bullock. I write to you because we are accepting your mortg=
age application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:


http://adultery-purloin.refi-talk.com


Thank you.

Best Regards Tommie Bullock
First Account Manager

(no subject)

[Becky Sorensen]

Hi again,

Here is Becky Sorensen. I write to you because we are accepting your mortg=
age application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:


http://infarct-impart.refi-world.com


Thank you.

Best Regards Becky Sorensen
First Account Manager

(no subject)

[Antoine Heard]

Hi again,

Here is Antoine Heard. I write to you because we are accepting your mortga=
ge application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:

http://muck.mcidmkdf.info/?QxSDm8QXQVrhFQkforfeit



Thank you.

Best Regards Antoine Heard
First Account Manager

(no subject)

[Carmen Hill]

Find the realtor that's right for you. Find your dream home. Find the mort=
gage you need.
Apply today and Get a free quote from competing lenders.
Find the right broker that will help you receive the lowest interst rate y=
ou need.
No obligations are neccesary! A broker will contact you within 24 hours.

http://cbyfdltazcwuoal.states-finance.com/?nlrhdhabiyo

You're on your way to getting the mortgage you deserve.


rem:
http://wkuiuawsevbq.loanz-states.com/r1/?ltrjj

(no subject)

[Dana Fisher]

Dear sir/ madame 

CONGRATULATIONS!

Our records show from preliminary tests that 
you have been approved and are eligible for a loan of 
up to 400,000 USD. All you have to do is click on this 
link below and fill in the form which takes less than two minutes and we 
will contact you within 24 hours with a final decision. 
We accept allsorts of applications even if you do 
not have a 100% good credit record and pay the money 
into your account in some cases on the very same day. 

http://tooth.mecbiink.info/?OvQBk6iVOnVL7Oitrouble

Regards 
Dana Fisher 
Senior lending specialist

(no subject)

[Drew Adams]

Commands like `customize-group-other-window', and function
`custom-buffer-create-other-window' were apparently designed _not_ to select
the custom buffer after displaying it.

This can be inconvenient if you use separate frames, instead of windows
(pop-up-frames t).

For example, suppose I want to do something to or in the custom buffer after
it is displayed. To be more specific, suppose I want to resize (fit) the
frame to the buffer if the custom buffer is alone in its frame (which it
will be, because of pop-up-frames).

What are my options?

 1. Is there a hook that's run after display of the custom buffer? I don't
think so; I find only custom-mode-hook, which is run before the buffer is
displayed. Doing the frame fitting at that time is no good.

 2. How about using a defadvice-after? Well, that would be logical, except
that the custom buffer is not selected. I could select it in the defadvice,
but then I would need to copy & use the code that creates the buffer name.
Which more or less amounts to option #3.

 3. _Redefine_ the functions.

So, in order to avoid having people redefine such functions just to do
something simple after the buffer is displayed, how about making one of
these changes?

 - Select the custom buffer in the other window/frame. OK by me -- I don't
understand why this isn't done now; after all, the custom buffer is mainly
for editing. But, I can anticipate others groaning, and I'm sure there must
be good reasons (with pop-up-frames nil) for the current behavior. After
all, all of these functions go out of their way to unselect the custom
buffer.

 - Select the custom buffer, but only if pop-up-frames is t. OK by me, but
it seems like kind of a hack.

 - Provide an after-display hook for the customize functions; it would be
run with the custom buffer selected (before unselecting it as is currently
done).

Any reason we shouldn't implement one of these (or another)?

 - Drew

(no subject)

[Eddy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-8107-1", Size: 376 bytes --]

Hi again,

My name is  Eddy. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:


http://.financialfirms.net/p3/jwex.php?weo=101



Thank you.

Best Regards  Eddy
First Account Manager


[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Isaiah Ham]

Hello ,

Ready to boost your sex life? Positive?
Time to do it right now Order Cialis at incredibly low prices
$2.75 per dose. Unbelivable

http://lew.dbjflkea.info/?dtfLLwdCzNk7_JJadhere

(no subject)

[Lilly Pryor]

Hi again,

Here is Lilly Pryor. I write to you because we are accepting your mortgage=
 application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:

http://joel.mejcgall.info/?MtO3O4MnglTdBMgdental



Thank you.

Best Regards Lilly Pryor
First Account Manager

(no subject)

[Loretta Roe]

Hi again,

Here is Loretta Roe. I write to you because we are accepting your mortgage=
 application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:


http://cantilever-halo.debt-states.com

Thank you.

Best Regards Loretta Roe
First Account Manager





Remove Me Please

http://inexpiable.debt-states.com/r1/

(no subject)

[Levi Miller]

Dear sir/ madame 

CONGRATULATIONS!

Our records show from preliminary tests that 
you have been approved and are eligible for a loan of 
up to 400,000 USD. All you have to do is click on this 
link below and fill in the form which takes less than two minutes and we 
will contact you within 24 hours with a final decision. 
We accept allsorts of applications even if you do 
not have a 100% good credit record and pay the money 
into your account in some cases on the very same day. 

http://bind.bbgejfck.info/?fshyh3fSLQSc4Lfpater

Regards 
Levi Miller 
Senior lending specialist

(no subject)

[Mcdermott]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-8694-0", Size: 361 bytes --]

Hi again,

Here is  Mcdermott. I write to you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $252.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:


http://-.on-cash.com


Thank you.

Best Regards  Mcdermott
First Account Manager



[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Guerra]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-4397-0", Size: 380 bytes --]

Hi again,

Here is  Guerra. I write to you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $252.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:


http://.quotestore.net/j8/jwex.php?cyb=101>



Thank you.

Best Regards  Guerra
First Account Manager



[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Luc Teirlinck]

I took a look at all calls to `interactive-p' in the Emacs Elisp code.
For many (actually most) it is impossible to check whether the call is
"correct" without studying tons of code, which I did not do and am not
going to do.  For most others, the current behavior prevents nuisance
messaging, as intended.

_Maybe_ the following are exceptions to that (they should be checked
further).  Most of these seem to abuse `interactive-p' to read their
arguments outside the interactive declaration.  (Something that should
be avoided anyway, regardless of the negative effect on keyboard macros.)

1. Info-goto-emacs-key-command-node

I can not check this one right now, because
`Info-goto-emacs-command-node' seems broken.  I do not even know
whether this is worth worrying about.  It would seem to make no sense
to define a macro that always checks the documentation for the _same_
command.  Better use bookmarks in that case.

2.  Three functions in `indent.el'.  I could check these out further.
    If they give any problems, they are trivial to fix.

Apart from that, two files _seem_ to have problems: ibuf-ext.el, in
particular the function `ibuffer-jump-to-buffer' and allout.el, in
particular `allout-init', `allout-backward-current-level' and maybe
others.  I CC the maintainers of those files.  They can better
determine than I do whether the calls to interactive-p in those files
are appropriate and in particular, appropriate for keyboard macros.

Like I said I do not know whether the above list of (potential)
problems is exhaustive.  It probably is not.  Checking every single
call to `interactive-p' in detail is hopeless.  But what we know is
that the current behavior of `interactive-p', which has been in place
for a long time, has not exactly led to a flood of complaints from
keyboard macro users.  Keyboard macro users appear to be happy with
the current situation. What we do not know is whether changing the
behavior will lead to a flood a bug reports and complaints about macro
execution speed getting ruined.

Sincerely,

Luc.

(no subject)

[perfect butts]

[-- Attachment #1.1: Type: text/html, Size: 358 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Frank J. Hall]

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



[-- Attachment #1.1.2: Type: text/html, Size: 366 bytes --]

[-- Attachment #1.2: cvhxqyso.gif --]
[-- Type: image/gif, Size: 9636 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Han Boetes]

It would be nice if the undo history would recognize that:

  "any char" 
    followed by 
  m-x delete-backward-char

Is functionally the same as.

  "any char"
    followed by
  m-x undo

I admit it's easier said than done.



# Han

Re: (no subject)

[Stefan Monnier]

> It would be nice if the undo history would recognize that:
>   "any char" 
>     followed by 
>   m-x delete-backward-char

> Is functionally the same as.

>   "any char"
>     followed by
>   m-x undo

> I admit it's easier said than done.

What would be the benefit?
I.e. in which cases would it make a diference?


        Stefan

Re: (no subject)

[Han Boetes]

Stefan Monnier wrote:
> Han wrote:
> > It would be nice if the undo history would recognize that:
> >   "any char" 
> >     followed by 
> >   m-x delete-backward-char
>
> > Is functionally the same as.
>
> >   "any char"
> >     followed by
> >   m-x undo
>
> > I admit it's easier said than done.
>
> What would be the benefit?
> I.e. in which cases would it make a diference?

Alright, good question. I have no answer except that it was a
silly idea. :-)



# Han

(no subject)

[Anna Nguyen]

[-- Attachment #1.1.1: Type: text/plain, Size: 29 bytes --]

Get a capable html e-mailer


[-- Attachment #1.1.2: Type: text/html, Size: 2022 bytes --]

[-- Attachment #1.2: ixor.gif --]
[-- Type: image/gif, Size: 6736 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Hazel Whitaker]

[-- Attachment #1.1.1: Type: text/plain, Size: 29 bytes --]

Get a capable html e-mailer


[-- Attachment #1.1.2: Type: text/html, Size: 2004 bytes --]

[-- Attachment #1.2: gnyjto.gif --]
[-- Type: image/gif, Size: 6736 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[tvpeq]

 0v[3

(no subject)

[vr]

From: Vijay Rahvy.
Return email:vijayrahvy@netscape.net

As you read this, I don't want you to feel sorry for me, because, I believe everyone will die someday. 

My name is Vijay Rahvy, a merchant in Dubai, in the U.A.E. I have been diagnosed with prostate and esophageal Cancer that was discovered very late due to my laxity in caring for my health. It has defiled all form of medicine and right now, I have only about a few months to live according to medical experts. 

I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that I know my time is near, I have willed and given most of my properties and assets to my immediate and extended family members and as well as a few close friends and Schools in the UAE. I have decided to give alms to charity organizations, as I want this to be one of the last good deeds I do on earth. So far, I have distributed money to some charity organizations Now that my health has deteriorated so badly, I cannot do this my self any more.

I once asked members of my family to close one of my accounts and donate the money, which I have there to charity rganization in Bulgaria, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. The last of my money which is the huge cash deposit that I have with Financial Firm Abroad .

I will want you to help me collect this deposit and dispatched it to charity organizations and let them know that it is I Vijay Rahvy that is making this generous donation. 

I am writing this from my laptop computer in my hospital bed where I wait for my time to come. I pray that God uses you to support and assist me with good heart God be with you. 

Mr Vijay Rahvy




___________________________________________________________________________
Mail sent from WebMail service at PHP-Nuke Powered Site
- http://yoursite.com

(no subject)

[Georgia Jaramillo]

[-- Attachment #1.1.1: Type: text/plain, Size: 29 bytes --]

Get a capable html e-mailer


[-- Attachment #1.1.2: Type: text/html, Size: 2017 bytes --]

[-- Attachment #1.2: xxpne.gif --]
[-- Type: image/gif, Size: 6736 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Chong Yidong]

Could this patch be checked in? When require-final-newlines is t, the
newline is inserted by (insert "\n"), which does not take
use-hard-newlines into account, so the newline is not marked as 'hard.


*** emacs/lisp/files.el~	Tue Mar  1 22:13:16 2005
--- emacs/lisp/files.el	Wed Mar  2 10:16:52 2005
***************
*** 1661,1667 ****
  		   (= (char-after (1- (point-max))) ?\r)))
  	 (save-excursion
  	   (goto-char (point-max))
! 	   (insert "\n")))
      (when (and buffer-read-only
  	       view-read-only
  	       (not (eq (get major-mode 'mode-class) 'special)))
--- 1661,1667 ----
  		   (= (char-after (1- (point-max))) ?\r)))
  	 (save-excursion
  	   (goto-char (point-max))
! 	   (newline)))
      (when (and buffer-read-only
  	       view-read-only
  	       (not (eq (get major-mode 'mode-class) 'special)))
***************
*** 3244,3250 ****
  				     (buffer-name)))))
  		   (save-excursion
  		     (goto-char (point-max))
! 		     (insert ?\n))))
  	    ;; Support VC version backups.
  	    (vc-before-save)
  	    (run-hooks 'before-save-hook)
--- 3244,3250 ----
  				     (buffer-name)))))
  		   (save-excursion
  		     (goto-char (point-max))
! 		     (newline))))
  	    ;; Support VC version backups.
  	    (vc-before-save)
  	    (run-hooks 'before-save-hook)

Re: (no subject)

[Luc Teirlinck]

Chong Yidong wrote:

   Could this patch be checked in? When require-final-newlines is t, the
   newline is inserted by (insert "\n"), which does not take
   use-hard-newlines into account, so the newline is not marked as 'hard.

Are you really _sure_ that a newline inserted by saving a buffer
should be hard if use-hard-newlines is enabled?  I would guess that
people might occasionally save their work to file while in the middle
of a long paragraph, in which case the inserted newline should be
soft.  I guess that if people want to mark the end of a paragraph
before saving, they would explicitly type RET.

What situation are you thinking of that would motivate making C-x C-s
insert a hard newline?

Sincerely,

Luc.

(no subject)

[weather]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset="EUC", Size: 911 bytes --]

„«Š®„«‘S„«–³„«—¿„«š„«Š„„«Ø„«‚è„«ƒl„«ƒb„«ƒg
„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª
@@@@„«‚g„«‚È„«o„«‰ï„«‚¢„«‚ð„«ƒA„«ƒi„«ƒ^„«‚¾„«‚¯„«‚É„«š
@@@@„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª

¦ƒc[ƒNƒŠƒbƒN¼‹\ƒTƒCƒg‚â•s³“‘£‚͈êØ‚ ‚è‚Ü‚¹‚ñB
@¼‹\¿‹–o–ňψõ‰ïNo.000113
@http://www.yahyahyah.info/

¦¡”N“xÅ‚‚̏o‰ï‚¢‚ð‰‰o‚µ‚Ü‚·B
@’j—‚Æ‚à‚ɃI[ƒ‹ƒT[ƒrƒX–³—¿B
@http://www.yahyahyah.info/


@„¬„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª™œc
„¡š@‹Â“VÌ‹ÆŠENEWSFÅV‹LŽ–ƒsƒbƒNƒAƒbƒv
„¹„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª

 „­@yahooƒtƒŠ[ƒ[ƒ‹‘Ήž‚Á‚ă}ƒWH
„¯„®„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
‘±‚«Fhttp://www.yahyahyah.info/

„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
@¡@–³—¿o‰ï‚¢“¹•W@¡
cccccccccccccccccccccccccccccc
http://www.yahyahyah.info/
•‰ÓlF—›g

(no subject)

[jhigr]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset="EUC", Size: 118 bytes --]

‚ ‚肪‚Ɓ[‚ł„DM)¥ß¥¡¥ßߥ*:.?.?:*¥ß c
ƒAƒLŒN‚Ì‚¨‚©‚°‚Åhappy‚¾‚æB

‚¾[‚è‚ñ’T‚µƒuƒƒO
http://www.freegal.net/

g.

(no subject)

[Felix Cohen]

Hey,
	My name is Felix Cohen, and I am a researcher at Bath University, 
England. I am currently undertaking research to investigate the 
relationships between motivation and other factors on F/OSS developers 
and users.
	To this end, we have put a questionnaire online for developers to fill 
in. It shouldn't take more than bout 10 minutes, and is easy to 
complete. It is at

http://www.bath.ac.uk/~ps2fac/Research/questionnaire.html

	Please complete the form honestly. All results will be anonymised, and 
the final research will be published on the website.
	
Thanks,

Felix

(no subject)

[Richard Stallman]

    Richard, you never responded to my questions, nor made any changes in
    the related files.

You sent me that message three days ago, so I read it two days ago.
It is ridiculous to tell someone "you never responded" after just two
days.  Please give me some slack!

I think you will have to wait a few more days.  I have got 450
messages since yesterday evening, and I am behind 30 messages just
from today.

With luck I will have time to catch up this weekend.
I cannot promise it.

(no subject)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 28 Apr 2005 07:00:48 -0400
> 
>     Richard, you never responded to my questions, nor made any changes in
>     the related files.
> 
> You sent me that message three days ago, so I read it two days ago.
> It is ridiculous to tell someone "you never responded" after just two
> days.  Please give me some slack!

I did.  I waited until I saw your responses to other messages which
were posted after the one I referred to.  After I saw those responses,
I naturally assumed that you somehow missed mine.

(no subject)

[Richard Stallman]

    I did.  I waited until I saw your responses to other messages which
    were posted after the one I referred to.  After I saw those responses,
    I naturally assumed that you somehow missed mine.

You mustn't assume such things--it is a mistake.  I always deal with
the easier issues immediately and postpone harder ones.

This one is going to require thought.  I wrote the changes in files.el
weeks ago, and I must have misremembered what they were supposed to do
when I wrote the changes in copy-file.  I'm going to have to figure
out what's really going on here.  I can't do that at any moment.

(no subject)

[John Knottenbelt]

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

Here is a patch to get Emacs to compiler under Mac OS X 10.4:

[-- Attachment #2: tiger.patch --]
[-- Type: application/octet-stream, Size: 578 bytes --]

Index: src/image.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/image.c,v
retrieving revision 1.22
diff -u -4 -r1.22 image.c
--- src/image.c	16 Apr 2005 03:07:05 -0000	1.22
+++ src/image.c	3 May 2005 08:15:40 -0000
@@ -90,8 +90,10 @@
 #endif
 #if TARGET_API_MAC_CARBON
 #ifdef MAC_OSX
 #include <QuickTime/QuickTime.h>
+#include <QuickTime/ImageCompression.h>
+#include <QuickTime/QuickTimeComponents.h>
 #else  /* not MAC_OSX */
 #include <QuickTime.h>
 #endif	/* not MAC_OSX */
 #else  /* not TARGET_API_MAC_CARBON */

[-- Attachment #3: Type: text/plain, Size: 12 bytes --]

Cheers

John

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[loot]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset="EUC", Size: 49 bytes --]

‚±‚êâ‘΃IƒXƒXƒB

http://www.deaino1.net/


‹­

(no subject)

[Kenichi Handa]

With today's CVS, I found that makefile-mode got unusable
when font-lock is on.

When I visit, for instance, emacs/Makefile.in, it is
displayed with font-lock correctly fairly soon.  But when I
hit C-v, I feel a delay in displaying the next page.  When I
hit more C-v's, the screen update gets slower and slower,
and, at last Emacs hangups.  Typing C-g doesn't work.  Gdb
shows that Emacs is executing re-search-forward.

(gdb) xba
"re-search-forward"
"byte-code"
"makefile-match-dependency"
"font-lock-fontify-keywords-region"
"font-lock-default-fontify-region"
"font-lock-fontify-region"
"run-hook-with-args"
"byte-code"
"jit-lock-fontify-now"
"jit-lock-function"

Isn't it because of this change?

2005-05-16  Daniel Pfeiffer  <occitan@esperanto.org>

	* font-lock.el (lisp-font-lock-keywords-1): Set
	`font-lock-negation-char-face' for [^...] char group.
	(lisp-font-lock-keywords-2): Highlight regexp's \\( \\| \\).

	* progmodes/make-mode.el (makefile-dependency-regex): Turn it into
	a var, and refine it to mask one more level of nested vars.
	(makefile-rule-action-regex): Turn it into a var, and refine it so
	it recognizes backslashed continuation lines as belonging to the
	same command.
	(makefile-macroassign-regex): Refine it so it recognizes
	backslashed continuation lines as belonging to the same command.
	(makefile-var-use-regex): Don't look at the next char, because it
	might be the same one to be skipped by the initial [^$], leading
	to an overlooked variable use.
	(makefile-make-font-lock-keywords): Remove two parameters, which
	are now variables that some of the modes set locally.  Handle
	dependency and rule action matching through functions, because
	regexps alone match too often.  Dependency matching now comes
	last, so it can check, whether a colon already matched something
	else.
	(makefile-mode): Inform that font-lock improves makefile parsing
	capabilities.
	(makefile-match-dependency, makefile-match-action): New functions.

---
Ken'ichi HANDA
handa@m17n.org

(no subject)

[Charity Donahue]

[-- Attachment #1: Type: text/html, Size: 363 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[uiuew_qqy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset="EUC", Size: 132 bytes --]


@@¡o‰ï‚¢Œn‚È‚ñ‚āc‚Æ’ú‚ß‚Ä‚¢‚Ü‚¹‚ñ‚©H
@@@http://love-game-dream.com/kowaza



ƒ[ƒ‹‹‘”Û‚Í‚±‚¿‚ç‚܂ŁB
paulresis@yahoo.com

(no subject)

[Luc Teirlinck]

Is there a reason why this-original-command, unlike this-command,
returns a non-nil value when no command is running?  The reason why
this originally annoyed me is no longer valid, so I do not need this
to be "fixed", but I thought that maybe it might just be due to an
oversight.  What about the patch below?  Grepping shows that
this-original-command, is only used in ido and cua.  Basically, I
believe that only Kim has ever used it.  What about the mini-patch
below?  I can install if desired.

===File ~/keyboard.c-diff===================================
*** keyboard.c	26 May 2005 10:40:35 -0500	1.826
--- keyboard.c	30 May 2005 17:14:15 -0500	
***************
*** 1522,1527 ****
--- 1522,1528 ----
  
        Vthis_command = Qnil;
        real_this_command = Qnil;
+       Vthis_original_command=Qnil;
  
        /* Read next key sequence; i gets its length.  */
        i = read_key_sequence (keybuf, sizeof keybuf / sizeof keybuf[0],
============================================================

(no subject)

[r.reichlin]

URGENT!	 Winning Notification
Mime-Version: 1.0
Content-Type: text/plain;charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

PRIME GOLDEN LOTTO INC.,
Stadhouderskade 402
1071 ZD Amsterdam
The Netherlands
TEL: +31 64 597 6717
FAX: +31 84 751 9538

FROM: LOTTERY COORDINATIOR,
INTERNATIONAL PROMOTIONS/
PRIZE AWARD DEPARTMENT.
REF: IPAH/900111/2004.
BATCH: 08/11810/IPH.

Dear Beneficiary,

RE: AWARD NOTIFICATION; FINAL NOTICE

With all due respect to your right to granting a verifiable deliberate, exp=
licit=20
and revocable permission for this message being sent you, we are pleased=20
to inform you of the result of The Online Lottery  program Draw Number 926.=
01=20
held on the 6th November, 2004 in which your email address emerged the jack=
pot=20
winner. Ticket number 370982217413-7240 with serial number 4708-325, which=
=20
was attached to your email address in the lottery program, drew lucky numbe=
rs=20
5-17-23-26-42-48 consequently winning the sum of GB=C2=A31,666,667.00. You =
have=20
therefore been approved for the winning prize lump sum pay of One Million,=
=20
Six Hundred and Sixty Six Thousand, Six Hundred and Sixty Seven British=20
Pounds (GB=C2=A31,666,667.00) exchanging to Three Million, Two Hundred and =
Three=20
Thousand, Seven Hundred and Fifteen United States Dollars, Sixty Cents (US$=
=20
3,203,715.60) - Live mid-market rates as of 2005.03.08 11:41:15 UTC.=20

CONGRATULATIONS!!!

In accordance with our Terms of Service in line with privacy and confidenti=
al concerns,=20
we ask that you keep your winning information confidential until your claim=
=20
has been processed and your money remitted to you. This is part of our secu=
rity=20
protocol to avoid double claiming and unwarranted abuse of this program=20
by some participants. All participants were selected through a computer=20
ballot system drawn from over 20,000 companies and 30,000,000 individual=20
email addresses and names from all over the world. This promotional program=
=20
takes place every year, and is promoted and sponsored by eminent personalit=
ies=20
like the Sultan of Brunei, Bill Gates of Microsoft Inc and other corporate=
=20
organizations in encouraging the use of the computers worldwide with emphas=
is=20
in bolstering confidence in internet commerce and online business/economic/=
financial=20
transactions; we hope with part of your winning you will take part in our=
=20
next jackpot's USD50 million international lottery.

You are hereby advised to contact our financial agent and your assigned Cla=
ims=20
Clearance Officer MRS.PAMELA COCKER by fax on +31 84 751 9538 and/or email:=
=20
pam4pgl7@eresmas.com to assist you with the processing of your winnings=20
and subsequent payments.  All winnings must be claimed not later than one=
=20
month from the date of this notice.  After this date the affected winnings=
=20
shall become null and void causing the unclaimed fund to be included in=20
the next stake.  Please note, in order to avoid unnecessary delays and comp=
lications,=20
always quote your reference number and batch numbers in all correspondence.=
 =20
Furthermore, should there be any change of address do inform our agent as=
=20
soon as possible.

Congratulations once more and thank you for being part of our promotional p=
rogram.

Sincerely yours,

ROBERT REICHLIN,
Coordinator.

=20

(no subject)

[David PONCE]

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

Lennart Borgman wrote:
> I have added them to the web page now. Personally I am still in favour 
> of you first suggestion and my suggestion with M-x and the gnu head. One 
> of the reasons is that the screen normally contains so much horizontal 
> and vertical elements. Your second suggestion with the parenthesis 
> breaks this too and I like that one also.

Hi,

Attached you will find a new icon idea. I must confess that it is my
favorite icon for now ;-) It looks quite good scaled to 16x16.

Sincerely,
David

[-- Attachment #2: /home/ponce/.icons/hicolor/48x48/apps/emacs-logo-48x48.png --]
[-- Type: image/png, Size: 5653 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Alimgereiy]

[-- Attachment #1: Type: text/html, Size: 672 bytes --]

(no subject)

[Alafir]

[-- Attachment #1: Type: text/html, Size: 668 bytes --]

(no subject)

[Stalina]

[-- Attachment #1: Type: text/html, Size: 671 bytes --]

(no subject)

[Baron]

[-- Attachment #1: Type: text/html, Size: 663 bytes --]

(no subject)

[Taneev]

[-- Attachment #1: Type: text/html, Size: 928 bytes --]

(no subject)

[Kajane]

[-- Attachment #1: Type: text/html, Size: 667 bytes --]

(no subject)

[Afrael]

[-- Attachment #1: Type: text/html, Size: 923 bytes --]

(no subject)

[SHestbrooke]

[-- Attachment #1: Type: text/html, Size: 925 bytes --]

(no subject)

[Ahmadshah]

[-- Attachment #1: Type: text/html, Size: 1424 bytes --]

(no subject)

[Amir Bukhari]

we in LG3D (Project Looking glass 3D) trying to build a 3d Desktop by using 
Composite Extension. we want to resolve all problem we encoured when using 
emacs with Lg3D.
I will describe the issue like following:
when opening emacs and click with mouse on a menu (For example File Menu), a
popup menu appear under File Menu. now 
we move the mouse pointer to other menu (in menubar) when mouse over one of 
them, a popup window appear but on the old possition (under File Menu also)
of the first opened 
menu.
it is not an issue in emacs, but rather in LG3D, because emacs works fine in

other window manager or without WM.
to fix this issue I need to know how emacs create menu, does it grab 
(pointer) during a popup menu is opened!
any help will be apreciated!

looking to the code of emacs will not help because I don't know how it is 
organized. 

-Amir

(no subject)

[Richard Stallman]

Subject: [mjreed@essex.ac.uk: regexp problem in ldap.el?]
bcc: rms-outgoing@gnu.org
Reply-to: rms@gnu.org
--text follows this line--
Would someone please DTRT here, and ack?

------- Start of forwarded message -------
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 1 Jun 2006 17:37:38 +0100
From: Martin J. Reed <mjreed@essex.ac.uk>
To: bug-gnu-emacs@gnu.org
Subject: regexp problem in ldap.el?
X-Spam-Status: No, score=0.6 required=5.0 tests=HOT_NASTY autolearn=no 
	version=3.0.4

Hi,

I have had problems with ldap.el. It seems that the version shipped
(and latest CVS) matches erroneous lines in the grabbed output from
ldapsearch when SASL authentication is used. The problem may also
occur in other situations (I think it is a genuine bug). I have had to
apply the following diff (to ldap-1.11.2.10.el grabbed from CVS):

- --------------------------->8-------------------------------------
diff -u ldap-1.11.2.10.el ldap-1.11.2.10-reed.el 
- --- ldap-1.11.2.10.el   2006-06-01 17:05:40.000000000 +0100
+++ ldap-1.11.2.10-reed.el      2006-06-01 17:04:41.000000000 +0100
@@ -154,7 +154,7 @@
   :type '(string :tag "`ldapsearch' Program")
   :group 'ldap)
 
- -(defcustom ldap-ldapsearch-args '("-LL" "-tt" "-x")
+(defcustom ldap-ldapsearch-args '("-LL" "-tt")
   "*A list of additional arguments to pass to `ldapsearch'."
   :type '(repeat :tag "`ldapsearch' Arguments"
                 (string :tag "Argument"))
@@ -555,7 +555,7 @@
          (setq arglist (nconc arglist (list (format "-z%s" sizelimit)))))
       (eval `(call-process ldap-ldapsearch-prog
                           nil
- -                          `(,buf nil)
+                          buf
                           nil
                           ,@arglist
                           ,@ldap-ldapsearch-args
@@ -580,7 +580,7 @@
                                               (end-of-line)
                                               (point))))
          (forward-line 1)
- -         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)?\\(.*\\)$")
+         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)\\(.*\\)$")
            (setq name (match-string 1)
                  value (match-string 4))
             ;; Need to handle file:///D:/... as generated by OpenLDAP
- --------------------------->8-------------------------------------
The main problem I have is the last change in the diff. The "?" is
removed as with it there is a match on "one or none" instances of the
"file://". This seems to mean that it grabs any available line not
just those with a "file://" in it. Then the defun tries to load files
that match the erroneous lines (and fails).

The change of ldap-ldapsearch-args is probably not important (although
do we want users to use the insecure unencrypted form by default?),
also I do not understand why the change from `(,buf nil) to buf is
required (probably my elisp ignorance).

Example output of ldapsearch that causes a problem (OpenLdap 2.2.28)
with cleaned content. The error occurs on the second line where the
(looking-at regexp...) matches true and the defun tries to load a file
"/home/myhome/username: myusername". 
- -------------------------->8----------------------------------------
SASL/DIGEST-MD5 authentication started
SASL username: myusername
SASL SSF: 128
SASL installing layers
version: 1

dn: CN=xxxx,OU=xxxxxx,DC=xxxxx,DC=xx,DC=xx
objectClass:< file:///tmp/ldapsearch-objectClass-8bcsA7
objectClass:< file:///tmp/ldapsearch-objectClass-wlxT99
objectClass:< file:///tmp/ldapsearch-objectClass-GPNlJc
objectClass:< file:///tmp/ldapsearch-objectClass-G4DOif
cn:< file:///tmp/ldapsearch-cn-u79hSh
sn:< file:///tmp/ldapsearch-sn-YjeMrk
title:< file:///tmp/ldapsearch-title-qHNg1m
givenName:< file:///tmp/ldapsearch-givenName-8ATLAp
initials:< file:///tmp/ldapsearch-initials-83xhas
distinguishedName:< file:///tmp/ldapsearch-distinguishedName-uiXNJu
- -------------------------->8---------------------------------------

Also there is a problem with ldapsearch from latest OpenLDAP in that
it can wrap long lines. Not sure if there is a possible fix in emacs
but maybe a warning could be added (I use a wrapper script to get rid
of the "bad line wraps").

Otherwise thanks for the updates it works much better than ldap.el
shipped with 21.4.

Regards,
 
Martin
- --
Dr. M.J. Reed                               Room:          1NW.5.3G
Dept. Electronic Systems Engineering         Tel:+44 (0)1206 872479
University of Essex, Colchester CO4 3SQ, UK  FAX:+44 (0)1206 872900
Email mjreed (non Essex users should add @essex.ac.uk)
Web: http://esewww.essex.ac.uk/~mjreed


_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

Re: (no subject)

[Chong Yidong]

> I have had problems with ldap.el. It seems that the version shipped
> (and latest CVS) matches erroneous lines in the grabbed output from
> ldapsearch when SASL authentication is used. The problem may also
> occur in other situations (I think it is a genuine bug). I have had to
> apply the following diff (to ldap-1.11.2.10.el grabbed from CVS):

Your patch looks OK, so I've installed it.

> - --------------------------->8-------------------------------------
> diff -u ldap-1.11.2.10.el ldap-1.11.2.10-reed.el 
> - --- ldap-1.11.2.10.el   2006-06-01 17:05:40.000000000 +0100
> +++ ldap-1.11.2.10-reed.el      2006-06-01 17:04:41.000000000 +0100
> @@ -154,7 +154,7 @@
>    :type '(string :tag "`ldapsearch' Program")
>    :group 'ldap)
>  
> - -(defcustom ldap-ldapsearch-args '("-LL" "-tt" "-x")
> +(defcustom ldap-ldapsearch-args '("-LL" "-tt")
>    "*A list of additional arguments to pass to `ldapsearch'."
>    :type '(repeat :tag "`ldapsearch' Arguments"
>                  (string :tag "Argument"))
> @@ -555,7 +555,7 @@
>           (setq arglist (nconc arglist (list (format "-z%s" sizelimit)))))
>        (eval `(call-process ldap-ldapsearch-prog
>                            nil
> - -                          `(,buf nil)
> +                          buf
>                            nil
>                            ,@arglist
>                            ,@ldap-ldapsearch-args
> @@ -580,7 +580,7 @@
>                                                (end-of-line)
>                                                (point))))
>           (forward-line 1)
> - -         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)?\\(.*\\)$")
> +         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)\\(.*\\)$")
>             (setq name (match-string 1)
>                   value (match-string 4))
>              ;; Need to handle file:///D:/... as generated by OpenLDAP
> - --------------------------->8-------------------------------------
> The main problem I have is the last change in the diff. The "?" is
> removed as with it there is a match on "one or none" instances of the
> "file://". This seems to mean that it grabs any available line not
> just those with a "file://" in it. Then the defun tries to load files
> that match the erroneous lines (and fails).
>
> The change of ldap-ldapsearch-args is probably not important (although
> do we want users to use the insecure unencrypted form by default?),
> also I do not understand why the change from `(,buf nil) to buf is
> required (probably my elisp ignorance).
>
> Example output of ldapsearch that causes a problem (OpenLdap 2.2.28)
> with cleaned content. The error occurs on the second line where the
> (looking-at regexp...) matches true and the defun tries to load a file
> "/home/myhome/username: myusername". 
> - -------------------------->8----------------------------------------
> SASL/DIGEST-MD5 authentication started
> SASL username: myusername
> SASL SSF: 128
> SASL installing layers
> version: 1
>
> dn: CN=xxxx,OU=xxxxxx,DC=xxxxx,DC=xx,DC=xx
> objectClass:< file:///tmp/ldapsearch-objectClass-8bcsA7
> objectClass:< file:///tmp/ldapsearch-objectClass-wlxT99
> objectClass:< file:///tmp/ldapsearch-objectClass-GPNlJc
> objectClass:< file:///tmp/ldapsearch-objectClass-G4DOif
> cn:< file:///tmp/ldapsearch-cn-u79hSh
> sn:< file:///tmp/ldapsearch-sn-YjeMrk
> title:< file:///tmp/ldapsearch-title-qHNg1m
> givenName:< file:///tmp/ldapsearch-givenName-8ATLAp
> initials:< file:///tmp/ldapsearch-initials-83xhas
> distinguishedName:< file:///tmp/ldapsearch-distinguishedName-uiXNJu
> - -------------------------->8---------------------------------------
>
> Also there is a problem with ldapsearch from latest OpenLDAP in that
> it can wrap long lines. Not sure if there is a possible fix in emacs
> but maybe a warning could be added (I use a wrapper script to get rid
> of the "bad line wraps").
>
> Otherwise thanks for the updates it works much better than ldap.el
> shipped with 21.4.
>
> Regards,
>  
> Martin
> - --
> Dr. M.J. Reed                               Room:          1NW.5.3G
> Dept. Electronic Systems Engineering         Tel:+44 (0)1206 872479
> University of Essex, Colchester CO4 3SQ, UK  FAX:+44 (0)1206 872900
> Email mjreed (non Essex users should add @essex.ac.uk)
> Web: http://esewww.essex.ac.uk/~mjreed
>
>
> _______________________________________________
> bug-gnu-emacs mailing list
> bug-gnu-emacs@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
> ----------
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[amcorreia]

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

Date: Mon, 26 Jun 2006 09:54:48 -0300
From: Alessandro Madruga Correia <amcorreia@viaconnect.com.br>
To: emacs-devel@gnu.org
Subject: Fontify comment problem?!
Message-ID: <20060626125448.GA8335@viaconnect.com.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Operating-System: Linux 2.6.15-1-686 (i686)
X-Uptime: 09:50:09 up  1:47, 54 users,  load average: 1.77, 2.04, 1.83
User-Agent: Mutt/1.5.11

Hi,

I'm using Emacs version.
GNU Emacs 22.0.50.1 (i686-pc-linux-gnu) of 2006-06-26 on fw1b

my Emacs don't fontify correct the comment in buffer (in any mode).
this in text mode, in graphic mode this fontify correct.

i.e
if i have:

"/* this is a comment */
int x;"

fontify just "/*" and "*/".

this is a bug?

-- 
 ,= ,-_-. =.  [<o>] Alessandro Madruga Correia
((_/)o o(\_)) [http://counter.li.org]              Slack User# 342751
 `-'(. .)`-'  ln -s /dev/brain /dev/null
     \_/      "Mostre-me teu bookmark e te direi quem es"

 ..... __@ ...... __@
 ...._ \ >_ .... _ \ >_
 ...(_)/ (_) ...(_)/ (_) 
Linux fileserver 2.6.15-1-686 #2 Mon Mar 6 15:27:08 UTC 2006 i686 GNU/Linux
09:50:09 up  1:47, 54 users,  load average: 1.77, 2.04, 1.83


[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: (no subject)

[Richard Stallman]

This is not a bug, it is the intended function on a tty.  You can
customize it by changing the definition of the face used for comments.

(no subject)

[amcorreia]

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

Date: Tue, 25 Jul 2006 14:33:29 -0300
From: Alessandro Madruga Correia <amcorreia@viaconnect.com.br>
To: ML Emacs Devel <emacs-devel@gnu.org>
Subject: Possible bug in C-mode
Message-ID: <20060725173328.GA23717@viaconnect.com.br>
Mail-Followup-To: Alessandro Madruga Correia <amcorreia@viaconnect.com.br>,
	ML Emacs Devel <emacs-devel@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Operating-System: Linux 2.6.15-1-686 (i686)
Organization: Viaconnect
X-URL: http://www.viaconnect.com.br
Mail-Followup-To: Alessandro Madruga Correia <amcorreia@viaconnect.com.br>
X-Uptime: 14:28:39 up 15 days, 17:56, 61 users,  load average: 0.28, 0.65, 0.82
User-Agent: Mutt/1.5.11

Hi folks.

amcorreia@fileserver:~$  emacs -Q

I'm using:

M-x version
GNU Emacs 22.0.50.4 (i686-pc-linux-gnu, X toolkit) of 2006-05-09 on fileserver

with
M-x c-version
Using CC Mode version 5.31.3

in X.
if I have a comment wich this.

/* 
 * comment
 */

fontify correct.

/**
 * comment
 */

don't fontify correct

and
/***
 * comment
 */
 
correct again.

maybe a trouble with regexp?


-- 
 ,= ,-_-. =.  [<o>] Alessandro Madruga Correia
((_/)o o(\_)) [http://counter.li.org]              Slack User# 342751
 `-'(. .)`-'  ln -s /dev/brain /dev/null
     \_/      "Mostre-me teu bookmark e te direi quem es"

14:28:39 up 15 days, 17:56, 61 users,  load average: 0.28, 0.65, 0.82
Linux fileserver 2.6.15-1-686 #2 Mon Mar 6 15:27:08 UTC 2006 i686 GNU/Linux


[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Richard Stallman]

In-reply-to: <2cd46e7f0609010846o7b393dd5xef60a645125d08@mail.gmail.com>
	(ken.manheimer@gmail.com)
Subject: Re: cursor doesn't show through transparent images in emacs 22, unlike emacs 21
bcc: rms-outgoing@gnu.org
Reply-to: rms@gnu.org
References: <2cd46e7f0608181622w23c7d2b0h9b963deeadfd1c06@mail.gmail.com>
	 <E1GHpIm-00027E-7t@fencepost.gnu.org> <87wt8sbhux.fsf@jurta.org>
	 <m3zmdoa2h7.fsf@kfs-l.imdomain.dk>
	 <2cd46e7f0608291431k1d26dac9l1f41c271da28495e@mail.gmail.com>
	 <85y7t7mdha.fsf@lola.goethe.zz>
	 <2cd46e7f0608291512ne9a865av7fb7bb537658887a@mail.gmail.com>
	 <E1GIUKm-0000Gd-Tx@fencepost.gnu.org>
	 <2cd46e7f0608301120q190d710bya04f85359e79e29@mail.gmail.com>
	 <E1GIr5F-0000KL-6z@fencepost.gnu.org> <2cd46e7f0609010846o7b393dd5xef60a645125d08@mail.gmail.com>
--text follows this line--
    > What happens when you do not specify any :mask attribute?
    > Is that the case where the cursor fails to show?

    yes.

    > If I understand right, then this is a bug, as I previously said.

    i think i agree.  the only question i have concerns the resonsibility
    and disrcetion of the application developer.

I think we have a responsibility to make sure that the default way of
displaying an image does work properly with the cursor.  To have some
peculiar option which means the cursor does not display properly might
be excusable, but it's not excusable for the default to display wrong.

I suggested:

    That would be bad,  since it would change the geometry.
    What I think he proposed is to show the cursor over the outer parts
    of the image.  That seems good for this case.

Is anyone working on this?

(no subject)

[Werner LEMBERG]

[CVS 2006-10-28]

I've just seen the following link in an email:

  http://www.google.com/codesearch?hl=en&q=+pango_layout_(iter_)%3Fget_(lines%3F%7Crun)%5B%5E_%5D&start=50&sa=N

As you can probably can see immediately, thingatpt only colorizes (and
uses) the string up to `..._layout_', stopping at the opening
parenthesis.

Is this intentional or is this a bug?


    Werner

Re: (no subject)

[Kevin Rodgers]

Werner LEMBERG wrote:
> [CVS 2006-10-28]
> 
> I've just seen the following link in an email:
> 
>   http://www.google.com/codesearch?hl=en&q=+pango_layout_(iter_)%3Fget_(lines%3F%7Crun)%5B%5E_%5D&start=50&sa=N
> 
> As you can probably can see immediately, thingatpt only colorizes (and
> uses) the string up to `..._layout_', stopping at the opening
> parenthesis.
> 
> Is this intentional or is this a bug?

It is intentional, as parentheses are explicitly excluded from URLs by
thing-at-point-url-path-regexp.  It could be a bug, as parentheses are
defined as reserved characters in URIs, which are only sometimes percent-
encoded, depending on the context; but I think they are allowed within
both the path and query components of generic URIs (without being
percent-encoded).

So just as the slashes in the URI above should not need to be %-encoded
(since they follow the ?, they are clearly within the query component),
neither should the parentheses need to be %-encoded -- but perhaps they
ought to be.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: (no subject)

[Slawomir Nowaczyk]

On Thu, 21 Dec 2006 11:43:55 -0700
Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote:

#> Werner LEMBERG wrote:
#> > [CVS 2006-10-28]
#> > 
#> > I've just seen the following link in an email:
#> > 
#> >   http://www.google.com/codesearch?hl=en&q=+pango_layout_(iter_)%3Fget_(lines%3F%7Crun)%5B%5E_%5D&start=50&sa=N
#> > 
#> > As you can probably can see immediately, thingatpt only colorizes (and
#> > uses) the string up to `..._layout_', stopping at the opening
#> > parenthesis.
#> > 
#> > Is this intentional or is this a bug?
#> 
#> It is intentional, as parentheses are explicitly excluded from URLs by
#> thing-at-point-url-path-regexp.  It could be a bug, as parentheses are
#> defined as reserved characters in URIs, which are only sometimes percent-
#> encoded, depending on the context; but I think they are allowed within
#> both the path and query components of generic URIs (without being
#> percent-encoded).
#> 
#> So just as the slashes in the URI above should not need to be %-encoded
#> (since they follow the ?, they are clearly within the query component),
#> neither should the parentheses need to be %-encoded -- but perhaps they
#> ought to be.

FWIW, I have found this behaviour to be pretty annoying: URLs like this
one are becoming rather common nowadays (at least in my experience) and
the fact that find-file-at-point does not handle them feels like a bug.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

All I want is a warm bed, and a kind word, and unlimited power.

(no subject)

[A Soare]

Here is the indentation rewriten, and taking into consideration all problems we have just talked about.

If there are some other new problems, please report.


Alin  Soare


Index: emacs/lisp/emacs-lisp/lisp-mode.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/emacs-lisp/lisp-mode.el,v
retrieving revision 1.199
diff -c -r1.199 lisp-mode.el
*** emacs/lisp/emacs-lisp/lisp-mode.el	17 Feb 2007 11:34:22 -0000	1.199
--- emacs/lisp/emacs-lisp/lisp-mode.el	21 Feb 2007 22:26:09 -0000
***************
*** 908,942 ****
        (let ((normal-indent (current-column)))
          (cond ((elt state 3)
                 ;; Inside a string, don't change indentation.
! 	       nil)
!               ((save-excursion
!                  ;; test whether current line begins with a constant
!                  (goto-char indent-point)
!                  (skip-chars-forward " \t")
!                  (looking-at ":"))
!                (let ((desired-indent
!                       (save-excursion
!                         (goto-char (1+ containing-sexp))
!                         (parse-partial-sexp (point) calculate-lisp-indent-last-sexp 0 t)
!                         (point)))
!                      (parse-sexp-ignore-comments t))
!                  ;; Align a constant symbol under the last constant symbol
!                  (goto-char calculate-lisp-indent-last-sexp)
!                  (while (> (point) desired-indent)
!                    (if (looking-at ":")
!                        (setq desired-indent (point))
!                      (backward-sexp 1))))
!                  (current-column))
                ((and (integerp lisp-indent-offset) containing-sexp)
                 ;; Indent by constant offset
                 (goto-char containing-sexp)
                 (+ (current-column) lisp-indent-offset))
                (desired-indent)
-               ((and (boundp 'lisp-indent-function)
-                     lisp-indent-function
-                     (not retry))
-                (or (funcall lisp-indent-function indent-point state)
-                    normal-indent))
                (t
                 normal-indent))))))
  
--- 908,955 ----
        (let ((normal-indent (current-column)))
          (cond ((elt state 3)
                 ;; Inside a string, don't change indentation.
!                nil)
                ((and (integerp lisp-indent-offset) containing-sexp)
                 ;; Indent by constant offset
                 (goto-char containing-sexp)
                 (+ (current-column) lisp-indent-offset))
+               ((save-excursion
+                  ;; the car must be defined on the same line as the inner parenthesis.
+                  ;; in this case calculate-lisp-indent-last-sexp is not nil.
+                  (and containing-sexp
+                       (goto-char (1+ containing-sexp))
+                       (skip-chars-forward " \t")
+                       (looking-at "\\sw\\|\\s_")))
+                (or
+                 ;; try to align the parameters of a known function
+                 (and (boundp 'lisp-indent-function)
+                      lisp-indent-function
+                      (not retry)
+                      (funcall lisp-indent-function indent-point state))
+                 ;; if not a standard function, try to align a constant-symbol
+                 ;; under the last preceding constant symbol, if there is such one
+                 ;; of the last 2 preceding symbols, in the previous uncommented
+                 ;; line
+                 (and (save-excursion
+                        (goto-char indent-point)
+                        (skip-chars-forward " \t")
+                        (looking-at ":"))
+                      (let ((parse-sexp-ignore-comments t)
+                            indent)
+                        (goto-char calculate-lisp-indent-last-sexp)
+                        (if (looking-at ":")
+                            (setq indent (current-column))
+                          (when (and (> calculate-lisp-indent-last-sexp containing-sexp)
+                                     (< (save-excursion (beginning-of-line) (point))
+                                        (prog2 (backward-sexp) (point))))
+                            (if (looking-at ":")
+                                (setq indent (current-column)))))
+                        indent))
+                 ;; another symbols or constants not preceded by a constant
+                 ;; as defined above.
+                 normal-indent))
+               ;; in this case calculate-lisp-indent-last-sexp is nil
                (desired-indent)
                (t
                 normal-indent))))))

(no subject)

[A Soare]

Why it is not chosen another system to change the font using the mouse?


In this moment (default) to change the font I press SHIFT+[left mouse button] , then choose a font.

In general I receive the message << mouse-set-font: Font not found [2 times] >>. That is because there is no rule to select the fonts from the default list.

Why it is not assigned to SHIFT + LEFT-MOUSE-BUTTON a menu to choose:
- font color
- background color
- a list of fonts (and to dresse this list detecting at least whether the fonts are instlled in the system).

What do you say about this proposal. If the assoc list (buffer-name, color) cannot be implemented, maybe this solution would work better?

Alin Soare.

(no subject)

[A Soare]

Can somebody recommend me a place (usenet/etcetera) where one speaks about problems of parsers/grammars? I found nothing to like so far.

Thanks in advance.

Re: (no subject)

[Stefan Monnier]

> Can somebody recommend me a place (usenet/etcetera) where one speaks about
> problems of parsers/grammars? I found nothing to like so far.

I have no idea what this has to do with Emacs, but comp.compilers seems like
the best place for it,


        Stefan

(no subject)

[Herbert Euler]

Hi Alan,

I found cc mode signals an error.  To reproduce:

1. $ emacs -Q
2. C-x C-f x.c  (an empty file should be able to reproduce)
3. Type `#'

Emacs signals an error: "End of buffer".  I have located the position
that the error is signaled, it is in c-neutralize-syntax-in-CPP.  In
the above use case, this function is invoked as follows:

(c-neutralize-syntax-in-CPP 1 2 0)
error--> End of buffer

Regards,
Guanpeng Xu
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

(no subject)

[Xavier Maillard]

Hi,

In the NEWS file (for 23.1), I can read this:

*** diff-add-change-log-entries-other-window iterates through the diff
buffer and tries to create ChangeLog entries for each change.
It is bound to `C-x 4 A'.

If, for some reason, I have many diffs in a file, I would like
this to wait for me typing a log entry (if any) before inserting
yet another entry.

Currently, if I am doing C-x 4 A with my emacs.el file, it ends
up with something like:

2008-03-23  Xavier Maillard  <xma@gnu.org>

	* emacs.el:

	* emacs.el (Man-mode-hook):

	* emacs.el (lambda):

	* emacs.el (kbd):

	* emacs.el (kbd):

	* emacs.el (dired-mode-hook):

	* emacs.el (dired-mode-hook):

	* emacs.el (mm-body-charset-encoding-alist):

	* emacs.el:

	* emacs.el (emacs-lisp-mode-hook):

	* emacs.el (vc-diff-other-window):

	* emacs.el:

	* emacs.el:

So there are many "duplicate" and useless entries. A better
approach would have to split the window with on one side, the
diff entry and on the other side, the changelog buffer. This way
I could review better my change and add an accurate and
informative change message.

---------------------------------
| Diff buffer | Change log buffer|
----------------------------------
| a diff     => description      |
----------------------------------

If changelog could not find an accurate function/variable name to
put into parenthesis, then fail back to the "default" emacs.el
entry.

WDYT ?

	Xavier
--
http://www.gnu.org
http://www.april.org
http://www.lolica.org

(no subject)

[Drew Adams]

I've gotten this message for a while now when trying to visit the Emacs-Lisp
repository at
http://bazaar.launchpad.net/%7Evcs-imports/emacs/trunk/files/head%3A/lisp/:

 "Internal Server Error"

Is that still the correct URL?

(no subject)

[Jambunathan K]

Emacs version.

,----
| GNU Emacs 23.1.91.1 (i386-mingw-nt5.1.2600) of 2010-01-03 on PRETEST
`----

I am using package.el 
http://github.com/davidswelt/aquamacs-emacs/raw/aquamacs24

(I hope it is as good as one in the trunk)

If I do M-x list-packages, I see that revert-buffer-function gets set to
package-menu-revert. The problem seems to be that it is having a
'global' effect so that a revert on an elisp buffer fails with

  "if: The current buffer is not a Package Menu"

Please take care of this if it is not already taken care of.

Jambunathan K.

(no subject)

[Richard Stallman]

bzr was slow on savannah due to the use of sftp.
Do people find bzr satisfactory now?


-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: (no subject)

[Werner LEMBERG]

> bzr was slow on savannah due to the use of sftp.
> Do people find bzr satisfactory now?

Well, I'm only doing `bzr pull', and it seems indeed to be more
responsive than previously.  However, the amount of data transferred
by bzr is still excessively large.  For example, updating from
rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull') used
more than 20MByte!  Looking at the amount of changes actually applied
to the repository, I estimate that git would need only approx. 200 to
300kByte ^[$(Q#|^[(B this is 70 to 100 times less...

It would be great if someone using an emacs git repository could
verify my estimation.

git compresses the data on the remote side before transferring it.
Does bzr omit that step?  Maybe I'm missing a bzr option?  Otherwise,
it looks like a severe flaw in the design.  Given that many users
(including me currently) use mobile internet connections which are
sometimes extremely slow due to weak signal strength, bandwidth *is*
an issue even today.


    Werner

Re: (no subject)

[Werner LEMBERG]

> Well, I'm only doing `bzr pull', and it seems indeed to be more
> responsive than previously.  However, the amount of data transferred
> by bzr is still excessively large.  For example, updating from
> rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull')
> used more than 20MByte!

I forgot to mention that I'm currently using bzr version 2.0.5 in case
this makes a difference w.r.t. the amount of transferred data.


    Werner

Re: (no subject)

[Richard Stallman]

    Well, I'm only doing `bzr pull', and it seems indeed to be more
    responsive than previously.  However, the amount of data transferred
    by bzr is still excessively large.  For example, updating from
    rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull') used
    more than 20MByte!  Looking at the amount of changes actually applied
    to the repository, I estimate that git would need only approx. 200 to
    300kByte   this is 70 to 100 times less...

    It would be great if someone using an emacs git repository could
    verify my estimation.

It would be interesting to set up parallel repositories, the latest
bzr and git, and update them at the same times.  Then it would be
possible to rigorously compare the amount of data transferred.

    git compresses the data on the remote side before transferring it.
    Does bzr omit that step?  Maybe I'm missing a bzr option?

It might be that the compression occurs in scp, and you're measuring
the amount of raw data rather than the amount actually transmitted.

But that's just a speculation.  It would be interesting to find out
for certain.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: (no subject)

[Glenn Morris]

Richard Stallman wrote:

> bzr was slow on savannah due to the use of sftp.
> Do people find bzr satisfactory now?

It is much improved and personally I find it satisfactory now, yes.

Re: [no subject]

[Chris Gregory]

Oops meant to reply to `Simplify internal_catch()'.

Anyway here is another patch with the same thing.
-- 
Chris Gregory

diff --git a/src/eval.c b/src/eval.c
index e50e26a..edb41b6 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1337,20 +1337,12 @@ internal_condition_case_1 (Lisp_Object (*bfun) (Lisp_Object), Lisp_Object arg,
 			   Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun (arg);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (arg);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case_1 but call BFUN with ARG1 and ARG2 as

(No subject)

[slb zetrov]

Hi,

tl;dr: By actually trying to implement the idea, I just realized that the idea
is flawed, and ‘exec-path-from-shell’ is necessary.

---

Thanks for pointing out ‘exec-path-from-shell’ can work on other situations and
‘parsenv’ to sync two versions of paths.

Problem is that users might have a lot of staffs inside ‘.bashrc’
‘.bash_profile’ and ‘.zshrc’, as a result, an embedded script just cannot be
simply imported to a shell session to figure the PATH.

The only way to properly get the PATH is to let the shell print the PATH and
read the results which is exactly what ‘exec-path-from-shell’ do.

---

Technically, Emacs.app and command-line Emacs "lives" in two different worlds.
Command-line Emacs lives in at a Unix environment. Emacs.app lives in macOS's
‘launchd‘ environment which is part of the desktop environment and it has a
specific set of env variables.

I guess the reason why some Linux desktop environments didn't provide right
PATH is they override the env variables or use a different technique to launch
applications. It might not be a bug but a feature.

---

Thanks!

Re: (No subject)

[Yuan Fu]

Can we implement something built-in? So paths works out-of-the-box and new users doesn’t need to google why Emacs can’t find xxx.

Yuan

Re: (No subject)

[Michael Albinus]

Yuan Fu <casouri@gmail.com> writes:

> Can we implement something built-in? So paths works out-of-the-box and
> new users doesn’t need to google why Emacs can’t find xxx.

Can we use a proper subject in messages? So users doen’t need to google
what is meant?

> Yuan

Best regards, Michael.