Re: Surely 'bzr update' shouldn't be this slow?

Re: Surely 'bzr update' shouldn't be this slow?

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

[snip]

>> 39 minutes for branching outside the shared repository corresponds to a
>> slow machine. It is 10 minutes on a GNU/Linux 2.4 GHz 64 bits
>> worksation-class machine. Bazaar is no speed daemon, but in this case it
>> has to process more than 200 MB of data (not merely copying it around.)
>
> I beg your pardon?  My machine is a 1.2 GHz Athlon.  That is NOT a slow
> machine by any measure, except that even faster machines are now
> common.

I think that that is the definition of "slow machine" :-)

> Why does Bazaar need to "process" this data?  It's essentially doing
> copying, with some accompanying administrivia.

It is not copying, and in that case it can't simply copy the data. A
shared repository contains data from all the branches it encloses. When
you branch from it, only the data that belongs to the branch you want
must be transferred.

I don't know why Bazaar does not copy the files under .bzr when you
clone a branch when it is on the same format that the target,
though. A good question for it ml.

> Is it doing heavy number crunching in Python, when it really needs a C
> module, or something like that?

The inner loops are written in C.

> I just did a 'bzr update' on my .../trunk.  It took 23 minutes,
> transferring nearly 200Mb to/from savannah in the process.  This compares
> with all our source files (.c, .h, .el) being ~64Mb.  Could it be that
> 'bzr update' just downloads the whole repository again?  Or has somebody
> else raised this issue on another thread that I've missed?

Yup, that was recently discussed here. It was an exceptional case (I
hope).

> There seems to be a substantial mismatch between the assumptions of the
> bzr project and the realities of the Emacs project.  My impression is
> that bzr is so slow as to be barely usable at the moment.

Apart from the 200MB download, do you think that bzr is too slow on your
daily Emacs work? Which operations are too slow for you?

Sometimes I work on a netbook, which maybe is comparable to your 1.2GHz
Athlon on CPU power, and some operations are slow indeed (>20 seconds
for the log of a file.) I raised this on the Bazaar ml, but most people
there think that Bazaar is fast enough and no extensive work is planned
for performance improvements.

-- 
Óscar

Re: Surely 'bzr update' shouldn't be this slow?

[Lennart Borgman]

On Thu, Jan 7, 2010 at 2:56 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Sometimes I work on a netbook, which maybe is comparable to your 1.2GHz
> Athlon on CPU power, and some operations are slow indeed (>20 seconds
> for the log of a file.) I raised this on the Bazaar ml, but most people
> there think that Bazaar is fast enough and no extensive work is planned
> for performance improvements.


If that is the case I really wonder what is wrong. We use to complain
that software from MS needs faster and faster machines.

It should of course not be like that for free software. It should not
pollute. It should not stop people who can't afford faster machines.

Re: Surely 'bzr update' shouldn't be this slow?

[Alan Mackenzie]

Hi, Óscar,

On Thu, Jan 07, 2010 at 02:56:02PM +0100, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> [snip]

> > I beg your pardon?  My machine is a 1.2 GHz Athlon.  That is NOT a
> > slow machine by any measure, except that even faster machines are now
> > common.

> I think that that is the definition of "slow machine" :-)

It's a machine which is more than fast enough for every aspect of Emacs
development other than running bzr.

> > Why does Bazaar need to "process" this data?  It's essentially doing
> > copying, with some accompanying administrivia.

> It is not copying, and in that case it can't simply copy the data. A
> shared repository contains data from all the branches it encloses. When
> you branch from it, only the data that belongs to the branch you want
> must be transferred.

It IS copying, conceptually - the content of the branched repository
contains a portion of the original branch, and nothing else.  So it has
to do a bit of filtering on the files' logs.  There are ~2000 files in
Emacs, and that copying/filtering took 39 minutes, about 2300 seconds.
It's taking over a second per file (at ~100% CPU usage).  A second is
about how long my PC takes to compile each C file in .../emacs/src.

> I don't know why Bazaar does not copy the files under .bzr when you
> clone a branch when it is on the same format that the target,
> though. A good question for it ml.

> > Is it doing heavy number crunching in Python, when it really needs a C
> > module, or something like that?

