merging etc

merging etc

[Miles Bader]

Just a note -- my usual emacs merging activity is going to be kind of
slow for a while, as my home internet connection (and phone!) has been
cut off.  [I'm sending this from a public machine at mangaland.]

Thanks,

-Miles

-- 
Do not taunt Happy Fun Ball.

Re: merging etc

[Miles Bader]

Ok, I've put all the changelog info from the arch logs into
"ChangeLog.multi-tty" files in the various emacs directories (on the
multi-tty branch).  I split the entries by directory and generally
cleaned up the text.

Richard also said he wants the multi-tty changelogs "crunched" before
merging -- i.e., essentially replacing many historical entries for a
given function/variable by a single entry for it with all the changes
(or in the case of a new function/variable, all entries for it except
"New function/variable" can be dropped entirely).  I'm not sure how
this is supposed to work for multiple authors changing the same
function.... (one changelog entry per author?).

That seems like a daunting task given the size of the logs though...

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: merging etc

[Stefan Monnier]

> Ok, I've put all the changelog info from the arch logs into
> "ChangeLog.multi-tty" files in the various emacs directories (on the
> multi-tty branch).  I split the entries by directory and generally
> cleaned up the text.

Thank you very much.

> Richard also said he wants the multi-tty changelogs "crunched" before
> merging -- i.e., essentially replacing many historical entries for a
> given function/variable by a single entry for it with all the changes
> (or in the case of a new function/variable, all entries for it except
> "New function/variable" can be dropped entirely).  I'm not sure how
> this is supposed to work for multiple authors changing the same
> function.... (one changelog entry per author?).

> That seems like a daunting task given the size of the logs though...

I actually would rather keep the whole uncrunched text.  I know it can be
found on the branch, but if we insist on putting more than just "merge from
branch", then we may as well keep it all.


        Stefan

Re: merging etc

[Juri Linkov]

>> Richard also said he wants the multi-tty changelogs "crunched" before
>> merging -- i.e., essentially replacing many historical entries for a
>> given function/variable by a single entry for it with all the changes
>> (or in the case of a new function/variable, all entries for it except
>> "New function/variable" can be dropped entirely).  I'm not sure how
>> this is supposed to work for multiple authors changing the same
>> function.... (one changelog entry per author?).
>
>> That seems like a daunting task given the size of the logs though...
>
> I actually would rather keep the whole uncrunched text.  I know it can be
> found on the branch, but if we insist on putting more than just "merge from
> branch", then we may as well keep it all.

And maybe after adding ChangeLog entries from multy-tty to the trunk's
ChangeLog to change all dates (without crunching changelog entries) to the
date of sync with the trunk.  This will look as all multy-tty changes were
made on the same day and won't break the chronology in ChangeLog.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: merging etc

[Richard Stallman]

    And maybe after adding ChangeLog entries from multy-tty to the trunk's
    ChangeLog to change all dates (without crunching changelog entries) to the
    date of sync with the trunk.  This will look as all multy-tty changes were
    made on the same day and won't break the chronology in ChangeLog.

Changing all the dates to the date of installation in the trunk
is essential.  That is what permit the second step of combining
and simplifying the various entries.

Re: merging etc

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     And maybe after adding ChangeLog entries from multy-tty to the trunk's
>     ChangeLog to change all dates (without crunching changelog entries) to the
>     date of sync with the trunk.  This will look as all multy-tty changes were
>     made on the same day and won't break the chronology in ChangeLog.
>
> Changing all the dates to the date of installation in the trunk
> is essential.  That is what permit the second step of combining
> and simplifying the various entries.

If a clear and concise algorithm can be presented on how to proceed
with this "crunching" I can atempt to do so.

I am motivated to get the mtty functionality into emacs core, even if
I wouldn't do the merging this way myself. (I hope the mtty history
wont be lost this way, that would really not be very good)

-- 
Joakim Verona

Re: merging etc

[Miles Bader]

joakim@verona.se writes:
> I wouldn't do the merging this way myself. (I hope the mtty history
> wont be lost this way, that would really not be very good)

