From: Dave Love <d.love@dl.ac.uk>
Cc: emacs-devel@gnu.org
Subject: Re: please consider emacs-unicode for pervasive changes
Date: 24 Jul 2002 00:24:10 +0100 [thread overview]
Message-ID: <rzqy9c26nad.fsf@albion.dl.ac.uk> (raw)
In-Reply-To: tx165zcx4lw.fsf@raeburn.org
Ken Raeburn <raeburn@raeburn.org> writes:
> My string-macro changes, while fairly pervasive, are not as tough to
> make as they might appear. You might be surprised by what can be
> accomplished with a set of regular expressions that correspond to
> various styles of C expressions :-).
I'm not at all surprised, but that's not the point. You're one of the
people I expected actually to understand what such changes entail
practically when it comes to a merge, but it wasn't directed just at
your changes. Even things like straight global exchanges cause
problems in the end. Yes, you _can_ go through all the changes, try
to understand them, and try to duplicate more-or-less the work that
was done originally. But.
> Other changes I'm working on right now are to reduce the uses of SDATA
> that aren't read-only, to make it easier to identify places for
> inserting write-barrier code;
If you want to improve the GC (which would be very useful) what's the
reason for not trying the Boehm collector, as TODO suggests? The
ex-Harlequin Memory Pool System has been released since then, but as
far as I remember it doesn't currently have a suitable licence and I
don't know whether it would be worth considering practically, in
contrast to Boehm's.
> that's a slow and manual process, and
> while by no means as pervasive, still twice as painful if I have to do
> it on a branch as well.
I didn't say anyone else should start a branch, but I don't know
what's being done.
> is that pervasive enough that you want it brought over,
> or small enough to merge later?
Well, if it's slow and painful, I certainly wouldn't want to do it,
especially if I'm not convinced it's going in the right direction.
> It may be better just to say *everything*
> goes into the branch as well as the trunk.
I doubt that's worthwhile for changes that don't go anywhere near Mule
unless they're fixing things which make it difficult actually to run
the branch version (which is the reason I looked at trying to merge
changes which might help).
> I've assumed that when I start work on a Guile branch, I'd be
> responsible for dealing with merges in both directions and all the
> coordination that implies.
Well, I'll give up at that stage.
> It would be helpful for automatic tools or other useful techniques to
> be made available,
I don't know what tool support could help. I think it's basically a
question of management.
> but I wouldn't want to demand that everyone making
> big changes on the trunk also be required to know which branches are
> "active" and how their changes might have to be applied differently to
> those branches, and rewrite their changes to suit.
I disagree. ``CVS is not a substitute for management.''
> If you get around
> to merging in some big changes to the trunk to change the
> character-data handling in ways that better support the Unicode
> changes -- or perhaps the completed set of Unicode changes --
You mean there's some question about that happening, other than the
resources to do it which concerned me? That's not what I understood
when I was pressed to do the Mule work.
> would you want to be required to merge them onto a Guile branch as
> well?
I'm afraid I don't want to waste my time on things related to Guile.
If we're competing against that, I'm going to stop.
next prev parent reply other threads:[~2002-07-23 23:24 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-18 16:02 please consider emacs-unicode for pervasive changes Dave Love
2002-07-18 16:44 ` Stefan Monnier
2002-07-19 16:53 ` Richard Stallman
2002-07-19 17:44 ` Stefan Monnier
2002-07-20 0:35 ` Richard Stallman
2002-07-20 22:07 ` Richard Stallman
2002-07-21 5:10 ` Eli Zaretskii
2002-08-09 7:56 ` Stefan Monnier
2002-08-10 17:16 ` Richard Stallman
2002-08-12 17:25 ` Luc Teirlinck
2002-08-13 22:47 ` Richard Stallman
2002-08-12 17:53 ` Tak Ota
2002-08-12 18:44 ` Stefan Monnier
2002-08-13 22:46 ` Richard Stallman
[not found] ` <20020813.175221.107709446.Takaaki.Ota@am.sony.com>
2002-08-15 19:54 ` Richard Stallman
2002-08-15 20:47 ` Tak Ota
2002-08-16 14:31 ` FSF Copyright Assignment Clerk
2002-08-16 17:59 ` Richard Stallman
2002-08-16 18:32 ` Tak Ota
2002-08-12 19:58 ` Simon Josefsson
2002-08-13 22:46 ` Richard Stallman
2002-08-14 11:52 ` Simon Josefsson
2002-08-14 12:32 ` Simon Josefsson
2002-08-14 23:14 ` Richard Stallman
2002-08-31 17:12 ` Dave Love
2002-09-01 0:10 ` Alex Schroeder
2002-08-13 16:34 ` plan for code freeze Stefan Monnier
2002-08-14 5:15 ` Richard Stallman
2002-08-14 14:39 ` Stefan Monnier
2002-08-17 4:19 ` Karl Eichwalder
2002-08-17 20:08 ` Richard Stallman
[not found] ` <m2u1lsa3sx.fsf@primate.xs4all.nl>
2002-08-18 19:18 ` Karl Eichwalder
2002-08-19 5:17 ` Miles Bader
2002-08-19 20:46 ` Richard Stallman
2002-08-19 21:55 ` Alex Schroeder
2002-08-21 0:11 ` Richard Stallman
2002-08-26 8:37 ` Per Abrahamsen
2002-08-23 15:03 ` William M. Perry
2002-08-25 5:26 ` Richard Stallman
2002-08-28 15:47 ` William M. Perry
2002-08-29 17:50 ` Richard Stallman
2002-08-29 17:53 ` Stefan Monnier
2002-08-29 19:02 ` Sam Steingold
2002-08-29 20:15 ` Stefan Monnier
2002-08-29 20:25 ` Sam Steingold
2002-08-29 20:36 ` Alan Shutko
2002-08-29 20:38 ` Stefan Monnier
2002-09-04 14:40 ` William M. Perry
2002-07-18 18:39 ` please consider emacs-unicode for pervasive changes Ken Raeburn
2002-07-23 23:24 ` Dave Love [this message]
2002-07-24 15:54 ` Richard Stallman
2002-07-25 3:30 ` Ken Raeburn
2002-08-09 7:54 ` Stefan Monnier
2002-08-10 17:16 ` Richard Stallman
2002-08-12 20:08 ` Ken Raeburn
2002-08-13 0:30 ` Kenichi Handa
2002-08-31 17:07 ` Dave Love
2002-09-03 6:15 ` Kenichi Handa
2002-09-04 14:20 ` Richard Stallman
2002-09-05 5:48 ` Kenichi Handa
2002-09-05 14:48 ` Eli Zaretskii
2002-09-06 4:01 ` Richard Stallman
2002-09-06 4:29 ` Kenichi Handa
2002-09-07 3:17 ` Richard Stallman
2002-09-09 22:17 ` Dave Love
2002-09-19 4:59 ` Eli Zaretskii
2002-09-25 22:49 ` Dave Love
2002-09-19 4:57 ` Eli Zaretskii
2002-09-20 3:43 ` Richard Stallman
2002-09-25 22:39 ` Dave Love
2002-09-06 4:46 ` Kenichi Handa
2002-09-05 22:41 ` Dave Love
2002-09-06 4:01 ` Richard Stallman
2002-09-04 23:30 ` Dave Love
2002-09-05 18:03 ` Richard Stallman
2002-09-05 20:42 ` Kai Großjohann
2002-09-05 23:59 ` Dave Love
2002-09-06 20:02 ` Richard Stallman
2002-09-07 23:48 ` Dave Love
2002-09-09 0:22 ` Richard Stallman
2002-09-09 0:57 ` Kenichi Handa
2002-09-09 23:33 ` Richard Stallman
2002-09-12 23:01 ` Dave Love
2002-09-13 19:33 ` Richard Stallman
2002-09-25 22:49 ` Dave Love
2002-09-27 17:42 ` Richard Stallman
2002-10-04 22:22 ` Dave Love
2002-10-06 16:14 ` Richard Stallman
2002-10-04 6:08 ` Kenichi Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=rzqy9c26nad.fsf@albion.dl.ac.uk \
--to=d.love@dl.ac.uk \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).