> The inner loops are written in C.

> > I just did a 'bzr update' on my .../trunk.  It took 23 minutes,
> > transferring nearly 200Mb to/from savannah in the process.  This
> > compares with all our source files (.c, .h, .el) being ~64Mb.  Could
> > it be that 'bzr update' just downloads the whole repository again?
> > Or has somebody else raised this issue on another thread that I've
> > missed?

> Yup, that was recently discussed here. It was an exceptional case (I
> hope).

There have been, perhaps, ~100 files updated since I first downloaded the
repository last Friday.  For each changed file, bzr transferred ~2Mb
between my PC and savannah.  Why?  This is ludicrous.

Hopefully it was an exceptional case, but I'd not changed my .../trunk at
all since downloading it, so anything exceptional was at the savannah
end.

I'm about to fix a bug which will involve ~100 bytes change to a C file
and ~200 bytes log message and ChangeLog addition.  How much will the bzr
commit operation transfer?  Hopefully, several kilobytes, no more.

Any chance you could point out that other thread to me?

> > There seems to be a substantial mismatch between the assumptions of
> > the bzr project and the realities of the Emacs project.  My
> > impression is that bzr is so slow as to be barely usable at the
> > moment.

> Apart from the 200MB download, do you think that bzr is too slow on your
> daily Emacs work? Which operations are too slow for you?

Yes, bzr is too slow for me.  My first checkout took, perhaps, an hour
and a half, but I can cope with that.  'bzr branch' (to a random place)
took 40 minutes.  'bzr branch' to the Right Place took a few seconds, and
this is the only bzr thing I've done so far which has been reasonable.
'bzr update' took 23 minutes, and this is the killer, the operation which
will make Emacs development such a frustrating, miserable experience; on
CVS, it would have been faster on my 33MHz 486 with 33kbaud modem.

> Sometimes I work on a netbook, which maybe is comparable to your 1.2GHz
> Athlon on CPU power, and some operations are slow indeed (>20 seconds
> for the log of a file.) I raised this on the Bazaar ml, but most people
> there think that Bazaar is fast enough and no extensive work is planned
> for performance improvements.

Their basic assumptions don't match the Emacs project, for whatever
reason.

> -- 
> Óscar

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Surely 'bzr update' shouldn't be this slow?

[Juanma Barranquero]

On Thu, Jan 7, 2010 at 15:52, Alan Mackenzie <acm@muc.de> wrote:

> Hopefully it was an exceptional case, but I'd not changed my .../trunk at
> all since downloading it, so anything exceptional was at the savannah
> end.

Yes.

> I'm about to fix a bug which will involve ~100 bytes change to a C file
> and ~200 bytes log message and ChangeLog addition.  How much will the bzr
> commit operation transfer?  Hopefully, several kilobytes, no more.

src/ChangeLog is already ~734 KiB.

> Yes, bzr is too slow for me.  My first checkout took, perhaps, an hour
> and a half, but I can cope with that.

OK.

> 'bzr branch' (to a random place)
> took 40 minutes.

Slow, but it's not a common operation (branching and not using a
shared repo, I mean).

> 'bzr update' took 23 minutes, and this is the killer, the operation which
> will make Emacs development such a frustrating, miserable experience; on
> CVS, it would have been faster on my 33MHz 486 with 33kbaud modem.

I just did "bzr up" and it took < 9s. You are generalizing from what
is already been described as an exceptional situation.

> Their basic assumptions don't match the Emacs project, for whatever
> reason.

Their basic assumption, which seems quite reasonable, is that people
will use the smart server, not sftp, for such a big project.

    Juanma

Re: Surely 'bzr update' shouldn't be this slow?

[Stefan Monnier]

> I beg your pardon?  My machine is a 1.2 GHz Athlon.  That is NOT a slow
> machine by any measure, except that even faster machines are now common.

Agreed.  I use a similar machine every once in a while (Thinkpad X30)
and it's perfectly useable.  I haven't used it extensively for Emacs
hacking of late, but I have done some "bzr updates" of Emacs there and
didn't find it unbearable.
Note that Bzr is pretty memory hungry as well, so that might make
a larger difference (I have 768MB in my smallest/oldest/slowest
machine).