The raw(ish) changelog entries are already in CVS on the multi-tty
branch (in per-directory "ChangeLog.multi-tty" files), so in that sense,
at least, the history won't be "lost"....

-miles
-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Re: merging etc

[Leo]

On 2007-08-24 09:01 +0100, joakim@verona.se wrote:
> I am motivated to get the mtty functionality into emacs core, even if
> I wouldn't do the merging this way myself. (I hope the mtty history
> wont be lost this way, that would really not be very good)

Many people would be grateful for your effort ;)

Maybe this merging difficulty can be avoided in future. I see one option
for Emacs -- GIT¹.

Footnotes: 
¹  http://git.or.cz/
-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: merging etc

[joakim]

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

> On 2007-08-24 09:01 +0100, joakim@verona.se wrote:
>> I am motivated to get the mtty functionality into emacs core, even if
>> I wouldn't do the merging this way myself. (I hope the mtty history
>> wont be lost this way, that would really not be very good)
>
> Many people would be grateful for your effort ;)
>
> Maybe this merging difficulty can be avoided in future. I see one option
> for Emacs -- GIT¹.

The way I'm used to working, there wouldnt be much of a "changelog" at
all, that information would be extracted from a SCM.

But I think even CVS would be able to create changelogs directly from
the commits the way Emacs maintainers wants it, so I dont see what
switching to git would change in this regard. Its more of a cultural
issue. (git would of course bring us many other benefits)

> Footnotes: 
> ¹  http://git.or.cz/-- 
> Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

-- 
Joakim Verona

Re: merging etc

[Richard Stallman]

    But I think even CVS would be able to create changelogs directly from
    the commits the way Emacs maintainers wants it, so I dont see what
    switching to git would change in this regard. Its more of a cultural
    issue. (git would of course bring us many other benefits)

The CVS change logs are insufficient because they do not list the
authors' names.  They list who checked in the change.

So that simply is not an option.

Re: merging etc

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     But I think even CVS would be able to create changelogs directly from
>     the commits the way Emacs maintainers wants it, so I dont see what
>     switching to git would change in this regard. Its more of a cultural
>     issue. (git would of course bring us many other benefits)
>
> The CVS change logs are insufficient because they do not list the
> authors' names.  They list who checked in the change.
>
> So that simply is not an option.

That could surely be fixed by adding meta data to the commit. But I'm
not going to argue this point.

Instead I would like ask if its possible to do the merge like this:

- people knowledgeable how to perform the merge with the given tool
  contraints do so now, merging mtty to head.

- In the changelog there will be a placeholder:
-------
Merge performed from mtty branch: TODO insert crunched mtty changelog
here.
-------

- somewhere in the Emacs tree there will be a mtty changelog.

- The mtty changelog is crunched piece by piece, and inserted into the
  main changelog incrementaly. The corresponding passage in the mtty
  changelog is removed to keep track of progress.


I would like to do it this way so several people can work together on
the crunching, and so the merging wont be delayed so people can start
find actual functional problems. Furthermore I dont feel very
comfortable with cvs, and this way feels less likely to mess up.

-- 
Joakim Verona

Re: merging etc

[Glenn Morris]

joakim@verona.se wrote:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
> - somewhere in the Emacs tree there will be a mtty changelog.
They already exist, in the multi-tty CVS branch with the name
ChangeLog.multi-tty.
> - The mtty changelog is crunched piece by piece, and inserted into the
>   main changelog incrementaly. The corresponding passage in the mtty
>   changelog is removed to keep track of progress.
>
> I would like to do it this way so several people can work together on
> the crunching
People can do this right now. Simply edit ChangeLog.multi-tty to make
whatever improvements you can, then check in the changes as you go along (or
send diffs).
Date: Sat, 25 Aug 2007 22:08:05 -0400
In-Reply-To: <m3mywf3hqi.fsf@kurono.home> (joakim@verona.se's message of "Sat,
	25 Aug 2007 14:45:41 +0200")
Message-ID: <peejhr2gl6.fsf@fencepost.gnu.org>
User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)

gnus inserts headers in body [was Re: merging etc]

[Glenn Morris]

Glenn Morris wrote:

