please consider emacs-unicode for pervasive changes

please consider emacs-unicode for pervasive changes

[Dave Love]

There have been various pervasive changes recently which will cause
grief merging the unicode branch eventually.  Could people doing this
for Mule-related files (including display) please be prepared to
modify the `emacs-unicode' branch too.  I don't know if handa would
like to be consulted beforehand, but I assume he'd appreciate having
it done now, with less problems later on.  (I guess the same would go
for other active branches, if there are any.)

Thanks.

[In case this doesn't sound reasonable, I expect others with as much
experience would agree.  Even trivial global renaming of things can
cause trouble.  Some of the changes that have been made don't look
trivial and would probably need their authors consulting anyhow if
someone else did the work.]

Re: please consider emacs-unicode for pervasive changes

[Stefan Monnier]

> There have been various pervasive changes recently which will cause
> grief merging the unicode branch eventually.  Could people doing this
> for Mule-related files (including display) please be prepared to
> modify the `emacs-unicode' branch too.  I don't know if handa would
> like to be consulted beforehand, but I assume he'd appreciate having
> it done now, with less problems later on.  (I guess the same would go
> for other active branches, if there are any.)

Maintaining several branches like that takes a lot
of effort, especially if active development is done on both
the trunk and emacs-unicode.

I obviously agree that merging changes from the trunk to emacs-unicode
should be done regularly, ideally by the person that did the change.

But I think we should also think about trying to reduce the number of
active branches.  How about the following:

- feature freeze on the trunk.
- create a branch for Emacs_21_4 where we can commit bug-fixes during
  the subsequent debugging+pretest+maintenance period.
- merge the emacs-unicode changes onto the trunk.

IIUC 21.3 will be out soon, and I think that 21.4's feature freeze should
follow very closely.  How mature is emacs-unicode ?


	Stefan

Re: please consider emacs-unicode for pervasive changes

[Ken Raeburn]

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

Dave Love <d.love@dl.ac.uk> writes:
> There have been various pervasive changes recently which will cause
> grief merging the unicode branch eventually.  Could people doing this
> for Mule-related files (including display) please be prepared to
> modify the `emacs-unicode' branch too.  I don't know if handa would
> like to be consulted beforehand, but I assume he'd appreciate having
> it done now, with less problems later on.

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've attached the Lisp code I
use; scmcvt-string and scmcvt-string-2 are the interesting bits.
There's always a little cleanup needed afterwards (a few cases that
aren't matched; restoring lisp.h macros that become defined to expand
to themselves because the definition matched the pattern) but it does
95% of the work.

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; 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.  Though aside from a few cases where SDATA is
used to write to a string, it'll mostly consist of adding "const" to
char pointers in places, and eventually adding a const cast to the
SDATA macro; is that pervasive enough that you want it brought over,
or small enough to merge later?

As soon as any big changes that need to be applied to the branch
depend on any small changes that weren't applied to the branch, we get
a maintenance hassle, with someone who didn't write those small
changes trying to bring them and anything they might depend on over to
the branch.  (The dependencies may be obvious, but if they're of the
sort "simplify macro X because all code relying on side-effect Y has
been changed over the course of a couple months to not rely on it",
they may be hard to find.)  It may be better just to say *everything*
goes into the branch as well as the trunk.

Then again, is anything else likely to be as problematic as taking
string handling in two different directions on different branches?

>   (I guess the same would go
> for other active branches, if there are any.)

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.  ("We", not "I"; I really hope to get some
help in this work.)  That's also why I am taking the approach I am --
essentially, I *am* merging changes to the trunk that I made in my
divergent source tree started long ago.

It would be helpful for automatic tools or other useful techniques to
be made available, 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.  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 -- would
you want to be required to merge them onto a Guile branch as well?

I realize the Unicode work, which we've been talking about as the "big
thing" for Emacs 22, is probably in a special category, and maybe it
makes sense to ask for parallel development in this case and not
others.

Ken


[-- Attachment #2: c expr rewrite code --]
[-- Type: text/plain, Size: 4810 bytes --]

(defun quiet-replace-regexp (regexp to-string)
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward regexp nil t)
      (replace-match to-string nil nil))))

(defun qrep-car-cdr (base)
  (quiet-replace-regexp (concat "XCONS ?(\\(" base "\\))->car") "XCAR (\\1)")
  (quiet-replace-regexp (concat "XCONS ?(\\(" base "\\))->cdr") "XCDR (\\1)")
  )

(defun qrep-float (base)
  (quiet-replace-regexp (concat "XFLOAT ?(\\(" base "\\))->data")
			"XFLOAT_DATA (\\1)")
  )

;; All of these must accept only paren-balanced C expressions.  No
;; wildcard matching here...
(defvar c-exprs nil "")
(setq c-exprs
      '(
	;; no leading whitespace!
	"[-*a-z_A-Z0-9.][-*a-z_A-Z0-9.]*"
	"[-*a-z_A-Z0-9.][-*a-z_A-Z0-9.]*-> *[*a-z_A-Z0-9.]+"
	;; a(b), zero or more trailing ->s
	"[a-z_A-Z0-9][a-z_A-Z0-9 ]*([-a-z_A-Z0-9> .]*)[-a-z_>]*"
	;; a(b(c)), trailing ->s at end and after b(c)
	"[a-z_A-Z0-9][a-z_A-Z0-9 ]*([a-z_A-Z0-9 ]+([a-z_A-Z0-9 ]*)[-a-z_>]*)[-a-z_>]*"
	;; a(b(c(d)))
	"[a-z_A-Z0-9][a-z_A-Z0-9 ]*([a-z_A-Z0-9 ]+([a-z_A-Z0-9 ]+([a-z_A-Z0-9 ]*)))"
	;; something subscripted - a[b]
	"[a-z_A-Z0-9][a-z_A-Z0-9 ]*\\[[a-z_A-Z0-9 ]+\\]"
	;; a(b[c])
	"[a-z_A-Z0-9][a-z_A-Z0-9 ]*([a-z_A-Z0-9 ]+\\[[a-z_A-Z0-9 ]+\\])"
	;; GET_TRANSLATION_TABLE macro defn - subscript in the arg
	;; a(b)->c[(d)]
	"[a-z_A-Z0-9][a-z_A-Z0-9 ]*([a-z_A-Z0-9 ]*)->[a-z_A-Z0-9]+\\[([a-z_A-Z0-9 ]+)\\]"
	;; xfaces uses a->b[c]
	"[a-z_A-Z0-9][a-z_A-Z0-9 ]*->[a-z_A-Z0-9]+\\[[a-z_A-Z0-9 ]+\\]"
	;; (x)
	"([-*a-z_A-Z0-9.][-*a-z_A-Z0-9.]*)"
	;; f(a->b[c])
	"[a-z_A-Z0-9][a-z_A-Z0-9 ]*([a-z_A-Z0-9 ]*->[a-z_A-Z0-9]+\\[[a-z_A-Z0-9 ]+\\])"
	;; ( ! f(a) \n ? b \n : c ), where a b c can contain ->
	"(!?[a-z_A-Z0-9][a-z_A-Z0-9 ]*([->a-z_A-Z0-9 ]*)[ \n\t]*\\? [->a-z_A-Z0-9 ]*[ \n\t]*: [->a-z_A-Z0-9 ]*)"
	;; pure numbers (as extra macro args, of course, not variables)
	"-?[0-9][0-9]*"
	))
(defvar c-all-exprs nil "")
(setq c-all-exprs
      (apply 'concat
	     (car c-exprs)
	     (mapcar (lambda (x) (concat "\\|" x)) (cdr c-exprs))))

(defun scmcvt-car-and-cdr ()
  (interactive)
  (mapcar 'qrep-car-cdr c-exprs)

  ;; be careful -- this can change the definition of XFLOAT_DATA itself
  (qrep-float "[-*a-z_A-Z0-9>]+")
  (qrep-float "[-*a-z_A-Z0-9>]+\\[[a-z]+\\]")
  )

(defun map-over-files (fun)
  (let ((names (directory-files "." nil "\\.[ch]$")))
    (mapcar fun names)))

(defun get-fn-value (f)
  (if (symbolp f)
      (get-fn-value (symbol-function f))
    f))

(defun apply-and-save-wrapper (fun)
  (let ((x (get-fn-value fun)))
    (eval `(lambda (fn) (apply-and-save ,x fn)))))

(defun apply-and-save (fun fn)
  (if (file-regular-p fn)
      (progn
	(message "Working on %s..." fn)
	(find-file fn)
	(goto-char (point-min))
	(funcall fun)
	(if (buffer-modified-p nil)
	    (save-buffer))
	(kill-buffer nil)
	(message "Working on %s...done" fn)
	)))

(defun map-edit-files (fun)
  (let ((enable-local-variables nil))
    (map-over-files (apply-and-save-wrapper fun)))
  nil
  )