> Why does Bazaar need to "process" this data?  It's essentially doing
> copying, with some accompanying administrivia.  Is it doing heavy number
> crunching in Python, when it really needs a C module, or something like
> that?

The technical reason is that the repository (whether shared or not)
contains all the info for the branch you're copying, plus some more
(for other branches that are, or have been stored there, or other branches
which you have referred to from there (e.g. in a diff, merge, ...)).
So Bzr basically does a GC along the way, only extracting the bits that
are necessary, which means it unpacks and then repacks pretty much the
whole thing.

> I just did a 'bzr update' on my .../trunk.  It took 23 minutes,
> transferring nearly 200Mb to/from savannah in the process.  This compares
> with all our source files (.c, .h, .el) being ~64Mb.  Could it be that
> 'bzr update' just downloads the whole repository again?

Yes.  As mentioned, if the remote repository could be accessed via
bzr+ssh rather than sftp, it would be a bit better.

> Or has somebody else raised this issue on another thread that
> I've missed?

Of course.


        Stefan

Re: Surely 'bzr update' shouldn't be this slow?

[Karl Fogel]

Juanma Barranquero <lekktu@gmail.com> writes:
>> Their basic assumptions don't match the Emacs project, for whatever
>> reason.
>
>Their basic assumption, which seems quite reasonable, is that people
>will use the smart server, not sftp, for such a big project.

Yes.  I *think* we are having a savannah problem here, not a bzr
problem.  People may find it faster to use the Launchpad.net mirror of
Emacs until Savannah gets bzr+ssh:// access (smart server).

-Karl

Re: Surely 'bzr update' shouldn't be this slow?

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

[snip]

>> > Why does Bazaar need to "process" this data?  It's essentially doing
>> > copying, with some accompanying administrivia.
>
>> It is not copying, and in that case it can't simply copy the data. A
>> shared repository contains data from all the branches it encloses. When
>> you branch from it, only the data that belongs to the branch you want
>> must be transferred.
>
> It IS copying, conceptually - the content of the branched repository
> contains a portion of the original branch, and nothing else.  So it has
> to do a bit of filtering on the files' logs.  There are ~2000 files in
> Emacs, and that copying/filtering took 39 minutes, about 2300 seconds.
> It's taking over a second per file (at ~100% CPU usage).  A second is
> about how long my PC takes to compile each C file in .../emacs/src.

Things are not so simple. Please note that bzr stores almost 100,000
revisions of Emacs development in a bit more that 200 MB. And each
revision is related to other revisions and that relations needs
traversing. It is obvious that the storage system is far from trivial,
so any complexity assumption based on concepts like files or chunks of
bytes are, very likely, wrong.

>> Yup, that was recently discussed here. It was an exceptional case (I
>> hope).
>
> There have been, perhaps, ~100 files updated since I first downloaded the
> repository last Friday.  For each changed file, bzr transferred ~2Mb
> between my PC and savannah.  Why?  This is ludicrous.
>
> Hopefully it was an exceptional case, but I'd not changed my .../trunk at
> all since downloading it, so anything exceptional was at the savannah
> end.
>
> I'm about to fix a bug which will involve ~100 bytes change to a C file
> and ~200 bytes log message and ChangeLog addition.  How much will the bzr
> commit operation transfer?  Hopefully, several kilobytes, no more.

When bzr communicates with upstream by the http or sftp protocols, it
needs to read or write lots of data because the needed information is
scattered all over the repository files.

In theory, installing the Bazaar smart server in Savannah should fix
those problems.

> Any chance you could point out that other thread to me?

The subthread starts here:

http://article.gmane.org/gmane.emacs.devel/119410

>> Apart from the 200MB download, do you think that bzr is too slow on your
>> daily Emacs work? Which operations are too slow for you?
>
> Yes, bzr is too slow for me.  My first checkout took, perhaps, an hour
> and a half, but I can cope with that.  'bzr branch' (to a random place)
> took 40 minutes.  'bzr branch' to the Right Place took a few seconds, and
> this is the only bzr thing I've done so far which has been reasonable.
> 'bzr update' took 23 minutes, and this is the killer, the operation which
> will make Emacs development such a frustrating, miserable experience; on
> CVS, it would have been faster on my 33MHz 486 with 33kbaud modem.