<garbled message with headers in body>

Dammit, why does Gnus do that to me sometimes when I edit a draft then
send it? Anyone else ever bothered by this? I've always suspected it
may be some Gnus/VM interaction with different settings for some
message header separator...

Re: gnus inserts headers in body

[Reiner Steib]

[ Adding ding@gnus ]

On Sun, Aug 26 2007, Glenn Morris wrote:

> Glenn Morris wrote:
>
> <garbled message with headers in body>
>
> Dammit, why does Gnus do that to me sometimes when I edit a draft then
> send it? Anyone else ever bothered by this? 

No, I've never seen this happen for me (and I don't recall reports
about it neither) and I edit and send drafts quite often.  Ideas
anyone?

> I've always suspected it may be some Gnus/VM interaction with
> different settings for some message header separator...

Are you saying that you use VM?  I don't know how VM may interact here
as I don't know it.

Do you have a Gcc-ed copy of the message or maybe Joakim could provide
his copy?  It might provide some glue to see which headers were still
inserted correctly and which not (I suspect that the mailing list
software may change the order of the headers).

Also, please show us your settings, especially how you insert X-Spook,
X-Hue, X-Attribution, X-Detected-Kernel, and User-Agent.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: gnus inserts headers in body

[Glenn Morris]

Reiner Steib wrote:

> No, I've never seen this happen for me (and I don't recall reports
> about it neither) and I edit and send drafts quite often.  Ideas
> anyone?

It has happened to me several times.

>> I've always suspected it may be some Gnus/VM interaction with
>> different settings for some message header separator...
>
> Are you saying that you use VM?  I don't know how VM may interact here
> as I don't know it.

Yes, I use VM as well as Gnus. I have the impression the problem
occurs when I: start Gnus, compose a message, save as draft, start VM,
do some stuff, return to Gnus, edit draft, send.

I realize it was a vague complaint, I'll try to track down more
details when I can. It may well be my fault somehow.

Re: gnus inserts headers in body

[David Kastrup]

Glenn Morris <rgm@gnu.org> writes:

> Reiner Steib wrote:
>
>> No, I've never seen this happen for me (and I don't recall reports
>> about it neither) and I edit and send drafts quite often.  Ideas
>> anyone?
>
> It has happened to me several times.
>
>>> I've always suspected it may be some Gnus/VM interaction with
>>> different settings for some message header separator...
>>
>> Are you saying that you use VM?  I don't know how VM may interact here
>> as I don't know it.
>
> Yes, I use VM as well as Gnus. I have the impression the problem
> occurs when I: start Gnus, compose a message, save as draft, start VM,
> do some stuff, return to Gnus, edit draft, send.
>
> I realize it was a vague complaint, I'll try to track down more
> details when I can. It may well be my fault somehow.

Perhaps related:  News servers have occasionally rejected articles of
mine because they consisted of only headers (or something like that).
Inserting a blank line after the "--text follows this line--" line has
solved this problem when it occured.

The strange thing is that this blank line is not always needed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: merging etc

[Richard Stallman]

    - In the changelog there will be a placeholder:
    -------
    Merge performed from mtty branch: TODO insert crunched mtty changelog
    here.
    -------

If I did this, it would make more work for me, begging people over the
next weeks or months to actually do that.  I can't afford it.

    I would like to do it this way so several people can work together on
    the crunching, and so the merging wont be delayed so people can start
    find actual functional problems.

I already suggested how to do that.  In the multi-tty branch, copy its
own change unique log entries to a separate file (for each directory).
(I believe this has been done.)  Then various people can start
simplifying those files.

Alternatively, those files could be put into the trunk
under the name mtty-ChangeLog in each directory.  Then we can
work on simplifying them even without checking out multi-tty.

Re: merging etc

[Glenn Morris]

Richard Stallman wrote:

> The CVS change logs are insufficient because they do not list the
> authors' names.  They list who checked in the change.

This is not related to this issue, but when I check in changes written
by someone else, I find it helpful to put their name in the first line
of the CVS log entry.

Re: merging etc