(defun qrep-string (base)
  (quiet-replace-regexp (concat "SMBP ?(\\(" base "\\))")
			"STRING_MULTIBYTE (\\1)")
  ;; do size_byte before size, since the latter is a substring of the
  ;; former and would match
  (quiet-replace-regexp (concat "XSTRING ?(\\(" base "\\))->size_byte")
			"STRING_SIZE_BYTE (\\1)")
  (quiet-replace-regexp (concat "XSTRING ?(\\(" base "\\))->size")
			"SCHARS (\\1)")
  (quiet-replace-regexp (concat "STRING_SIZE_BYTE ?(\\(" base "\\))")
			"XSTRING (\\1)->size_byte")
  ;; other fields
  (quiet-replace-regexp (concat "XSTRING ?(\\(" base "\\))->intervals")
			"STRING_INTERVALS (\\1)")
  (quiet-replace-regexp (concat "XSTRING ?(\\(" base "\\))-> *data")
			"SDATA (\\1)")
  (quiet-replace-regexp (concat "STRING_BYTES (XSTRING ?(\\(" base "\\)))")
			"SBYTES (\\1)")
  (quiet-replace-regexp (concat "XSETSTRING (\\(" base "\\),[\n\t ]*XSTRING (\\(" base "\\)))")
			"\\1 = \\2")
  (quiet-replace-regexp (concat "SET_STRING_BYTES (XSTRING ?(\\(" base "\\)), -1)")
			"STRING_SET_UNIBYTE (\\1)")
  (quiet-replace-regexp (concat "SDATA (\\(" base "\\)) *\\[\\(" base "\\)\\]")
			"SREF (\\1, \\2)")
  )

(defun qrep-string-2 (base)
  (quiet-replace-regexp (concat "SET_STRING_BYTES (XSTRING ?(\\(" base "\\)), *\\((" base ")\\))")
			"STRING_SET_BYTES (\\1, \\2)")
  (quiet-replace-regexp (concat "STRING_SET_BYTES (\\(" base "\\), -1)")
			"STRING_SET_UNIBYTE (\\1)")

  )