If the exceptionally long time that it took for certain update is the
biggest problem you found so far, there is no reason to worry. Because
it is not usual (except for that case, bzr needs less than 3 minutes for
updating on my netbook) and because if it becomes too frequent people
here will force the Savannah maintainers to install the smart server.

[snip]

-- 
Óscar

Re: Surely 'bzr update' shouldn't be this slow?

[Jan Djärv]

Lennart Borgman skrev:
> On Thu, Jan 7, 2010 at 2:56 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> 
>> Sometimes I work on a netbook, which maybe is comparable to your 1.2GHz
>> Athlon on CPU power, and some operations are slow indeed (>20 seconds
>> for the log of a file.) I raised this on the Bazaar ml, but most people
>> there think that Bazaar is fast enough and no extensive work is planned
>> for performance improvements.
> 
> 
> If that is the case I really wonder what is wrong. 

With bzr or the bzr developers? :-)
A bzr pull for the trunk takes 25-30 seconds when there is nothing to pull.
CVS took 4-5 seconds in the same case.  This is critical, as pulling from the 
trunk is done quite often.  Other operations are also slow (commit to the 
trunk for instance).  It is on the edge of usable.

Maybe it is bad to compare to git:

- Bzr is slow!
- Compared to what?
- Git.
- Well, git is superfast compared to anything, that means bzr is not really
   slow.

	Jan D.

Re: Surely 'bzr update' shouldn't be this slow?

[Glenn Morris]

Karl Fogel wrote:

> Yes.  I *think* we are having a savannah problem here, not a bzr
> problem.  People may find it faster to use the Launchpad.net mirror of
> Emacs until Savannah gets bzr+ssh:// access (smart server).

Have you tried asking rms to ask the Savannah admins to please make
improving support for GNU bzr a high priority?

Re: Surely 'bzr update' shouldn't be this slow?

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > OK.  Hopefully the other branches are referred to via a relative path
 > rather than an absolute one.

Paths are resolved in the usual way on GNU/Linux and other POSIX
systems (ie, the shell globs, evaluates environment variable
references, and interprets special path elements like ~), and bzr
checks for an absolute path and otherwise resolves relative to CWD.

Windows is more complex but that's not relevant to you, right?

 > On Thu, Jan 07, 2010 at 02:56:02PM +0100, Óscar Fuentes wrote:
 > > Alan Mackenzie <acm@muc.de> writes:

 > > > Why does Bazaar need to "process" this data?  It's essentially doing
 > > > copying, with some accompanying administrivia.
 > 
 > > It is not copying, [...].
 > 
 > It IS copying, conceptually

Alan, don't be contrary.  Óscar is just telling you the facts, and
AIUI *he* would not have chosen bzr if it were up to him.  He's just
trying to help you and others make the best use of the official VCS.

 > - the content of the branched repository contains a portion of the
 > original branch, and nothing else.  So it has to do a bit of
 > filtering on the files' logs.

No, it has to do a lot more than that.  What it is doing is
conceptually most like garbage collection.  The actual content of a
repository is stored as a set of compressed archives of file objects,
revision objects, and patches, plus some indicies.  (These archives
are called "packs.")  The "processing" goes through those objects,
throws out the ones not needed for the branch you request, and
reconstructs minimal packs and indicies for them.

 > There have been, perhaps, ~100 files updated since I first downloaded the
 > repository last Friday.  For each changed file, bzr transferred ~2Mb
 > between my PC and savannah.  Why?  This is ludicrous.
 > 
 > Hopefully it was an exceptional case, but I'd not changed my .../trunk at
 > all since downloading it, so anything exceptional was at the savannah
 > end.

Exactly!  At this date, the main cause of that particular slowness is
not bzr, it's savannah-hackers, which chose the absolute worst
available way to implement bzr support.  (They had their reasons,
security-related, which given Savannah's history as a target seem
reasonably important to me.)

 > I'm about to fix a bug which will involve ~100 bytes change to a C file
 > and ~200 bytes log message and ChangeLog addition.  How much will the bzr
 > commit operation transfer?  Hopefully, several kilobytes, no more.