[Richard Stallman]

    This is not related to this issue, but when I check in changes written
    by someone else, I find it helpful to put their name in the first line
    of the CVS log entry.

It may be related.  If we were to adopt such a convention and practice
it uniformly, it would eliminate that one reason.

I think that there are other issues.  For instance, when I make
related changes in several files, I put them together in the ChangeLog
file.  But CVS wouldn't know that.

CVS could know that if the files were checked in together,
but I can't do that with VC, which is the only way I know.

Another issue is that when we make a systematic simple change in lots
of files, sometimes we don't bother mentioning them all in ChangeLog.
But in the combined CVS log, they would all have to appear
individually (right?).

Perhaps there are systematic solutions for all these issues.

Re: merging etc

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I think that there are other issues.  For instance, when I make
> related changes in several files, I put them together in the ChangeLog
> file.  But CVS wouldn't know that.
>
> CVS could know that if the files were checked in together,
> but I can't do that with VC, which is the only way I know.

It looks like Stefan has slowly been extending VC to handle multiple
files in various operations, but I don't know if there's a
user-interface for this functionality yet.

However, I don't think that would help -- AFAIK, CVS has essentially no
notion of "multiple file commits", and treats multiple files committed
together more or less as if you had committed them separately (with the
same log message).[1]

If getting rid of ChangeLogs is desirable (and I'm not sure I agree that
it is, even though ChangeLogs are a big pain for merging), really the
only sane thing to do is switch to a better source-control system than
CVS -- and I also think the one that makes sense for Emacs is "git",
though for the time being I'm still using arch for my work on emacs.[2]

   [1] There do seem to be ways you can notice the difference,
e.g. commit email messages seem to batch files which are committed
together, and perhaps the locking behavior is slightly different, but
once things have been committed, I think that information disappears

   [2] Incidentally, since you (Richard) spend a lot of time in
"disconnected" mode, I think you'd personally benefit a lot from
something like git -- it would allow you to do all operations
(committing, merging, log-checking, etc) operations locally, with easy
synchronization once you have access to a network again.

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: merging etc

[David Kastrup]

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

> On 2007-08-24 09:01 +0100, joakim@verona.se wrote:
>> I am motivated to get the mtty functionality into emacs core, even
>> if I wouldn't do the merging this way myself. (I hope the mtty
>> history wont be lost this way, that would really not be very good)
>
> Many people would be grateful for your effort ;)
>
> Maybe this merging difficulty can be avoided in future. I see one
> option for Emacs -- GIT¹.
>
> Footnotes: 
> ¹  http://git.or.cz/

But git will not do the kind of ChangeLog munging that is asked for
here.

On the other hand, git maintains logs and merge history with
author/committer distinction (particularly important for merges).  One
could likely just stop using ChangeLog files at all, or generate them
on-demand (for example, to put into the tarball).

-- 
David Kastrup

Bootstrap error

[B. Anyos]

Hi,

I have a bootstrap error as follows:

[...]
Compiling /e/Tools/emacs/lisp/emacs-lisp/byte-opt.el

In toplevel form:
emacs-lisp/byte-opt.el:288:51:Error: Wrong type argument: listp, restp
Compiling /e/Tools/emacs/lisp/emacs-lisp/bytecomp.el

In toplevel form:
emacs-lisp/bytecomp.el:213:38:Error: Wrong type argument: listp, handler
Compiling /e/Tools/emacs/lisp/subr.el

In toplevel form:
subr.el:229:29:Error: Wrong type argument: listp, n
Compiling /e/Tools/emacs/lisp/progmodes/cc-mode.el

In toplevel form:
progmodes/cc-mode.el:170:13:Error: Wrong type argument: listp, source-eval
Compiling /e/Tools/emacs/lisp/progmodes/cc-vars.el