(defun scmcvt-string ()
  (interactive)
  (mapcar 'qrep-string c-exprs))

(defun scmcvt-string-2 ()
  (interactive)
  (mapcar 'qrep-string-2 c-exprs))

(defun scmcvt-all ()
  (scmcvt-car-and-cdr)
  (scmcvt-string)
  )

(if nil
    (progn

      ;; run these forms one at a time
      (map-edit-files 'scmcvt-car-and-cdr)

      (map-edit-files 'scmcvt-string)
      (map-edit-files 'scmcvt-string-2)
      (map-edit-files 'scmcvt-all)

))

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    - feature freeze on the trunk.
    - create a branch for Emacs_21_4 where we can commit bug-fixes during
      the subsequent debugging+pretest+maintenance period.
    - merge the emacs-unicode changes onto the trunk.

This is unacceptable unless the emacs-unicode changes are almost ready
for real installation.  If they are almost ready, then rather than
doing this, we may want to merge them into the trunk now and include
them in the next release.  Otherwise they must remain a branch.
Basically, it's either in or out.

Re: please consider emacs-unicode for pervasive changes

[Stefan Monnier]

>     - feature freeze on the trunk.
>     - create a branch for Emacs_21_4 where we can commit bug-fixes during
>       the subsequent debugging+pretest+maintenance period.
>     - merge the emacs-unicode changes onto the trunk.
> 
> This is unacceptable unless the emacs-unicode changes are almost ready
> for real installation.

I'm not sure I understand why.  The three steps don't need to all take
place at the very same time.  Furthermore, during the debugging+pretest
phase of Emacs-21.4 I expect that we should concentrate on debugging
rather than new features so the trunk should most mostly quiet,
which leaves more time for merging emacs-unicode.  Finally, I agree
that the changes should be "ready for installation", but that doesn't
mean "100% completed".  It just means that the main parts are done
and working modulo bugs.
The trunk is where the main activity should take place, so as soon as
emacs-unicode is stable enough for other people (even if uninterested
in unicode) to hack on, it should be merged.

>  If they are almost ready, then rather than
> doing this, we may want to merge them into the trunk now and include
> them in the next release.

I hope that the work can be split enough that there's a "long time"
between "ready for use" and "feature complete ready for release".
Also I'd rather not delay the release of 21.4.

> Basically, it's either in or out.

Nice truism, Richard ;-)


	Stefan

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    > This is unacceptable unless the emacs-unicode changes are almost ready
    > for real installation.

    I'm not sure I understand why.

Because we don't want to force all new features after today into the
emacs-unicode version if that version is not ready for release just as
soon as everything else we are going to add.

    The trunk is where the main activity should take place, so as soon as
    emacs-unicode is stable enough for other people (even if uninterested
    in unicode) to hack on, it should be merged.

As soon as it basically does the same jobs that the older code does,
and works as well as things in the trunk normally should work, 
it can be installed in the trunk.

I do not know how close it is to that point now.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    >     - feature freeze on the trunk.
    >     - create a branch for Emacs_21_4 where we can commit bug-fixes during
    >       the subsequent debugging+pretest+maintenance period.
    >     - merge the emacs-unicode changes onto the trunk.
    > 
    > This is unacceptable unless the emacs-unicode changes are almost ready
    > for real installation.

    I'm not sure I understand why.  The three steps don't need to all take
    place at the very same time.

If all you're proposing for right now is a feature freeze on the
trunk, the question is, do we want one now?  I don't think so.
I would like to get the GDB enhancements in.

Re: please consider emacs-unicode for pervasive changes

[Eli Zaretskii]

On Sat, 20 Jul 2002, Richard Stallman wrote:

> If all you're proposing for right now is a feature freeze on the
> trunk, the question is, do we want one now?  I don't think so.
> I would like to get the GDB enhancements in.

If a feature freeze is being considered, I'd suggest that every developer 
who works on something tell what that is, so that the decision whether or 
not to freeze could be based on more data.

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

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.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    > 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?

There is no question about that.  We will switch to unicode as soon
as the unicode support is fully working.

Please do not draw such big conclusions from side issues in words
from people who are not in charge.  If you want to know what our
plans are for Emacs development, please ask me, not anyone else.

    > 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.

There is no need for you to concern yourself with the Guile changes.
That is a possibility for the future; it won't have any impact on your
work on the unicode branch.

Re: please consider emacs-unicode for pervasive changes

[Ken Raeburn]

I had written up a reply earlier, and Emacs crashed in the display
code, though I haven't figured out why yet.  I wonder if it's a
sign...


Dave Love <d.love@dl.ac.uk> writes:
> 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.

Yes, "but".  It's tedious work, whoever does it, and whichever
direction it's going, and unless you've got someone who understands
both sets of changes, merging them can be a problem.  I haven't yet
had a positive experience with extended development using branches.

Deciding who merges what and when is what's at issue.  Are we talking
about general policy for Emacs work, or special treatment for the
Unicode branch?  I haven't heard much about either.

Fortunately, in my case, most of my string-macro changes don't
actually require much understanding of the surrounding context; it's a
simple transformation on C source code.  So I probably could merge my
bigger recent changes into your branch without needing to understand
the overall gist of your changes.

> 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

This came up on emacs-hackers a few months ago.  Improving the GC
would be useful, but only if we decide we're not switching to Guile
any time soon.  If that happens, I'd probably be more interested in
working on fixing Guile, but I could probably be convinced to help
with more write-barrier stuff if someone else wanted to do the Emacs
GC work.

> 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).

Can you describe "anywhere near Mule" a little more carefully?  Or
should I just run some cvs diffs on your branch to see if you've
touched the code I want to touch?

>> 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.

I'm assuming it because I've heard nothing else about "how we manage
development branches in Emacs".  Perhaps RMS simply doesn't want a
blanket policy right now.  Or maybe it hasn't been advertised well
enough in places where I've been looking.

>> 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.

I was thinking of things like the lisp code I used to make some
changes.  Or easy manual techniques for finding where certain changes
need to be made in the code.  Perhaps not applicable to most cases,
but when they are, sometimes they're for pervasive changes like mine.

>> 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.''

So you think I need to understand your Unicode work, and Miles's
lexbind work (looks like he's added another field to Lisp_Symbol), and
whatever else might be "active" now, and merge any widespread changes
I make that might affect them onto N branches?  Or do you just want
special treatment for the Unicode branch?

Can we write up somewhere what's being done on branches that
developers need to be aware of, and when a developer should apply
changes to which branches?  Otherwise, how is someone who joins this
list next week going to know?

>> 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.

Poorly phrased, sorry.  I should have said, "If, when you do the
merging, there's a Guile branch..."

I don't know *how* you're going about the Unicode work, particularly
handling merges.  Apparently it involves getting other people to help
with some of the merging.

>> 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.

If you think Guile is a waste of time, I'm sorry to hear it.  I don't
plan to stop any time soon.  But I don't think that means there's any
sort of "competition" here.

And Guile wasn't the point of my question, anyways.  Assume for the
sake of argument that when you're ready to merge the Unicode changes,
there's some big, important, non-Guile-based branch that's also been
started by someone other than me, and it'll be affected by the Unicode
changes.  Do you think you should to be asked to merge the Unicode
changes onto that branch?

Ken

Re: please consider emacs-unicode for pervasive changes

[Stefan Monnier]

> 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.

From the very limited experiment done in the XEmacs camp it seems
that the result is slow.  It's not quite clear why and how much work
would be necessary to tune it to something acceptable, but I maybe
it's got something to do with "very fast cons-cell allocation".

> > 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.

I think Dave is right in trying to make people aware of the problem
and that the merging should not be blindly always imposed on the same
side.  There should be enough cooperation that the merge is done by
the people who can do it most easily (and thus reliably) and that
depends on the actual change.

In the case of a rename (or other changes like the ones done for Guile),
the one making the change is better prepared to apply it to other branches
because understanding the code that's changed is not really
necessary.

Maybe Ken should base its work on the emacs-unicode branch so it
doesn't need to worry about another branch.


	Stefan

Re: please consider emacs-unicode for pervasive changes

[Stefan Monnier]

>     >     - feature freeze on the trunk.
>     >     - create a branch for Emacs_21_4 where we can commit bug-fixes during
>     >       the subsequent debugging+pretest+maintenance period.
>     >     - merge the emacs-unicode changes onto the trunk.
>     > 
>     > This is unacceptable unless the emacs-unicode changes are almost ready
>     > for real installation.
> 
>     I'm not sure I understand why.  The three steps don't need to all take
>     place at the very same time.
> 
> If all you're proposing for right now is a feature freeze on the
> trunk, the question is, do we want one now?  I don't think so.
> I would like to get the GDB enhancements in.

I don't suggest a feature freeze right here and now, but I think it's
time to think about it.  A list of "things still to be included" would
be a first start, so that when those things are all included
we can freeze.


	Stefan

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    Maybe Ken should base its work on the emacs-unicode branch so it
    doesn't need to worry about another branch.

That sounds like a good idea to me, if the unicode branch
is working well enough to make it feasible.  The unicode branch
will be ready fairly soon, long before Ken's branch is anywhere
near ready.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    I don't suggest a feature freeze right here and now, but I think it's
    time to think about it.  A list of "things still to be included" would
    be a first start, so that when those things are all included
    we can freeze.

Could people who are working on things that might be desirale to
include soon please speak up and identify those changes?

Re: please consider emacs-unicode for pervasive changes

[Luc Teirlinck]

Richard Stallman wrote:

   Could people who are working on things that might be desirale to
   include soon please speak up and identify those changes?

I am working on a unified version of mailalias.el and mailabbrev.el,
as well as on a file allowing to write interactively defined mail
aliases automatically into .mailrc and a file defining a major mode to
edit .mailrc directly.  I hope to be able to submit all of this within
a month, although I can give no hard guarantee about that time-frame.

I do not know what the proposed feature freeze entails, so I do not
know how it would affect my proposed changes and additions.

My changes are partly new features, partly a unification of existing
features and partly bug fixes.  They form a unity however, since the
various aspects depend on each other.

Sincerely,

Luc.

Re: please consider emacs-unicode for pervasive changes

[Tak Ota]

Sat, 10 Aug 2002 11:16:58 -0600 (MDT): Richard Stallman <rms@gnu.org> wrote:

> Could people who are working on things that might be desirale to
> include soon please speak up and identify those changes?

Will you consider table.el as a part of emacs feature at some point?

-Tak

Re: please consider emacs-unicode for pervasive changes

[Stefan Monnier]

> > Could people who are working on things that might be desirale to
> > include soon please speak up and identify those changes?
> Will you consider table.el as a part of emacs feature at some point?

Yes, please install it ASAP.  Although independent packages
can be easily added with no risk of breaking anything (so we
can accept them more easily after a "feature freeze") it's
better to have them installed before the feature freeze.


	Stefan

Re: please consider emacs-unicode for pervasive changes

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     I don't suggest a feature freeze right here and now, but I think it's
>     time to think about it.  A list of "things still to be included" would
>     be a first start, so that when those things are all included
>     we can freeze.
>
> Could people who are working on things that might be desirale to
> include soon please speak up and identify those changes?

I didn't follow this thread closely so I'm not sure if it applies to
21.3 or 21.4, but I've been trying to track down papers for a SASL
package so it eventually could be considered for inclusion in Emacs.

The package allows better network authentication for IMAP (in Gnus),
SMTP (e.g., smtpmail.el) and third party packages (my Sieve package
for instance).

It should obviously not go into 21.3, but if 21.4 is freezed soonish I
think it would be nice to include it.

Should I send a patch?  I have not verified all paperwork yet though.

Re: please consider emacs-unicode for pervasive changes

[Ken Raeburn]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> I think Dave is right in trying to make people aware of the problem
> and that the merging should not be blindly always imposed on the same
> side.  There should be enough cooperation that the merge is done by
> the people who can do it most easily (and thus reliably) and that
> depends on the actual change.

Agreed.

> In the case of a rename (or other changes like the ones done for Guile),
> the one making the change is better prepared to apply it to other branches
> because understanding the code that's changed is not really
> necessary.

True, but I'm concerned about stepping on toes in "their" development
branch.  If the people "in charge of" the unicode branch say yes, they
want all these changes, okay, I can do it.

But they haven't said that.  Dave asked for the unicode branch to be
considered for pervasive changes, but said, "I don't know if handa
would like to be consulted beforehand".  I haven't seen any email from
handa on this, so I won't take this as a go-ahead yet, either in
general or for the specific changes I've made recently.  I sent both
of them email a couple weeks ago showing the string-macro changes as
they would apply to the unicode branch (as it was at that time),
asking if they wanted them applied, but I'm still waiting to hear
back.

> Maybe Ken should base its work on the emacs-unicode branch so it
> doesn't need to worry about another branch.

Only on the unicode branch, which will complicate the merging process
for whoever does it, especially since most of the automated changes
are done for now, or on both?

I'd gotten the impression from email a while ago that it wasn't ready
for daily use, but maybe that's changed.  I don't want to be
developing solely on a branch I can't effectively test.

Ken

Re: please consider emacs-unicode for pervasive changes

[Kenichi Handa]

In article <tx17kiv6dr9.fsf@raeburn.org>, Ken Raeburn <raeburn@raeburn.org> writes:
> True, but I'm concerned about stepping on toes in "their" development
> branch.  If the people "in charge of" the unicode branch say yes, they
> want all these changes, okay, I can do it.

> But they haven't said that.  Dave asked for the unicode branch to be
> considered for pervasive changes, but said, "I don't know if handa
> would like to be consulted beforehand".  I haven't seen any email from
> handa on this, so I won't take this as a go-ahead yet, either in
> general or for the specific changes I've made recently. I sent both
> of them email a couple weeks ago showing the string-macro changes as
> they would apply to the unicode branch (as it was at that time),
> asking if they wanted them applied, but I'm still waiting to hear
> back.

I'm very sorry for not reacting on this matter more quickly.
I've been busy for the other matters.  Could you please
apply any necessary changes to the unicode branch?   As I'm
currently working on the HEAD trunk of Emacs, I don't have a
time to work on emacs-unicode.  So, now is the good timing
for applying big changes to the unicode branch.

> I'd gotten the impression from email a while ago that it wasn't ready
> for daily use, but maybe that's changed.  I don't want to be
> developing solely on a branch I can't effectively test.

The biggest problems for daily use are perhaps gnus and
rmail.  Dave said that he was working on rmail now.

Proper settings of coding-systems and character set
priorities for each language environment is also not yet
finished.

For the other operations, I think emacs-unicode now works
fairly well.

---
Ken'ichi HANDA
handa@etl.go.jp

plan for code freeze

[Stefan Monnier]

Would it be possible to have the URL package included as well ?


	Stefan

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    The package allows better network authentication for IMAP (in Gnus),
    SMTP (e.g., smtpmail.el) and third party packages (my Sieve package
    for instance).

Would this perhaps replace some existing Emacs packages?

    It should obviously not go into 21.3, but if 21.4 is freezed soonish I
    think it would be nice to include it.

It is not too late.

    Should I send a patch?  I have not verified all paperwork yet though.

Do you think that package is cleanly written?  That is the main thing
we need to check, and it is fine if you check it for us first.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

Do you think table.el is ready for installation?
Have all the issues previously mentioned been resolved?

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    I do not know what the proposed feature freeze entails, so I do not
    know how it would affect my proposed changes and additions.

Since it is just an idea, it is not terribly precise.

Re: plan for code freeze

[Richard Stallman]

What is the URL package?

Re: please consider emacs-unicode for pervasive changes

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     The package allows better network authentication for IMAP (in Gnus),
>     SMTP (e.g., smtpmail.el) and third party packages (my Sieve package
>     for instance).
>
> Would this perhaps replace some existing Emacs packages?

Not really.  It is a clean modularization of some code that has been
done ad-hoc in imap.el and smtpmail.el (and sieve*.el, but that is not
part of Emacs).

>     Should I send a patch?  I have not verified all paperwork yet though.
>
> Do you think that package is cleanly written?  That is the main thing
> we need to check, and it is fine if you check it for us first.

Yes, I like it.  It does not depend on any other libraries (self
contained), the API is documented in a TEXI manual (it seems
incomplete though) and mimics the standardized Java API for SASL.  I
am using it in my local copies of imap.el and sieve*.el.

It is definitely better than having it implemented differently and
undocumented in imap.el/smtpmail.el which is the current situation.

I'll send the patch, track down papers, and then commit the patch
unless someone objects in the meantime.

Re: please consider emacs-unicode for pervasive changes

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

>>     The package allows better network authentication for IMAP (in Gnus),
>>     SMTP (e.g., smtpmail.el) and third party packages (my Sieve package
>>     for instance).
>>
>> Would this perhaps replace some existing Emacs packages?
>
> Not really.  It is a clean modularization of some code that has been
> done ad-hoc in imap.el and smtpmail.el (and sieve*.el, but that is not
> part of Emacs).

To clarify:  it is not the same code, but a rewrite from scratch.

Re: plan for code freeze

[Stefan Monnier]

> What is the URL package?

It used to be part of W3 and is holds the URL parsing and fetching
(via HTTP and other protocols) part of it.


	Stefan

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    I'll send the patch, track down papers, and then commit the patch
    unless someone objects in the meantime.

That is a useful way to proceed.  Please don't check in the patches
until you see that we have actually received the papers.  You can ask
assign@gnu.org whether papers have arrived.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

It looks like we don't have legal papers for table.el.
You signed an assignment for your changes to Emacs.
It is not automatically the case that table.el constitutes
a change to Emacs, since it is an added program.
However, if you send a letter to the FSF saying that
table.el constitutes a change to Emacs and is covered by
those papers, that will do the job.

assign@gnu.org will tell you what to do.

Re: please consider emacs-unicode for pervasive changes

[Tak Ota]

[-- Attachment #1: Type: Text/Plain, Size: 580 bytes --]

I hope you haven't lost it.  Please refer to the attached
correspondence.

-Tak

Thu, 15 Aug 2002 13:54:49 -0600 (MDT): Richard Stallman <rms@gnu.org> wrote:

> It looks like we don't have legal papers for table.el.
> You signed an assignment for your changes to Emacs.
> It is not automatically the case that table.el constitutes
> a change to Emacs, since it is an added program.
> However, if you send a letter to the FSF saying that
> table.el constitutes a change to Emacs and is covered by
> those papers, that will do the job.
> 
> assign@gnu.org will tell you what to do.

[-- Attachment #2: Type: Message/Rfc822, Size: 1270 bytes --]

From: Tak Ota <Takaaki.Ota@am.sony.com>
To: assign@gnu.org
Subject: Re: Takaaki Ota
Date: Tue, 19 Dec 2000 08:19:26 -0800 (PST)
Message-ID: <20001219.081926.107712473.Takaaki.Ota@am.sony.com>

I have returned the signed assignment form regarding `table.el' early
last week.  Please confirm you have received it.  Thank you.

Takaaki Ota

__________________________ Original Message __________________________
Subject: Re: Takaaki Ota
Author:  assignments (assign@gnu.org)
Date:    Mon, 27 Nov 2000 12:01:51 -0500
> 
> I sent you the form to sign.  Thanks!!
> 
>                               - Brian Youmans, FSF copyright clerk
> 
> Free Software Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA
>   voice: +1-617-542-5942  fax: +1-617-542-2652  web: http://www.gnu.org

[-- Attachment #3: Type: Message/Rfc822, Size: 1352 bytes --]

From: assignments <assign@gnu.org>
To: Takaaki.Ota@am.sony.com
Subject: Re: Takaaki Ota
Date: Tue, 19 Dec 2000 11:43:58 -0500
Message-ID: <E148Prq-0001Gu-00@fencepost.gnu.org>

Yes, we received it - thank you!!

                              - Brian Youmans, FSF copyright clerk

Free Software Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA
  voice: +1-617-542-5942  fax: +1-617-542-2652  web: http://www.gnu.org

Re: please consider emacs-unicode for pervasive changes

[FSF Copyright Assignment Clerk]

We do seem to have  Tak's copyright assignment.  Probably whoever looked
in copyright.list missed it:


EMACS	Takaaki Ota	Japan 1961	2000-12-04
Assigns table.el and future changes.
Takaaki.Ota@am.sony.com, tak@znet.com

                              - Brian Youmans, FSF copyright clerk

Free Software Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA
voice: +1-617-542-5942, x14  fax: +1-617-542-2652  web: http://www.gnu.org

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

I don't know why this happened, but when I searched our list of
copyright papers for your name yesterday, I did not find your entry.
But I looked again just now, and it is there.

So I will install table.el soon.

Could you write an item for etc/NEWS?

Re: please consider emacs-unicode for pervasive changes

[Tak Ota]

Fri, 16 Aug 2002 11:59:22 -0600 (MDT): Richard Stallman <rms@gnu.org> wrote:

> Could you write an item for etc/NEWS?

How about this?

*** The new package table.el implements editable, WYSIWYG and embedded
`text tables' in emacs buffers.  It implements a quasi mode by way of
text property.  Unlike major and minor mode, that is effective
throughout a buffer, this quasi mode exists within a limited area in a
buffer so that the effect is localized.  The package emulates WYSIWYG
table editing available in modern word processors.  The package also
can generate a table source in typesetting and markup languages such
as latex and html from the visually laid out text table.

-Tak

Re: plan for code freeze

[Karl Eichwalder]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

[URL package]

> It used to be part of W3 and is holds the URL parsing and fetching
> (via HTTP and other protocols) part of it.

I'd like to see it added, too.  Having such a generic feature coming
with Emacs is much more important than adding applications like an IRC
client.

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

Re: plan for code freeze

[Richard Stallman]

Ok, let's add the URL package.  Bill, do we have papers for it yet?

Re: plan for code freeze

[Karl Eichwalder]

huug <huug.at.gmane@xs4all.nl> writes:

> How about the other half of W3?

It's great stuff but it is not general enough to justify an inclusion.
There were big plans to write a DSSSL engine and to improve various
other aspects of W3.

> It is realy needed by gnus users who rather read their mail then bitch
> about it not being PC formatted.

W3 isn't required.  If you are better off using w3m these days.

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

Re: plan for code freeze

[Miles Bader]

Karl Eichwalder <keichwa@gmx.net> writes:
> W3 isn't required.  If you are better off using w3m these days.

Well, in the sense of it being on average somewhat less sucky than w3,
yes.

But w3m is far from perfect, and it definitely feels much more `foreign'
in emacs [via w3m-el] than w3 does.  I think a good, fast, w3 (or
something similar) is still a very worthwhile goal.

-Miles
-- 
Fast, small, soon; pick any 2.

Re: plan for code freeze

[Richard Stallman]

Could someone tell me what w3m is?

Re: plan for code freeze

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> Could someone tell me what w3m is?

w3 is a web browser written in elisp.
w3m is a standalone text web browser, very similar to lynx.
w3m-mode is a mode (not part of Emacs) that calls w3m in the
background to render HTML.

Alex.

Re: plan for code freeze

[Richard Stallman]

    w3m-mode is a mode (not part of Emacs) that calls w3m in the
    background to render HTML.

I can see how this could work for some purposes.
What happens for graphics, and for multiple fonts?
Can Emacs use w3m to display those?

Re: plan for code freeze

[William M. Perry]

Richard Stallman <rms@gnu.org> writes:

> Ok, let's add the URL package.  Bill, do we have papers for it yet?

Yes, papers for that were signed over ages ago.

-bp
-- 
Ceterum censeo vi esse delendam

Re: plan for code freeze

[Richard Stallman]

    > Ok, let's add the URL package.  Bill, do we have papers for it yet?

    Yes, papers for that were signed over ages ago.

Ok, let's install it now.  Can you do so?

Re: plan for code freeze

[Per Abrahamsen]

Karl Eichwalder <keichwa@gmx.net> writes:

> huug <huug.at.gmane@xs4all.nl> writes:
>
>> It is realy needed by gnus users who rather read their mail then bitch
>> about it not being PC formatted.
>
> W3 isn't required.  If you are better off using w3m these days.

I'm not sure how to parse the last sentence, but does w3m-el handle
links?  

In any case, w3 is used for much more than displaying text mail, it is
also used for parsing data from various web services, both web boards
and google in Gnus.  I have seen other Lisp packages use w3 for
fetching and parsing data from other web services, like dictionaries.

And finally, my old dream was to integrate W3 and customize, so you
can use W3 to write wizards (or "saints") i.e. interactive tutorials
for customizing Emacs, in an extended HTML.  W3 have a few tags for
that purpose, but it only really makes sense if W3 is bundled with
both emacsen.

Re: plan for code freeze

[William M. Perry]

Richard Stallman <rms@gnu.org> writes:

>     > Ok, let's add the URL package.  Bill, do we have papers for it yet?
>
>     Yes, papers for that were signed over ages ago.
>
> Ok, let's install it now.  Can you do so?

Unfortunately I'm stuck out in seattle right now and am swamped with work.
Is there anythin necessary other than symlinking the url CVS tree into the
emacs/lisp/ repository?

-bp
-- 
Ceterum censeo vi esse delendam

Re: plan for code freeze

[Richard Stallman]

    Unfortunately I'm stuck out in seattle right now and am swamped with work.
    Is there anythin necessary other than symlinking the url CVS tree into the
    emacs/lisp/ repository?

Do such symlinks work in CVS repositories?  I would have guessed they
do not, but I am not an expert.

Re: plan for code freeze

[Stefan Monnier]

>     Unfortunately I'm stuck out in seattle right now and am swamped with work.
>     Is there anythin necessary other than symlinking the url CVS tree into the
>     emacs/lisp/ repository?
> 
> Do such symlinks work in CVS repositories?  I would have guessed they
> do not, but I am not an expert.

CVS has special support for symlinks-in-the-repository, so it should
work, and if it doesn't, then CVS will tell you (I seem to remember that
there are limits to what CVS handles).
It is already used for emacs/src/regex.[ch] which is symlinked
with gnulib/regex.[ch].


	Stefan

Re: plan for code freeze

[Sam Steingold]

> * In message <200208291753.g7THrss11621@rum.cs.yale.edu>
> * On the subject of "Re: plan for code freeze "
> * Sent on Thu, 29 Aug 2002 13:53:54 -0400
> * Honorable "Stefan Monnier" <monnier+misc/ads@rum.cs.yale.edu> writes:
>
> CVS has special support for symlinks-in-the-repository, so it should
> work, and if it doesn't, then CVS will tell you (I seem to remember that
> there are limits to what CVS handles).
> It is already used for emacs/src/regex.[ch] which is symlinked
> with gnulib/regex.[ch].

this is a stunning revelation to me (I had some quite disastrous
experience with symlinks in the CVS some years ago, and the CVS manual
on the cvshome.org appears to support my understanding that symlink and
CVS do not work together at all).

Could you please be more specific: how do symlinks work?

thanks!

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
I want Tamagochi! -- What for?  Your pet hamster is still alive!

Re: plan for code freeze

[Stefan Monnier]

> > CVS has special support for symlinks-in-the-repository, so it should
> > work, and if it doesn't, then CVS will tell you (I seem to remember that
> > there are limits to what CVS handles).
> > It is already used for emacs/src/regex.[ch] which is symlinked
> > with gnulib/regex.[ch].
> 
> this is a stunning revelation to me (I had some quite disastrous
> experience with symlinks in the CVS some years ago, and the CVS manual
> on the cvshome.org appears to support my understanding that symlink and
> CVS do not work together at all).
> 
> Could you please be more specific: how do symlinks work?

I think you confuse the issue of revision-control of symlinks
in your project, against using symlinks inside the repository.

You indeed cannot store and revision control symlinks into the repository
(the typical workaround is to use a revision-controlled Makefile
which creates the symlinks and to just do `make' after every
`cvs update').

But you can use symlinks inside the repository for purposes of
providing the same RCS file(s) under a few different names in the CVS
repository and such that updating one automatically updates
the other(s) (because they really are one and the same).


	Stefan

Re: plan for code freeze

[Sam Steingold]

> * In message <200208292015.g7TKFAI13686@rum.cs.yale.edu>
> * On the subject of "Re: plan for code freeze "
> * Sent on Thu, 29 Aug 2002 16:15:09 -0400
> * Honorable "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
>
> > > CVS has special support for symlinks-in-the-repository, so it should
> > > work, and if it doesn't, then CVS will tell you (I seem to remember that
> > > there are limits to what CVS handles).
> > > It is already used for emacs/src/regex.[ch] which is symlinked
> > > with gnulib/regex.[ch].
> > 
> > this is a stunning revelation to me (I had some quite disastrous
> > experience with symlinks in the CVS some years ago, and the CVS manual
> > on the cvshome.org appears to support my understanding that symlink and
> > CVS do not work together at all).
> > 
> > Could you please be more specific: how do symlinks work?
> 
> I think you confuse the issue of revision-control of symlinks
> in your project, against using symlinks inside the repository.

nope - I have several identical files: FOO, src/BAR, etc/ZOT and I want
them all to refer the the same file in the CVS repository (FOO,v).
this caused so many problems that now each of these files has its own
*,v RCS file.

> But you can use symlinks inside the repository for purposes of
> providing the same RCS file(s) under a few different names in the CVS
> repository and such that updating one automatically updates the
> other(s) (because they really are one and the same).

so how do I tell cvs to do

$ rm -f src/BAR,v
$ ln -s FOO,v src/BAR,v

thanks

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
There are two ways to write error-free programs; only the third one works.

Re: plan for code freeze

[Alan Shutko]

Sam Steingold <sds@gnu.org> writes:

> so how do I tell cvs to do
>
> $ rm -f src/BAR,v
> $ ln -s FOO,v src/BAR,v

I think you have to have shell access to the repository... I don't
think you can do it within cvs.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Let's nuke the bridge we've burned 2,000 times before...

Re: plan for code freeze

[Stefan Monnier]

> > > > CVS has special support for symlinks-in-the-repository, so it should
> > > > work, and if it doesn't, then CVS will tell you (I seem to remember that
> > > > there are limits to what CVS handles).
> > > > It is already used for emacs/src/regex.[ch] which is symlinked
> > > > with gnulib/regex.[ch].
> > > 
> > > this is a stunning revelation to me (I had some quite disastrous
> > > experience with symlinks in the CVS some years ago, and the CVS manual
> > > on the cvshome.org appears to support my understanding that symlink and
> > > CVS do not work together at all).
> > > 
> > > Could you please be more specific: how do symlinks work?
> > 
> > I think you confuse the issue of revision-control of symlinks
> > in your project, against using symlinks inside the repository.
> 
> nope - I have several identical files: FOO, src/BAR, etc/ZOT and I want
> them all to refer the the same file in the CVS repository (FOO,v).
> this caused so many problems that now each of these files has its own
> *,v RCS file.

What have you tried ?

> > But you can use symlinks inside the repository for purposes of
> > providing the same RCS file(s) under a few different names in the CVS
> > repository and such that updating one automatically updates the
> > other(s) (because they really are one and the same).
> 
> so how do I tell cvs to do
> 
> $ rm -f src/BAR,v
> $ ln -s FOO,v src/BAR,v

There is no such cvs command, you have to do it by hand (i.e. use the
two lines above).


	Stefan

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Kenichi Handa <handa@etl.go.jp> writes:

> For the other operations, I think emacs-unicode now works
> fairly well.

I think that depends.  For one thing, it will typically clobber
iso-2022 files.  For another, redisplay is buggy, which is the main
reason I was looking to merge with the trunk in the first place.

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Could people who are working on things that might be desirale to
> include soon please speak up and identify those changes?

Not that I'm working on, but there are partly done things on the todo
list that deserve attention and I don't think have been tackled.

It would be nice to include W3, but I'm not sure it's in a good enough
state, and I'm not likely to fix it anytime soon.  (It has various
problems and omissions currently, and I don't think all its support
files are clean enough to include, although including it might
actually get people to help with it.)  However, a few of its files may
be worth including, as they aren't W3-specific as far as I remember,
e.g. socks.el and ssl.el.  (Some of the W3 pieces actually reveal the
need for extra hooks in Emacs; I think socks.el, as well as various
stuff for Emacspeak, as also noted in todo.)

The `url' package which supports W3 probably is in a good enough state
to install, however, although it still needs work and documentation.
It provides a framework and support for accessing URLs, like an HTTP
1.1 client in Lisp.  As far as I remember, it has complete assignments
(unlike at least one file in W3), but since I've lost access to
fencepost, I can't check.

Presumably the current Gnus development source should be considered,
but last I knew, there were assignment problems with that, and someone
will have to do the same sort of work as we did with Gnus 5.9
(including checking that bits we excluded then aren't still in the
sources).  I suspect it needs Mule-related attention too.

There's other work that could be taken up with small amounts of effort
to avoid it going to waste, such as merging back my branch containing
the XEmacs theme support for Custom which has been hanging around for
a long time.

Re: please consider emacs-unicode for pervasive changes

[Alex Schroeder]

Dave Love <d.love@dl.ac.uk> writes:

> There's other work that could be taken up with small amounts of effort
> to avoid it going to waste, such as merging back my branch containing
> the XEmacs theme support for Custom which has been hanging around for
> a long time.

We where just talking about this in the color-theme.el thread.  :)  I
am glad to see that the code is still around.  Should anybody merge
this stuff back, I can try an automatic conversion of the color themes
in color-theme.el, so that we can give the cus-theme.el code a
thorough testing.

Alex.

Re: please consider emacs-unicode for pervasive changes

[Kenichi Handa]

In article <rzqr8gfx8hm.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:
> Kenichi Handa <handa@etl.go.jp> writes:
>>  For the other operations, I think emacs-unicode now works
>>  fairly well.

> I think that depends.  For one thing, it will typically clobber
> iso-2022 files.  

Yes.  On reading and writing iso-2022 files, Emacs-unicode
may designate different charsets.  I still can't find a time
to fix it.

But, is it a big problem?  Even in Emacs 21, iso-2022 files
may be changed just by reading and writing (e.g. by removing
redundant escape sequences).

> For another, redisplay is buggy, which is the main
> reason I was looking to merge with the trunk in the first place.

But, the trunk is also not stable in the area of redisplay
in these days...

The most frustrating redisplay bug of emacs-unicode I notice
is that cursor sometimes disappear, and that was fixed in
HEAD by Gerd's series of changes in April.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    > I think that depends.  For one thing, it will typically clobber
    > iso-2022 files.  

    Yes.  On reading and writing iso-2022 files, Emacs-unicode
    may designate different charsets.  I still can't find a time
    to fix it.

What exactly is the nature of the problem?  "Clobber" usually means
"destroy or ruin"; however, your statement seems to say it would alter
the file but the altered file would still represent the correct
characters.  Which one is it?

Re: plan for code freeze

[William M. Perry]

"Stefan Monnier" <monnier+misc/ads@rum.cs.yale.edu> writes:

>>     Unfortunately I'm stuck out in seattle right now and am swamped with work.
>>     Is there anythin necessary other than symlinking the url CVS tree into the
>>     emacs/lisp/ repository?
>> 
>> Do such symlinks work in CVS repositories?  I would have guessed they
>> do not, but I am not an expert.
>
> CVS has special support for symlinks-in-the-repository, so it should
> work, and if it doesn't, then CVS will tell you (I seem to remember that
> there are limits to what CVS handles).  It is already used for
> emacs/src/regex.[ch] which is symlinked with gnulib/regex.[ch].

Who has access to the CVS machine to make these symlinks?  I don't have
direct access to that machine anymore.

-bp
-- 
Ceterum censeo vi esse delendam

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Kenichi Handa <handa@etl.go.jp> writes:

> But, is it a big problem?  Even in Emacs 21, iso-2022 files
> may be changed just by reading and writing (e.g. by removing
> redundant escape sequences).

RMS complained about even chaneglogs getting changed, but it will
certainly screw various Emacs 21 lisp/{international,language} files.

> The most frustrating redisplay bug of emacs-unicode I notice
> is that cursor sometimes disappear,

It misses entire chunks of text for me, particularly after pasting an
sexp in, I think.  I've been quite confused trying to use it.

Re: please consider emacs-unicode for pervasive changes

[Kenichi Handa]

In article <E17mb1H-000733-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>>  I think that depends.  For one thing, it will typically clobber
>>  iso-2022 files.  

>     Yes.  On reading and writing iso-2022 files, Emacs-unicode
>     may designate different charsets.  I still can't find a time
>     to fix it.

> What exactly is the nature of the problem?  "Clobber" usually means
> "destroy or ruin"; however, your statement seems to say it would alter
> the file but the altered file would still represent the correct
> characters.  Which one is it?

As Emacs-unicode unifies, for instance, character C1 of
charset CS1 and character C2 of CS2.  So, so even if an
original iso-2022-7bit file uses the different byte sequence
to represent them, when emacs reads it and write, C2 will be
encoded by the same byte sequence as C1.

It doesn't matter for Emacs because when Emacs reads that
file again, there's no difference.

It's difficult to answer the question "Are C1 and C2 the
same character?"  To Emacs-unicode (and also to Unicoders),
they are same.  To some other application, they may be
different.

But, this kind of thing happen only for such coding systems
as iso-2022-7bit, iso-latin-1-with-esc, etc (those invented
by Emacs) because they can support more than two charsets
that contains characters unified by Emacs.

Other application usually don't use such coding systems but
use iso-2022-jp, iso-2022-kr, etc.  As charsets supported by
each of them doesn't overlap (thus not unified), reading and
writing by Emacs-unicode has no problem.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: please consider emacs-unicode for pervasive changes

[Eli Zaretskii]

On Thu, 5 Sep 2002, Kenichi Handa wrote:

> As Emacs-unicode unifies, for instance, character C1 of
> charset CS1 and character C2 of CS2.  So, so even if an
> original iso-2022-7bit file uses the different byte sequence
> to represent them, when emacs reads it and write, C2 will be
> encoded by the same byte sequence as C1.
> 
> It doesn't matter for Emacs because when Emacs reads that
> file again, there's no difference.

As an example of a situation where it does matter, consider this: you 
visit a file, edit some parts of it, then save it.  It would be 
reasonable to expect that portions of the file you didn't change will 
compare equal to the original file.  In other words, running `diff' on 
the original and the edited files will not show any changes in those line 
you didn't modify.  However, unification means that `diff' _will_ 
sometimes show differences in unedited portions of the file, because C2 
was recoded into a different codepoint.

(Please do not interpret the above to mean I'm against unification.  I'm 
not.)

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    RMS complained about even chaneglogs getting changed,

I recall these changes but not what caused them.  Were they caused by
the emacs-unicode branch?

If so, what exactly was the nature of the change that occurred?  Was
the change a matter of replacing one correct iso-2022 representation
with a different but equally correct representation for the same
characters?  Or was the change bigger than that?

If the change was bigger than that, it could be a bug that should be
fixed.

							  but it will
    certainly screw various Emacs 21 lisp/{international,language} files.

As part of convertng Emacs to use unicode for most characters,
won't we also change these files to use unicode?  So they won't
be clobbered.

Editing the non-unicode Emacs 21 files might change them, indeed.  Is
this an inevitable consequence of the unification done by Unicode?  If
so, we may as well just accept it, right?

Re: please consider emacs-unicode for pervasive changes

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     RMS complained about even chaneglogs getting changed,
>
> I recall these changes but not what caused them.  Were they caused by
> the emacs-unicode branch?

I b0rked the ChangeLog files a couple of times.

> If so, what exactly was the nature of the change that occurred?  Was
> the change a matter of replacing one correct iso-2022 representation
> with a different but equally correct representation for the same
> characters?  Or was the change bigger than that?

In my case, the í in Pavel Janík's name was changed from a Latin-2
character to a Latin-1 character.

I had turned on unify-8859-on-decoding-mode.  This unification is the
correct behavior, I think, for unify-8859-on-decoding-mode.  I turned
this mode off and I haven't clobbered the file since.  (AFAIK.)

I tried to devise a file variable that would turn off this mode for a
specific file, but the implementation of unify-8859-on-decoding-mode
appears to be such that this is difficult: it uses translation
tables, which are global.

> 							  but it will
>     certainly screw various Emacs 21 lisp/{international,language} files.
>
> As part of convertng Emacs to use unicode for most characters,
> won't we also change these files to use unicode?  So they won't
> be clobbered.

> Editing the non-unicode Emacs 21 files might change them, indeed.  Is
> this an inevitable consequence of the unification done by Unicode?  If
> so, we may as well just accept it, right?

Yep.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Kenichi Handa <handa@etl.go.jp> writes:

> Other application usually don't use such coding systems but
> use iso-2022-jp, iso-2022-kr, etc.  As charsets supported by
> each of them doesn't overlap (thus not unified), reading and
> writing by Emacs-unicode has no problem.

But there will be a problem if you rely on coding system
auto-detection.  For instance, if you write out a buffer showing the
jisx0208 charset as iso-2022-jp, Emacs 21 will auto-detect that
encoding when you visit the file.  However, Emacs 22 auto-detects it
as iso-2022-7bit -- I don't know if this is a bug -- and if you then
write it out, you'll get at least latin-iso8859-1 and chinese-gb2312
in the mix.

I was particularly warning about iso-2022-7bit, i.e. many of the Emacs
21 files in lisp/{language,international}, and ChangeLogs (which rms
already complained about) since this is going to developers.

[For the benefit of others:  Emacs 22 doesn't necessarily unify
characters from CJK sets, in particular -- it's done explicitly in the
Mule configuration, and can now be undone.  However, as things stand,
for example, you get a mixture of single- and double-width characters
used for non-Japanese parts of japanese-jisx0208, and Chinese used for
some of the Japanese, since a unification table for it is installed.
Hence my remarks concerning lack of complete unification qua bug.]

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     RMS complained about even chaneglogs getting changed,
> 
> I recall these changes but not what caused them.  Were they caused by
> the emacs-unicode branch?

Yes, in the case you complained to me about (on the branch, and it was
actually edits of handa's did originally).  However, I seem to
remember there were other problems, probably due to people using
unification-on-decode, contrary to the warnings.

> If so, what exactly was the nature of the change that occurred?  Was
> the change a matter of replacing one correct iso-2022 representation
> with a different but equally correct representation for the same
> characters?

Yes, since it was Latin-1 v. Latin-2 if I remember correctly.  If it
had been Chinese v. Japanese, it might not have been correct.

> 							  but it will
>     certainly screw various Emacs 21 lisp/{international,language} files.
> 
> As part of convertng Emacs to use unicode for most characters,
> won't we also change these files to use unicode?

They mostly haven't been touched, and don't need to be.  You can't
generally change them to Unicode (as opposed to utf-8-emacs) because
they may contain non-Unicode characters.  Also, if you want, say, to
maintain the distinction between Japanese and Chinese in HELLO, you
don't want to unify that.

> So they won't be clobbered.

If anyone else starts working on that code, they better understand the
issues anyhow...

> Editing the non-unicode Emacs 21 files might change them, indeed.

(Those and similar files.)  That's just what I'm warning about.

> Is this an inevitable consequence of the unification done by
> Unicode?

No.  The fact that you can't prevent it for i/o of general iso-2022 is
a missing feature, as handa said.  (Not that I know the design for
that.)  I thought it was a design feature you insisted on that the
character space is much bigger than Unicode for that sort of reason.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    But, this kind of thing happen only for such coding systems
    as iso-2022-7bit, iso-latin-1-with-esc, etc (those invented
    by Emacs) because they can support more than two charsets
    that contains characters unified by Emacs.

If it only affects semi-obsolete character sets invented for Emacs,
then it is not a serious problem.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

      In other words, running `diff' on 
    the original and the edited files will not show any changes in those line 
    you didn't modify.  However, unification means that `diff' _will_ 
    sometimes show differences in unedited portions of the file, because C2 
    was recoded into a different codepoint.

Given that we are using unicode and unification,
isn't this inevitable?

Re: please consider emacs-unicode for pervasive changes

[Kenichi Handa]

In article <E17nAJW-0003ku-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>       In other words, running `diff' on 
>     the original and the edited files will not show any changes in those line 
>     you didn't modify.  However, unification means that `diff' _will_ 
>     sometimes show differences in unedited portions of the file, because C2 
>     was recoded into a different codepoint.

> Given that we are using unicode and unification,
> isn't this inevitable?

Not necessarily.  If we put the text property `charset' (the
value is a charset) to a text on decoding, and check it on
encoding, we can preserve the same byte sequence.

Putting that text property to all the text is too much.  We
should put it only on such characters that will be encoded
differently without that information.

The new code conversion routine of emacs-unicode already has
a basic mechanism to handle to such a thing (currently used
only for compositions).  Only that I don't have a time to
write concrete codes.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: please consider emacs-unicode for pervasive changes

[Kenichi Handa]

In article <Pine.SUN.3.91.1020905164418.18455A-100000@is>, Eli Zaretskii <eliz@is.elta.co.il> writes:
> On Thu, 5 Sep 2002, Kenichi Handa wrote:

>>  As Emacs-unicode unifies, for instance, character C1 of
>>  charset CS1 and character C2 of CS2.  So, so even if an
>>  original iso-2022-7bit file uses the different byte sequence
>>  to represent them, when emacs reads it and write, C2 will be
>>  encoded by the same byte sequence as C1.
>>  
>>  It doesn't matter for Emacs because when Emacs reads that
>>  file again, there's no difference.

> As an example of a situation where it does matter, consider this: you 
> visit a file, edit some parts of it, then save it.  It would be 
> reasonable to expect that portions of the file you didn't change will 
> compare equal to the original file.  In other words, running `diff' on 
> the original and the edited files will not show any changes in those line 
> you didn't modify.

But, `diff' is another program.  Emacs' ediff-files should
work well.

And, please note that even Emacs 21 don't preserve the same
byte sequence for iso-2022-7bit file in rare case.  This
problem can actually be ignored only because such a case is
very very rare.

Anyway, I'm not claiming that we don't have to solve this
problem.  Just I have more urgent tasks for the moment.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    They mostly haven't been touched, and don't need to be.  You can't
    generally change them to Unicode (as opposed to utf-8-emacs) because
    they may contain non-Unicode characters.

What non-Unicode characters do you mean?  In the Unicode version, the
only non-Unicode characters Emacs supports will be Han characters.
Why would we want to have non-Han non-Unicode characters in these files
when Emacs does not support them?

If you think there is a reason to do so, would you please explain what
it is, why, and which characters we would use?  Please give one
concrete example to nail things down.

    > Is this an inevitable consequence of the unification done by
    > Unicode?

    No.  The fact that you can't prevent it for i/o of general iso-2022 is
    a missing feature, as handa said.

Handa, I have not seen where you said that.  Would you please address
this question?

      I thought it was a design feature you insisted on that the
    character space is much bigger than Unicode for that sort of reason.

I am not sure what this missing feature would be, and I don't know
what "that sort of reason" refers to.  The reason the character set is
bigger than Unicode is to avoid unifying Han characters.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    Not necessarily.  If we put the text property `charset' (the
    value is a charset) to a text on decoding, and check it on
    encoding, we can preserve the same byte sequence.

    Putting that text property to all the text is too much.  We
    should put it only on such characters that will be encoded
    differently without that information.

This could be a useful feature.  These properties won't be necessary
for correctness, and it would be no disaster if they got lost,
but when they are present they will bring about better results.

Would someone like to implement it?

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> What non-Unicode characters do you mean?  In the Unicode version, the
> only non-Unicode characters Emacs supports will be Han characters.

I'm not sure whether you mean you'll veto anything else or I don't
know what I'm talking about.  Currently:

(let (non-uc)
  (dolist (cs (charset-list))
    (when (and (eq cs (plist-get (charset-plist cs) :name))
         (>= (or (plist-get (charset-plist cs) :code-offset) 0)
                #xf0000))
      (push cs non-uc)))
  non-uc)
  => (eight-bit eight-bit-control eight-bit-graphic chinese-gb2312 chinese-gbk chinese-cns11643-1 chinese-cns11643-2 chinese-cns11643-3 chinese-cns11643-4 chinese-cns11643-5 chinese-cns11643-6 chinese-cns11643-7 big5 chinese-big5-1 chinese-big5-2 japanese-jisx0208 japanese-jisx0208-1978 japanese-jisx0212 japanese-jisx0213-1 japanese-jisx0213-2 korean-ksc5601 chinese-sisheng ipa vietnamese-viscii-lower vietnamese-viscii-upper arabic-1-column arabic-2-column indian-is13194 indian-glyph devanagari-glyph indian-1-column tibetan ethiopic gb18030-4-byte-ext-1 gb18030-4-byte-ext-2)

They're used for things like raw bytes, CJK stuff, level 2, emacs-mule
support &c, and there need to be more eventually.

I don't think it's useful to worry about this and have endless
explanation.  It would be best to spend time implementing and testing,
and I think anyone wanting to work on it will have to read the code
like me.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    > What non-Unicode characters do you mean?  In the Unicode version, the
    > only non-Unicode characters Emacs supports will be Han characters.

    I'm not sure whether you mean you'll veto anything else or I don't
    know what I'm talking about.

I don't know why the IPA, Korean, Vietnamese, Indian, Arabic and
Ethiopic character sets exist in the Unicode branch.  I thought the
plan was to unify everything into Unicode except Han characters.

Handa, has that plan been changed?  Is there a reason why these should
not or cannot be unified?  Have you not finished unifying them?

Re: please consider emacs-unicode for pervasive changes

[Kenichi Handa]

In article <E17oCJe-0002hO-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> I don't know why the IPA, Korean, Vietnamese, Indian, Arabic and
> Ethiopic character sets exist in the Unicode branch.  I thought the
> plan was to unify everything into Unicode except Han characters.

> Handa, has that plan been changed?  Is there a reason why these should
> not or cannot be unified?  Have you not finished unifying them?

Each charset has different reason.

IPA: Some characters are not in Unicode.
Korean: It contains Chinese characters too.  But, by
	default, it is unified with Unicode.
		(unify-charset 'korean-ksc5601 nil 'deunify)
	will cancel the unification.
Vietnames: Simply because not yet worked on.
Indian: Glyph characters (i.e. what appear only in
	composition) are not in Unicode:
Arabic: Simply because not yet worked on.

By the way, as I must prepare my presentation at GNU/Linux
conference held in Japan next week, I won't be able to work
on Emacs this week.  I'll keep on reading mails, but please
don't expect a prompt response.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> This could be a useful feature.  These properties won't be necessary
> for correctness, and it would be no disaster if they got lost,

It would be unfortunate, as it is clobbering data.  Especially, it's
probably not visually obvious.

Text properties are currently fragile because they're often stripped
with calls of buffer-substring-no-properties and friends.  A lot of
that was done either before composition used text properties or
without considering it, and should be re-thought -- `-no-properties'
should typically be `-some-properties'.

I'm not sure how much trouble that can cause in practice when moving
text, but I think it needs attention.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    IPA: Some characters are not in Unicode.
    Korean: It contains Chinese characters too.  But, by
	    default, it is unified with Unicode.
		    (unify-charset 'korean-ksc5601 nil 'deunify)
	    will cancel the unification.

    Indian: Glyph characters (i.e. what appear only in
	    composition) are not in Unicode:

I see.  In that case, it is good that we support them separately,

    Vietnames: Simply because not yet worked on.
    Arabic: Simply because not yet worked on.

So we can expect these to disappear as separate character sets
in Emacs.

Dave, is it now clear what to do?

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> So we can expect these to disappear as separate character sets
> in Emacs.

No, you can't get rid of the charsets, even if you re-map them, but
don't worry about it.

> Dave, is it now clear what to do?

I don't know what you think I was unclear about.  It is not clear what
to do for some things, but that's not because I don't basically
understand the implementation.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    > So we can expect these to disappear as separate character sets
    > in Emacs.

    No, you can't get rid of the charsets, even if you re-map them, but
    don't worry about it.

Would you please explain why we can't get rid of those charsets even
after we have unified them into Unicode?  I would like to understand
this.

    > Dave, is it now clear what to do?

    I don't know what you think I was unclear about.  It is not clear what
    to do for some things, but that's not because I don't basically
    understand the implementation.

That is very abstract.  I am trying to help solve concrete issues.
What is the concrete point on which you are not sure what to do?

Re: please consider emacs-unicode for pervasive changes

[Eli Zaretskii]

On Fri, 6 Sep 2002, Richard Stallman wrote:

>       In other words, running `diff' on 
>     the original and the edited files will not show any changes in those line 
>     you didn't modify.  However, unification means that `diff' _will_ 
>     sometimes show differences in unedited portions of the file, because C2 
>     was recoded into a different codepoint.
> 
> Given that we are using unicode and unification,
> isn't this inevitable?

Perhaps it is; but it's something that might surprise (to put it mildly) 
users.  We should probably document this in some prominent place, unless 
we are going to take care of it.

Re: please consider emacs-unicode for pervasive changes

[Eli Zaretskii]

On 9 Sep 2002, Dave Love wrote:

> Richard Stallman <rms@gnu.org> writes:
> 
> > This could be a useful feature.  These properties won't be necessary
> > for correctness, and it would be no disaster if they got lost,
> 
> It would be unfortunate, as it is clobbering data.  Especially, it's
> probably not visually obvious.
> 
> Text properties are currently fragile because they're often stripped
> with calls of buffer-substring-no-properties and friends.

Agreed.  Perhaps text properties aren't the right vehicle for solving 
this problem.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    >       In other words, running `diff' on the original and the
    >     edited files will not show any changes in those line you
    >     didn't modify.  However, unification means that `diff'
    >     _will_ sometimes show differences in unedited portions of
    >     the file, because C2 was recoded into a different codepoint.

    > Given that we are using unicode and unification,
    > isn't this inevitable?

    Perhaps it is; but it's something that might surprise (to put it mildly) 
    users.  We should probably document this in some prominent place, unless 
    we are going to take care of it.

I agree.  The change to Unicode will be big news and announced in many
ways.  For now, the question is whether this particular consequence is
inevitable.  Is it something we must accept, or something we can fix?

    > Text properties are currently fragile because they're often stripped
    > with calls of buffer-substring-no-properties and friends.

    Agreed.  Perhaps text properties aren't the right vehicle for solving 
    this problem.

I don't think this is a serious problem.  Things use
buffer-substring-no-properties when they are going to do computation
on the text, or use it as a command, etc.  Programs that move text
around do not discard the text properties.

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> I agree.  The change to Unicode will be big news and announced in many
> ways.

If it's something the user needs to care about modulo some things
working better than before, it's a serious problem.  I don't think
there is such a problem.

> For now, the question is whether this particular consequence is
> inevitable.  Is it something we must accept, or something we can
> fix?

We've already said that encoding currently not being the almost-exact
inverse of decoding is something that will be fixed when someone gets
round to it.

I think people shouldn't worry about these issues unless they
understand the current implementation enough to hack on it and get it
to a state where users can test how it works in practice.

> I don't think this is a serious problem.  Things use
> buffer-substring-no-properties when they are going to do computation
> on the text, or use it as a command, etc.  Programs that move text
> around do not discard the text properties.

That isn't generally true.  I mentioned it because I've installed code
like that myself in the past.

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Would you please explain why we can't get rid of those charsets even
> after we have unified them into Unicode?

Because people want to use them.  You were complaining about charset
information not being preserved, after all.

> I would like to understand this.

Handa had better speak to his design.  I've mostly just read the
implementation and thought it was sensible.

> That is very abstract.  I am trying to help solve concrete issues.
> What is the concrete point on which you are not sure what to do?

There are various issues, but going over and over them here isn't
useful.  I ask experts where it's that easy.  The useful thing would
be for people to do work on and with the implementation so solutions
can be tried out and I'm afraid I'm currently unenthusiastic.

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

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

> > Text properties are currently fragile because they're often stripped
> > with calls of buffer-substring-no-properties and friends.
> 
> Agreed.  Perhaps text properties aren't the right vehicle for solving 
> this problem.

Surely they have to be.  Code that strips them just needs to be fixed.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    > Would you please explain why we can't get rid of those charsets even
    > after we have unified them into Unicode?

    Because people want to use them.

You are being very terse.  It is conceivable that you have a valid point,
but your words don't present it clearly and therefore I am not convinced.

Re: please consider emacs-unicode for pervasive changes

[Kenichi Handa]

In article <rzqhegd65y2.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:

> Richard Stallman <rms@gnu.org> writes:
>>  Would you please explain why we can't get rid of those charsets even
>>  after we have unified them into Unicode?

> Because people want to use them.  You were complaining about charset
> information not being preserved, after all.

>>  I would like to understand this.

> Handa had better speak to his design.  I've mostly just read the
> implementation and thought it was sensible.

It seems that the word "get rid of" is confusing.

Emacs-unicode still keeps all latin-iso8859-X charsets.  We
can't get rid of them.  Those charsets carry such
information as how to map their code point to Unicode, what
designation sequence to use to be encoded in iso-2022 base
coding systems.

But we can "get rid of" a special character code area for
each of them.

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

Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     > Would you please explain why we can't get rid of those charsets even
>     > after we have unified them into Unicode?
> 
>     Because people want to use them.
> 
> You are being very terse.  It is conceivable that you have a valid point,
> but your words don't present it clearly and therefore I am not convinced.

I don't see what more I can say.  What other reason is there for
adding charsets than users want or need them?  I can't remember what
charsets these were to justify each one; why do you want to get rid of
them anyhow?

I don't know why I should have to convince you anyway.  These were
probably not even ones I added.  I have added some that are of limited
interest, such as EBCDICs, but there's a point -- in the case of
EBCDIC, as an example that doesn't work properly in Mule 5.

If you don't trust me to know roughly what I'm doing, please find
someone else to do the Mule donkey work.  If you object to the whole
design, then I don't see what's basically wrong with it, and it's too
late to change it now.  It even achieves things I didn't think would
be feasible.

Re: please consider emacs-unicode for pervasive changes

[Richard Stallman]

    >     > Would you please explain why we can't get rid of those charsets even
    >     > after we have unified them into Unicode?
    > 
    >     Because people want to use them.
    > 
    > You are being very terse.  It is conceivable that you have a valid point,
    > but your words don't present it clearly and therefore I am not convinced.

    I don't see what more I can say.  What other reason is there for
    adding charsets than users want or need them?

Use them how?  For what purposes?  If I don't understand what use
they have, I cannot think about the question.

    I don't know why I should have to convince you anyway.

No reason it has to be you, but I am trying to understand the
situation and you could help.

    If you don't trust me to know roughly what I'm doing, please find
    someone else to do the Mule donkey work.  If you object to the whole
    design, then I don't see what's basically wrong with it, and it's too
    late to change it now.

I'm not ready to object to it, or support it--first I need to know
what it *is*.