As much as it needs to, but until the issue with Savannah gets
addressed, the minimum you should hope for is one pack and the index
file, typically a few MB.

You'll know when it gets fixed because there will be an announcement
that you should use "bzr+ssh" URLs, not "http" or "sftp".

 > Any chance you could point out that other thread to me?

The issue that bzr can be damned slow if you don't tune your workflow
has been pretty well constantly active since late 2007.  I guess it
just faded into the rest of the background noise for you. :-)

 > Yes, bzr is too slow for me.  My first checkout took, perhaps, an hour
 > and a half, but I can cope with that.

By "checkout" you mean "bzr branch http://savannah.../path/to/emacs/trunk",
right?  ("bzr checkout" does something completely different and should
not take more than a handful of seconds.  Please don't remark about the
randomness of bzr command names, this particular choice makes sense in
the appropriate context.)

The 90-minute initial branch is something we'll just have to deal
with (probably you personally won't actually need to do it again!)

BTW, "bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk emacs" just
now took 31:30 on my MacBook Pro (2.4GHz Intel Core2 Duo, 2GB RAM, Mac
OS X 10.5.8, Python 2.6.4) with bzr 2.0.1.  As others report, this is
CPU-bound, using 97% of one core.

 > 'bzr branch' (to a random place) took 40 minutes.

Are you sure the "random place" wasn't your CD-RW?  Just joking, but
that seems awfully long to me ("bzr branch emacs emacs.1" took 584
seconds, under 10 minutes for me, same box as above).  The only recent
reports I've seen on the Bazaar list in that league involve Windows
file systems or NFS mounts, so I wonder if there's something unusual
about your setup.  Are you on NFS?  If not, may I ask you to confirm
that your disk performance doesn't normally noticably suck, etc?

 > 'bzr branch' to the Right Place took a few seconds, and
 > this is the only bzr thing I've done so far which has been
 > reasonable.

It's also one of the things you're likely to do fairly frequently, and
minimizing its cost removes an important barrier to adopting best
practice.  So that's a good sign, even if so far it's rare in your
experience.

 > 'bzr update' took 23 minutes,

This is probably a one-off.  See the "BZR error!" thread, where Stefan
explains.

And the underlying problem is probably the Savannah misconfiguration,
which will eventually get fixed.

In any case, once you get the branch(es) you need locally, most
operations can be done locally, and with a little bit of care are all
reasonably fast.  Even while the Savannah issue remains open, once
Stefan et al finish tuning the arrangement of stuff in the main repo
(probably already done, actually), if you update your local branch
mirrors at least a couple of times a week you can probably hope to
limit each download to 10 or 20MB.

Or you can use the Launchpad mirror, as others have suggested.

 > Their basic assumptions don't match the Emacs project, for whatever
 > reason.

bzr was chosen for political reasons (it was the only GNU project
among the contenders), not because it was the best fit to existing
Emacs project practice.  The Emacs project therefore must adapt, and
that's part of the deal for Emacs developers.

It really shouldn't be that hard, but managing transitions in the GNU
Project is hard because the admins are spread so thinly.  Expect a few
more bumps, but really, there's no reason to expect that problems will
continue to be this frequent for more than a couple more weeks.

Re: Surely 'bzr update' shouldn't be this slow?

[Karl Fogel]

Glenn Morris <rgm@gnu.org> writes:
>Karl Fogel wrote:
>
>> Yes.  I *think* we are having a savannah problem here, not a bzr
>> problem.  People may find it faster to use the Launchpad.net mirror of
>> Emacs until Savannah gets bzr+ssh:// access (smart server).
>
>Have you tried asking rms to ask the Savannah admins to please make
>improving support for GNU bzr a high priority?

I've made similar requests of RMS before, and his response was:

  "Mail the Savannah admins list and CC me."

which seems like a reasonable course of action.

Someone here want to do it?

Re: Surely 'bzr update' shouldn't be this slow?

[Glenn Morris]

Karl Fogel wrote:

> Someone here want to do it?

I see Stefan (and you) already said pretty much all there is to say
back in November:

https://savannah.gnu.org/support/?107077#comment13

It tailed off into a discussion of commit emails, but that's resolved
now isn't it?

Re: Surely 'bzr update' shouldn't be this slow?

[grischka]

> > It IS copying, conceptually
>
> Alan, don't be contrary.  Óscar is just telling you the facts, and 
> AIUI *he* would not have chosen bzr if it were up to him.  He's just 
> trying to help you and others make the best use of the official VCS.

But Óscar wasn't telling any facts aside from that the issue is maybe
"complex" and "non-trivial".

> No, it has to do a lot more than that.  

Has to?  Why?

> What it is doing is
> conceptually most like garbage collection.  The actual content of a
> repository is stored as a set of compressed archives of file objects,
> revision objects, and patches, plus some indicies.  (These archives
> are called "packs.")  The "processing" goes through those objects,
> throws out the ones not needed for the branch you request, and
> reconstructs minimal packs and indicies for them.

So it's slow because it does lots of slow stuff.  Fine.

Obviously compression is slow, but who says it needs to de/recompress
the objects just to build a new index or to build a new pack with some
but not all of the objects?

Also with http:  You claim it's slow because it needs to download entire
packs.  But AFAIK http supports seeking into file offsets.  Or otherwise
you can store the top of the history near the beginning of the pack such
that you can stop downloading as soon as you have the missing updates.
Or otherwise you could have packs on the server only for commits older
than a year and anything more recent as single files.  It's not that
there weren't alternatives.

--- grischka

Re: Surely 'bzr update' shouldn't be this slow?

[Stephen J. Turnbull]

grischka writes:

 > > No, it has to do a lot more than that.  
 > 
 > Has to?  Why?

Because the data structures are designed that way.

But really, your question is either "why isn't bzr git?", in which
case the answer is "because it's not."

Or it's "why isn't Emacs using git?", in which case the answer is
"because Emacs is a means to the end of promoting free software, and
in RMS's judgment, Emacs using bzr is beneficial to that end."

 > Also with http: You claim it's slow because it needs to download
 > entire packs.

That is the fact of the matter.  Don't argue on emacs-devel with me
about bzr implementation.  Argue with the bzr devs on their lists, and
you'll find me in your corner.[1]  Probably Óscar, too.


Footnotes: 
[1]  Actually, not.  I'm sympathetic but unwilling to tilt at that
windmill.

Re: Surely 'bzr update' shouldn't be this slow?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Thu, 07 Jan 2010 15:48:00 -0500
> Cc: =?utf-8?Q?=C3=93scar?= Fuentes <ofv@wanadoo.es>,
> 	Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org,
> 	Alan Mackenzie <acm@muc.de>
> 
> Glenn Morris <rgm@gnu.org> writes:
> >Karl Fogel wrote:
> >
> >> Yes.  I *think* we are having a savannah problem here, not a bzr
> >> problem.  People may find it faster to use the Launchpad.net mirror of
> >> Emacs until Savannah gets bzr+ssh:// access (smart server).
> >
> >Have you tried asking rms to ask the Savannah admins to please make
> >improving support for GNU bzr a high priority?
> 
> I've made similar requests of RMS before, and his response was:
> 
>   "Mail the Savannah admins list and CC me."
> 
> which seems like a reasonable course of action.
> 
> Someone here want to do it?

Done.

Re: Surely 'bzr update' shouldn't be this slow?

[grischka]

Stephen J. Turnbull wrote:
> grischka writes:
> 
>  > > No, it has to do a lot more than that.  
>  > 
>  > Has to?  Why?
> 
> Because the data structures are designed that way.
 >
> But really, your question is either "why isn't bzr git?", in which
> case the answer is "because it's not."

We could ask them but I don't think that the bzr people would claim
that the shortcomings in question are a necessary consequence from
the top level design, that is from "being bzr" after all.

Frankly, that's somehow just as unlikely as that emacs cannot have
a better UI unless it wanted to be eclipse.

> Or it's "why isn't Emacs using git?", in which case the answer is
> "because Emacs is a means to the end of promoting free software, and
> in RMS's judgment, Emacs using bzr is beneficial to that end."

It is completely okay not to use git, however it is completely not okay
to ignore existing ideas and designs, the less if they are available by
the same principles that emacs is trying to promote.

--- grischka