In toplevel form:
progmodes/cc-vars.el:83:19:Error: Wrong type argument: listp, l
make[1]: *** [compile-SH] Error 1
make[1]: Leaving directory `/e/Tools/emacs/lisp'
make: *** [bootstrap-gmake] Error 2


I've freshly taken sources from CVS. Would anyone solve this?

Regards,
 Bela

Re: merging etc

[Richard Stallman]

    If a clear and concise algorithm can be presented on how to proceed
    with this "crunching" I can atempt to do so.

Any time you can take multiple entries for a single function
and simplify them into one combined entry, if that makes the
whole thing simpler, you do it.

When you don't see more opportunities to do this, you are done.

Re: merging etc

[Richard Stallman]

    > That seems like a daunting task given the size of the logs though...

    I actually would rather keep the whole uncrunched text.  I know it can be
    found on the branch, but if we insist on putting more than just "merge from
    branch", then we may as well keep it all.

Not crunching changelog makes for a lot more work understanding it
in the future.

But I don't insist that it be crunched "perfectly".  Just to the
extent that it makes the text simpler.

Re: merging etc

[Stefan Monnier]

>> That seems like a daunting task given the size of the logs though...
>     I actually would rather keep the whole uncrunched text.  I know it can be
>     found on the branch, but if we insist on putting more than just "merge from
>     branch", then we may as well keep it all.

> Not crunching changelog makes for a lot more work understanding it
> in the future.

I see no evidence or hint that it would be the case.


        Stefan

Re: merging etc

[Richard Stallman]

    > Not crunching changelog makes for a lot more work understanding it
    > in the future.

    I see no evidence or hint that it would be the case.

The bigger the change log is, the harder it is to grasp
the changes described.

Re: merging etc

[Stefan Monnier]

>> Not crunching changelog makes for a lot more work understanding it
>> in the future.

>     I see no evidence or hint that it would be the case.

> The bigger the change log is, the harder it is to grasp
> the changes described.

I tend to believe the opposite: the description of small changes are easier
to understand than description of combined changes.


        Stefan

Re: merging etc

[Richard Stallman]

    I tend to believe the opposite: the description of small changes are easier
    to understand than description of combined changes.

The usual simplification is to replace

        * foo.c (fooo_bar): Call mumble.
	...
	* foo.c (fooo_bar): New function

with

	* foo.c (fooo_bar): New function

since (from the point of view of the trunk) the whole
thing is new.

Re: merging etc

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     I tend to believe the opposite: the description of small changes are easier
  >     to understand than description of combined changes.
  > 
  > The usual simplification is to replace
  > 
  >         * foo.c (fooo_bar): Call mumble.
  > 	...
  > 	* foo.c (fooo_bar): New function
  > 
  > with
  > 
  > 	* foo.c (fooo_bar): New function
  > 
  > since (from the point of view of the trunk) the whole
  > thing is new.

Can you please clarify, is crunching the log a blocker for the merge?
Or can the merge proceed, add the logs with the dates changed to the
date of the merge, and add an entry in FOR-RELEASE that the logs need
to be processed?

Re: merging etc

[Glenn Morris]

Dan Nicolaescu wrote:

> Can you please clarify, is crunching the log a blocker for the merge?

I would expect that it is, because rms will want the "tidy" logs used
for the CVS log entries for the merge.

Re: merging etc

[Richard Stallman]

    Can you please clarify, is crunching the log a blocker for the merge?

Yes, because that is needed to make sure it really gets done.  If I
approved doing the merge first, followed by simplifying the change
logs, I expect people would not do the simplification, just as they
are not fixing the Emacs 22 bugs.

Re: merging etc

[Richard Stallman]

    Richard also said he wants the multi-tty changelogs "crunched" before
    merging -- i.e., essentially replacing many historical entries for a
    given function/variable by a single entry for it with all the changes
    (or in the case of a new function/variable, all entries for it except
    "New function/variable" can be dropped entirely).  I'm not sure how
    this is supposed to work for multiple authors changing the same
    function.... (one changelog entry per author?).

That is one way to do it.

    That seems like a daunting task given the size of the logs though...

I think that anyone here could do it in a few hours.
But it doesn't have to be done all by one person.

How about checking in a copy of the whole change log
(since the branch was forked) in a separate file in each directory?
That way, various people can contribute to simplifying it.

Re: merging etc

[Glenn Morris]

"Miles Bader" wrote:

> Ok, I've put all the changelog info from the arch logs into
> "ChangeLog.multi-tty" files in the various emacs directories (on the
> multi-tty branch).  I split the entries by directory and generally
> cleaned up the text.

People won't want to hear this, but these ChangeLogs are not very
good, IMO. This reflects the original logs, not the way they were
combined, I should imagine.

Eg I'm looking at the one for lib-src now, trying to clean it up. Many
of the changes between the trunk and multi-tty are either not
documented, or are not documented very cleanly. I'm finding it
necessary to look at the diff between trunk and multi-tty to construct
a proper log. Perhaps I have just found a bad example though.

Re: merging etc

[Glenn Morris]

Glenn Morris wrote:

> People won't want to hear this, but these ChangeLogs are not very
> good, IMO.

I have to go further: the lib-src/ChangeLog.multi-tty was bloody
awful. I fixed it up as best I can, but with very little understanding
of the code it was not easy and can do doubt be improved upon. Many
change were totally undocumented, so I have no idea who made them.

multi-tty developers: please improve this. I don't think it will take
too long for those of you who are familiar with the code.

Re: merging etc

[Richard Stallman]

Thanks for starting to work on the change logs for multi-tty.

    I have to go further: the lib-src/ChangeLog.multi-tty was bloody
    awful. I fixed it up as best I can, but with very little understanding
    of the code it was not easy and can do doubt be improved upon. Many
    change were totally undocumented, so I have no idea who made them.

    multi-tty developers: please improve this. I don't think it will take
    too long for those of you who are familiar with the code.

It is a good thing you examined them, so that we know they are
incomplete.  If I had told people to just go ahead and merge them
without paying attention to this, we would not have noticed that
these changes were not properly documented in the change logs.

Re: merging etc

[Richard Stallman]

    Eg I'm looking at the one for lib-src now, trying to clean it up. Many
    of the changes between the trunk and multi-tty are either not
    documented, or are not documented very cleanly. I'm finding it
    necessary to look at the diff between trunk and multi-tty to construct
    a proper log. Perhaps I have just found a bad example though.

I am surprised that multi-tty required changes in lib-src.
Why was that?

Re: merging etc

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     Eg I'm looking at the one for lib-src now, trying to clean it up. Many
  >     of the changes between the trunk and multi-tty are either not
  >     documented, or are not documented very cleanly. I'm finding it
  >     necessary to look at the diff between trunk and multi-tty to construct
  >     a proper log. Perhaps I have just found a bad example though.
  > 
  > I am surprised that multi-tty required changes in lib-src.
  > Why was that?

For fundamental reasons: emacsclient.c needed to be updated to deal
with ttys and handling multiple terminals.

Re: merging etc

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > "Miles Bader" wrote:
  > 
  > > Ok, I've put all the changelog info from the arch logs into
  > > "ChangeLog.multi-tty" files in the various emacs directories (on the
  > > multi-tty branch).  I split the entries by directory and generally
  > > cleaned up the text.
  > 
  > Eg I'm looking at the one for lib-src now, trying to clean it up. Many

I am working on lisp/ChangeLog.multi-tty, I will check it in when it
is done. 

>From the looks of it, only src/ChangeLog.multi-tty is left.

Re: merging etc

[Juanma Barranquero]

On 8/29/07, Miles Bader <miles@gnu.org> wrote:

> No doubt some things have broken as a result (I haven't tested it).

Ctrl-Z => "Suspending an Emacs running under W32 makes no sense"

Gee, Emacs, thanks, I *know*... that's why it used to run
iconify-or-deiconify-frame :)

Also, I'm seeing a redisplay bug where part of an inactive modeline is
left over the fringe after killing the window.

        Juanma

Re: merging etc

[Juanma Barranquero]

I'm still getting this redisplay bug on Windows. I think it first
appeared just after the multi-tty merge.

On 8/29/07, Juanma Barranquero <lekktu@gmail.com> wrote:

> Also, I'm seeing a redisplay bug where part of an inactive modeline is
> left over the fringe after killing the window.

A simple recipe:

-------- .emacs --------
(setq default-indicate-empty-lines t)
------------------------

C:\> emacs

C-x b [RET]     ; so we are in *scratch*
C-x 2 C-x 0

             Juanma

Re: merging etc

[Jason Rumney]

Juanma Barranquero wrote:
> I'm still getting this redisplay bug on Windows. I think it first
> appeared just after the multi-tty merge.
>
> On 8/29/07, Juanma Barranquero <lekktu@gmail.com> wrote:
>
>   
>> Also, I'm seeing a redisplay bug where part of an inactive modeline is
>> left over the fringe after killing the window.
>>     

The fringe seems to not display any of the bitmaps it should, and seems
to not clear properly when there should be a bitmap displayed in that
part of the fringe. Can anyone with a recent CVS build on other
platforms confirm that the fringe is working properly there so we know
whether to focus our search on w32 specific or shared code.

There have recently been a few reorganizations of the etc folder - could
this have affected the bitmaps that are displayed in the fringe (they
used to be defined in the src, but did they get moved to external files
at some stage, which have now moved?)

Re: merging etc

[Glenn Morris]

Jason Rumney wrote:

> The fringe seems to not display any of the bitmaps it should, and
> seems to not clear properly when there should be a bitmap displayed
> in that part of the fringe. Can anyone with a recent CVS build on
> other platforms confirm that the fringe is working properly there so
> we know whether to focus our search on w32 specific or shared code.

Seems to work fine for me on GNU/Linux.

(setq default-indicate-buffer-boundaries 'left)  works
(setq overflow-newline-into-fringe t)            works

> There have recently been a few reorganizations of the etc folder -
> could this have affected the bitmaps that are displayed in the
> fringe (they used to be defined in the src, but did they get moved
> to external files at some stage, which have now moved?)

The moving around was mostly my doing. I don't think I moved anything
relevant to the fringe. The bitmaps are still defined in fringe.c
AFAICS.

Re: merging etc

[Romain Francoise]

"Miles Bader" <miles@gnu.org> writes:

> Ok, the multi-tty branch has been merged into the trunk.

Thank you!

Re: merging etc

[Leo]

On 2007-08-29 17:12 +0100, Romain Francoise wrote:
> "Miles Bader" <miles@gnu.org> writes:
>
>> Ok, the multi-tty branch has been merged into the trunk.
>
> Thank you!

Many thanks. This is the biggest leap after the release of 22.1.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

         Gnus is one component of the Emacs operating system.

Re: merging etc

[Richard Stallman]

    Ok, the multi-tty branch has been merged into the trunk.

What about documentation?  I don't see any changes in NEWS.
I assumed, because you thought the branch was ready to merge,
that it had the appropriate documentation.

We cannot proceed with development without documentation of these new
features.  Would you please provide the detailed information
on new Lisp-level interfaces?

Re: merging etc

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     Ok, the multi-tty branch has been merged into the trunk.
>
> What about documentation?  I don't see any changes in NEWS.
> I assumed, because you thought the branch was ready to merge,
> that it had the appropriate documentation.

Just to get things started, here is a tentative NEWS entry:

** Emacs now supports several simultaneous display devices.
Emacs can now handle frames on several different X displays and
terminals simultaneously. Emacsclient has also been extendend to allow
specification on which display to use.

>
> We cannot proceed with development without documentation of these new
> features.  Would you please provide the detailed information
> on new Lisp-level interfaces?

-- 
Joakim Verona

Re: merging etc

[Stefan Monnier]

> Just to get things started, here is a tentative NEWS entry:

> ** Emacs now supports several simultaneous display devices.
> Emacs can now handle frames on several different X displays and
> terminals simultaneously. Emacsclient has also been extendend to allow
> specification on which display to use.

That's the Emacs-level documentation.  We need the Lisp-level doc as well.


        Stefan

Re: merging etc

[David Kastrup]

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

>> Just to get things started, here is a tentative NEWS entry:
>
>> ** Emacs now supports several simultaneous display devices.
>> Emacs can now handle frames on several different X displays and
>> terminals simultaneously. Emacsclient has also been extendend to allow
>> specification on which display to use.
>
> That's the Emacs-level documentation.

It is?  We don't need to document that environment variables suddenly
are session-specific, we don't need to document the relation of
sessions to frames to terminals and so on?  That some stuff has become
frame-local, too?

I think that some of those details would better be solved in a
different way, but it is not easy to do or judge that if the current
choices are not really documented with their user-relevant
consequences.

> We need the Lisp-level doc as well.

That too.  But for discussing and/or cleaning the implications of the
design, the consequences for the user are of foremost interest, I
think.  If we can't explain the consequences for the user concisely
and understandably, there is a problem with the design.

So that is the kind of documentation I would want to see first.  If
the user-visible consequences are easy to understand and consistent,
the documentation for _that_ can stay, and the Lisp level can then try
to follow.

-- 
David Kastrup

Re: merging etc

[joakim]

David Kastrup <dak@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Just to get things started, here is a tentative NEWS entry:
>>
>>> ** Emacs now supports several simultaneous display devices.
>>> Emacs can now handle frames on several different X displays and
>>> terminals simultaneously. Emacsclient has also been extendend to allow
>>> specification on which display to use.
>>
>> That's the Emacs-level documentation.
>
> It is?  We don't need to document that environment variables suddenly
> are session-specific, we don't need to document the relation of
> sessions to frames to terminals and so on?  That some stuff has become
> frame-local, too?

Is that sort of thing normaly documented in NEWS? I thought the
purpose of NEWS was to be a somewhat terse overview?

> I think that some of those details would better be solved in a
> different way, but it is not easy to do or judge that if the current
> choices are not really documented with their user-relevant
> consequences.
>
>> We need the Lisp-level doc as well.
>
> That too.  But for discussing and/or cleaning the implications of the
> design, the consequences for the user are of foremost interest, I
> think.  If we can't explain the consequences for the user concisely
> and understandably, there is a problem with the design.
>
> So that is the kind of documentation I would want to see first.  If
> the user-visible consequences are easy to understand and consistent,
> the documentation for _that_ can stay, and the Lisp level can then try
> to follow.
>
> -- 
> David Kastrup

-- 
Joakim Verona

Re: merging etc

[Stefan Monnier]

> Is that sort of thing normaly documented in NEWS? I thought the
> purpose of NEWS was to be a somewhat terse overview?

It depends.  Usually, the NEWS entries are terse indeed, enough for the user
to have some idea of what's going on and where to find the rest of the info
if needed.

In a case such as the multi-tty patches, an important part is the *change*
more than the end result: the Emacs and Elisp manuals need to be updated to
reflect the resulting behavior, but the NEWS file might need to contain
non-trivial descriptions of how things changed.


        Stefan

Re: merging etc

[Richard Stallman]

    Is that sort of thing normaly documented in NEWS? I thought the
    purpose of NEWS was to be a somewhat terse overview?

If I am going to update the manual based on NEWS, NEWS has to contain
all the information I need in order to do this.  At least for now.
We could delete some of it later.

If someone else updates the manual now, so it need not be done from
NEWS, then a more terse entry in NEWS would be adequate.

Re: merging etc

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 30 Aug 2007 08:37:33 -0400
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > Just to get things started, here is a tentative NEWS entry:
> 
> > ** Emacs now supports several simultaneous display devices.
> > Emacs can now handle frames on several different X displays and
> > terminals simultaneously. Emacsclient has also been extendend to allow
> > specification on which display to use.
> 
> That's the Emacs-level documentation.

Actually, it isn't even that.  It's basically an announcement of a new
feature without any details, and as such, it's almost useless.

Joakim, please take a moment to browse through NEWS entries.  For each
new feature, they mention at least the most important user commands
and variables, and any other auxiliary info, like environment
variables, that are necessary to at least turn on/off the feature and
control its behavior in some basic ways.

In CVS, this kind of documentation serves yet another purpose: it is a
reminder to update the manual with the expanded version of the
documentation.  Without such a reminder, chances are we will forget to
update the manual when the time comes to release Emacs.

If neither the manual nor NEWS have some information about a new
feature (and a major feature such as multi-tty), that feature does not
exist for all practical purposes, since no one will be able to use it
without prolonged study of the sources.  Please have a mercy on us!