Upcoming 23.1 release

Upcoming 23.1 release

[Chong Yidong]

As mentioned earlier, the 23.1 release is currently scheduled for this
Wednesday.

There are a couple of problems which probably can't be fixed without
destabilizing the branch and significantly delaying the release.  These
are (i) the rmail auto-save issue, (ii) a bug in vertical-motion
involving continued a particular combination of tab characters
(Bug#3879), and (iii) the remaining issues with the Cocoa port.  I think
it's OK to leave these for 23.2.  If anyone has objections to these or
other issues, now is the time to raise them.

Re: Upcoming 23.1 release

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 20 Jul 2009 14:32:18 -0400
> 
> As mentioned earlier, the 23.1 release is currently scheduled for this
> Wednesday.
> 
> There are a couple of problems which probably can't be fixed without
> destabilizing the branch and significantly delaying the release.  These
> are (i) the rmail auto-save issue, (ii) a bug in vertical-motion
> involving continued a particular combination of tab characters
> (Bug#3879), and (iii) the remaining issues with the Cocoa port.  I think
> it's OK to leave these for 23.2.  If anyone has objections to these or
> other issues, now is the time to raise them.

In Emacs 22.3, if one turns on auto-save in the Rmail buffer, would
Emacs DTRT?  If so, I'd suggest to try to fix this before the
release.  If it didn't DTRT in Emacs 22.3, I'm okay with postponing
the fix.

How complex is the fix proposed by Richard, and why do you think
installing it on could destabilize the branch?  Can you show the diffs
here?

Re: Upcoming 23.1 release

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> In Emacs 22.3, if one turns on auto-save in the Rmail buffer, would
> Emacs DTRT?  If so, I'd suggest to try to fix this before the
> release.  If it didn't DTRT in Emacs 22.3, I'm okay with postponing
> the fix.
>
> How complex is the fix proposed by Richard, and why do you think
> installing it on could destabilize the branch?  Can you show the diffs
> here?

The fix proposed by Richard involves changing an undocumented behavior
of buffer-saved-size.  Previously, the documentation said that a value
of -1 has a certain behavior, but actully any negative number does the
same thing as -1; this patch changes things to treat -2 specially.  We
can't install this without a significant amount of testing to see if
this breaks anything.


*** fileio.c	7 Jul 2009 22:52:59 -0000	1.655
--- fileio.c	16 Jul 2009 01:45:11 -0000	1.656
***************
*** 4492,4498 ****
        if (visiting)
  	{
  	  SAVE_MODIFF = MODIFF;
! 	  XSETFASTINT (current_buffer->save_length, Z - BEG);
  	  current_buffer->filename = visit_file;
  	}
        UNGCPRO;
--- 4492,4499 ----
        if (visiting)
  	{
  	  SAVE_MODIFF = MODIFF;
! 	  if (XINT (current_buffer->save_length) != -2)
! 	    XSETFASTINT (current_buffer->save_length, Z - BEG);
  	  current_buffer->filename = visit_file;
  	}
        UNGCPRO;
***************
*** 4703,4709 ****
    if (visiting)
      {
        SAVE_MODIFF = MODIFF;
!       XSETFASTINT (current_buffer->save_length, Z - BEG);
        current_buffer->filename = visit_file;
        update_mode_lines++;
      }
--- 4704,4711 ----
    if (visiting)
      {
        SAVE_MODIFF = MODIFF;
!       if (XINT (current_buffer->save_length) != -2)
! 	XSETFASTINT (current_buffer->save_length, Z - BEG);
        current_buffer->filename = visit_file;
        update_mode_lines++;
      }
***************
*** 5307,5313 ****
  	    && BUF_SAVE_MODIFF (b) < BUF_MODIFF (b)
  	    && b->auto_save_modified < BUF_MODIFF (b)
  	    /* -1 means we've turned off autosaving for a while--see below.  */
! 	    && XINT (b->save_length) >= 0
  	    && (do_handled_files
  		|| NILP (Ffind_file_name_handler (b->auto_save_file_name,
  						  Qwrite_region))))
--- 5309,5315 ----
  	    && BUF_SAVE_MODIFF (b) < BUF_MODIFF (b)
  	    && b->auto_save_modified < BUF_MODIFF (b)
  	    /* -1 means we've turned off autosaving for a while--see below.  */
! 	    && XINT (b->save_length) != -1
  	    && (do_handled_files
  		|| NILP (Ffind_file_name_handler (b->auto_save_file_name,
  						  Qwrite_region))))
***************
*** 5321,5328 ****
  		&& EMACS_SECS (before_time) - b->auto_save_failure_time < 1200)
  	      continue;
  
! 	    if ((XFASTINT (b->save_length) * 10
! 		 > (BUF_Z (b) - BUF_BEG (b)) * 13)
  		/* A short file is likely to change a large fraction;
  		   spare the user annoying messages.  */
  		&& XFASTINT (b->save_length) > 5000
--- 5323,5332 ----
  		&& EMACS_SECS (before_time) - b->auto_save_failure_time < 1200)
  	      continue;
  
! 	    if (XINT (b->save_length) != -2
! 		/* -2 is a magic flag turning off this feature in a buffer.  */
! 		&& (XFASTINT (b->save_length) * 10
! 		    > (BUF_Z (b) - BUF_BEG (b)) * 13)
  		/* A short file is likely to change a large fraction;
  		   spare the user annoying messages.  */
  		&& XFASTINT (b->save_length) > 5000
***************
*** 5347,5353 ****
  	    internal_condition_case (auto_save_1, Qt, auto_save_error);
  	    auto_saved++;
  	    b->auto_save_modified = BUF_MODIFF (b);
! 	    XSETFASTINT (current_buffer->save_length, Z - BEG);
  	    set_buffer_internal (old);
  
  	    EMACS_GET_TIME (after_time);
--- 5351,5358 ----
  	    internal_condition_case (auto_save_1, Qt, auto_save_error);
  	    auto_saved++;
  	    b->auto_save_modified = BUF_MODIFF (b);
! 	    if (XINT (current_buffer->save_length) != -2)
! 	      XSETFASTINT (current_buffer->save_length, Z - BEG);
  	    set_buffer_internal (old);
  
  	    EMACS_GET_TIME (after_time);
***************
*** 5392,5398 ****
       ()
  {
    current_buffer->auto_save_modified = MODIFF;
!   XSETFASTINT (current_buffer->save_length, Z - BEG);
    current_buffer->auto_save_failure_time = -1;
    return Qnil;
  }
--- 5397,5404 ----
       ()
  {
    current_buffer->auto_save_modified = MODIFF;
!   if (XINT (current_buffer->save_length) != -2)
!     XSETFASTINT (current_buffer->save_length, Z - BEG);
    current_buffer->auto_save_failure_time = -1;
    return Qnil;
  }
*** files.el	5 Jul 2009 22:15:37 -0000	1.1055
--- files.el	16 Jul 2009 01:52:36 -0000	1.1056
***************
*** 4996,5002 ****
  	       (make-auto-save-file-name))))
    ;; If -1 was stored here, to temporarily turn off saving,
    ;; turn it back on.
!   (and (< buffer-saved-size 0)
         (setq buffer-saved-size 0))
    (if (interactive-p)
        (message "Auto-save %s (in this buffer)"
--- 4996,5002 ----
  	       (make-auto-save-file-name))))
    ;; If -1 was stored here, to temporarily turn off saving,
    ;; turn it back on.
!   (and (= buffer-saved-size -1)
         (setq buffer-saved-size 0))
    (if (interactive-p)
        (message "Auto-save %s (in this buffer)"
*** rmail.el	18 May 2009 16:27:00 -0000	1.535
--- rmail.el	16 Jul 2009 01:52:36 -0000	1.536
***************
*** 371,377 ****
    :group 'rmail-headers)
  
  ;;;###autoload
! (defcustom rmail-retry-ignored-headers "^x-authentication-warning:\\|content-type:\\|content-transfer-encoding:\\|mime-version:"
    "Headers that should be stripped when retrying a failed message."
    :type '(choice regexp (const nil :tag "None"))
    :group 'rmail-headers
--- 371,377 ----
    :group 'rmail-headers)
  
  ;;;###autoload
! (defcustom rmail-retry-ignored-headers "^x-authentication-warning:\\|^x-detected-operating-system:\\|^x-spam[-a-z]*:\\|content-type:\\|content-transfer-encoding:\\|mime-version:"
    "Headers that should be stripped when retrying a failed message."
    :type '(choice regexp (const nil :tag "None"))
    :group 'rmail-headers
***************
*** 1410,1415 ****
--- 1410,1418 ----
    ;; Don't let a local variables list in a message cause confusion.
    (make-local-variable 'local-enable-local-variables)
    (setq local-enable-local-variables nil)
+   ;; Don't turn off auto-saving based on the size of the buffer
+   ;; because that code does not understand buffer-swapping.
+   (setq buffer-saved-size -2)
    (make-local-variable 'revert-buffer-function)
    (setq revert-buffer-function 'rmail-revert)
    (make-local-variable 'font-lock-defaults)

Re: Upcoming 23.1 release

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 20 Jul 2009 14:51:21 -0400
> 
> The fix proposed by Richard involves changing an undocumented behavior
> of buffer-saved-size.  Previously, the documentation said that a value
> of -1 has a certain behavior, but actully any negative number does the
> same thing as -1; this patch changes things to treat -2 specially.  We
> can't install this without a significant amount of testing to see if
> this breaks anything.

Can't we have a magically-named buffer-local variable for the same
effect in fileio.c?  Then previous behavior would be left untouched,
and we won't need that much testing, as only Rmail would be affected.

Re: Upcoming 23.1 release

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Can't we have a magically-named buffer-local variable for the same
> effect in fileio.c?  Then previous behavior would be left untouched,
> and we won't need that much testing, as only Rmail would be affected.

This approach seems wrong anyhow.  Firstly, it prevents Emacs from
disabling auto-saving due to big changes in the file, which could be
either due to buffer swapping or actual changes---and the latter case
can lead to data loss anyway.  Secondly, because of Rmail-mbox's funky
buffer-swapping design, it's not even clear to me that turning on
auto-save-mode manually in Rmail leads to the correct buffer being
auto-saved.

I think the correct fix is to change `buffer-swap-text', giving it an
optional argument that makes it swap the two buffers' values of
auto-save-file-name and auto_save_modified (and possibly other
file-related variables also).  And we need an additional hook into
auto-save-mode that Rmail can use to ensure that M-x auto-save-mode
turns on auto-save in the correct buffer.

Re: Upcoming 23.1 release

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 20 Jul 2009 15:37:37 -0400
> 
> I think the correct fix is to change `buffer-swap-text', giving it an
> optional argument that makes it swap the two buffers' values of
> auto-save-file-name and auto_save_modified (and possibly other
> file-related variables also).  And we need an additional hook into
> auto-save-mode that Rmail can use to ensure that M-x auto-save-mode
> turns on auto-save in the correct buffer.

Since buffer-swap-text is used only in two places in Emacs (AFAIR),
would such a change be safe enough to be included in 23.1?

Re: Upcoming 23.1 release

[Stefan Monnier]

> can lead to data loss anyway.  Secondly, because of Rmail-mbox's funky
> buffer-swapping design, it's not even clear to me that turning on
> auto-save-mode manually in Rmail leads to the correct buffer being
> auto-saved.

AFAIK tar-mode (which also uses the buffer-swapping) support
auto-saving.  So either Rmail can be fixed to work like tar-mode, or
tar-mode suffers from the same problem (unnoticed until now).

> I think the correct fix is to change `buffer-swap-text', giving it an
> optional argument that makes it swap the two buffers' values of
> auto-save-file-name and auto_save_modified (and possibly other
> file-related variables also).

At least in tar-mode, auto-save-file-name doesn't need to be moved to
the data buffer.  But, maybe auto_save_modified and a few other vars
need to be treated more carefully.

> And we need an additional hook into auto-save-mode that Rmail can use
> to ensure that M-x auto-save-mode turns on auto-save in the
> correct buffer.

That sounds to me like it's going in the wrong direction.


        Stefan

Re: Upcoming 23.1 release

[Chong Yidong]

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

> AFAIK tar-mode (which also uses the buffer-swapping) support
> auto-saving.  So either Rmail can be fixed to work like tar-mode, or
> tar-mode suffers from the same problem (unnoticed until now).

I think tar-mode also turns off auto-save-mode by default:

(defun tar-subfile-mode (p)
  ...
  (cond (tar-subfile-mode
	 (add-hook 'write-file-functions 'tar-subfile-save-buffer nil t)
	 ;; turn off auto-save.
	 (auto-save-mode -1)

Re: Upcoming 23.1 release

[Stefan Monnier]

>> AFAIK tar-mode (which also uses the buffer-swapping) support
>> auto-saving.  So either Rmail can be fixed to work like tar-mode, or
>> tar-mode suffers from the same problem (unnoticed until now).

> I think tar-mode also turns off auto-save-mode by default:

> (defun tar-subfile-mode (p)
>   ...
>   (cond (tar-subfile-mode
> 	 (add-hook 'write-file-functions 'tar-subfile-save-buffer nil t)
> 	 ;; turn off auto-save.
> 	 (auto-save-mode -1)

That's for the subfiles (i.e. the buffers showing one of the member of
the archive), not for the tar-mode buffer.


        Stefan

Re: Upcoming 23.1 release

[Richard Stallman]

      Secondly, because of Rmail-mbox's funky
    buffer-swapping design, it's not even clear to me that turning on
    auto-save-mode manually in Rmail leads to the correct buffer being
    auto-saved.

The same hook that does it for real saves
runs in this case too.

I just tested it again.  It took just 30 seconds to do M-x
auto-save-mode followed by running (do-auto-save).  However, I kept
editing and I saw that it kept saving the whole file.

I just found and fixed a bug in my change: auto-save-mode did not
toggle the mode off in an Rmail file.  But even if that had not been
fixed, it is less severe than the bug now planned for 23.1.

    I think the correct fix is to change `buffer-swap-text', giving it an
    optional argument that makes it swap the two buffers' values of
    auto-save-file-name and auto_save_modified (and possibly other
    file-related variables also).  And we need an additional hook into
    auto-save-mode that Rmail can use to ensure that M-x auto-save-mode
    turns on auto-save in the correct buffer.

That approach might work too.  But we have a fix that works, and is
much simpler.  It is better to use this, and fix the bug.

Re: Upcoming 23.1 release

[Richard Stallman]

    The fix proposed by Richard involves changing an undocumented behavior
    of buffer-saved-size.  Previously, the documentation said that a value
    of -1 has a certain behavior, but actully any negative number does the
    same thing as -1; this patch changes things to treat -2 specially.  We
    can't install this without a significant amount of testing to see if
    this breaks anything.

Until I made this change, negative values other than -1 were never
used.   Imaginary problems in hypothetical nonexistent code should not
stop us from fixing a real bug in a real case.

The rules we make for how to do maintenance are not sacred.
They exist for the sake of making a better release.

rmail-output turns on auto-save mode in an Rmail buffer when it outputs
a message into that buffer.  This is important because the user is very
likely to delete the message from the buffer it was previously in,
and he might easily save that buffer without saving the other one.
Then the message will be in no file, and could get lost.

This feature fails to do its job if auto-save mode turns itself off
because the text in the Rmail buffer is short.

Please install the fix.

Re: Upcoming 23.1 release

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Until I made this change, negative values other than -1 were never
> used.   Imaginary problems in hypothetical nonexistent code should not
> stop us from fixing a real bug in a real case.
>
> The rules we make for how to do maintenance are not sacred.
> They exist for the sake of making a better release.

That doesn't excuse making sloppy changes.  If necessary, we'll
introduce a new variable that states whether or not auto-save should be
disabled when the buffer size shrinks.  But first, I need to figure out
whether this is even enough---as I just mentioned in a reply to Eli,
this change still fails to handle auto-saving in rmail-edit.

Re: Upcoming 23.1 release

[Richard Stallman]

    That doesn't excuse making sloppy changes.  If necessary, we'll
    introduce a new variable that states whether or not auto-save should be
    disabled when the buffer size shrinks.

You have no justification for calling my fix sloppy, but by all means
fix it some other way if you like.

Re: Upcoming 23.1 release

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> In Emacs 22.3, if one turns on auto-save in the Rmail buffer, would
> Emacs DTRT?  If so, I'd suggest to try to fix this before the
> release.  If it didn't DTRT in Emacs 22.3, I'm okay with postponing
> the fix.

BTW.  I don't know how to reproduce the bug (i.e. turning off of
auto-save) in Emacs 23.  Do you?

Re: Upcoming 23.1 release

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 20 Jul 2009 15:02:16 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In Emacs 22.3, if one turns on auto-save in the Rmail buffer, would
> > Emacs DTRT?  If so, I'd suggest to try to fix this before the
> > release.  If it didn't DTRT in Emacs 22.3, I'm okay with postponing
> > the fix.
> 
> BTW.  I don't know how to reproduce the bug (i.e. turning off of
> auto-save) in Emacs 23.  Do you?

Yes:

   C-u M-x rmail RET SOME-mbox-FILE RET
   e
   M-x auto-save-mode
   <make some edits>

After that, wait for auto-save-timeout seconds, and you will see the
bug.  (It could be that you need a sufficiently large mbox file, to
trigger this.)

Re: Upcoming 23.1 release

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>    C-u M-x rmail RET SOME-mbox-FILE RET
>    e
>    M-x auto-save-mode
>    <make some edits>
>
> After that, wait for auto-save-timeout seconds, and you will see the
> bug.  (It could be that you need a sufficiently large mbox file, to
> trigger this.)

OK, this I can reproduce.

With Richard's changes, the auxilliary buffer containing the mbox data
is auto-saved, but this buffer does *not* contain the text that's being
edited in the RMAIL buffer.  So nothing's gained in this case.

To fix this case, the annotation functions might detect that rmail-edit
is in effect, and DTRT so that only the presently edited message is
auto-saved.

But it seems that Richard's concern is with rmail-output, not
rmail-edit.

Re: Upcoming 23.1 release

[Richard Stallman]

    With Richard's changes, the auxilliary buffer containing the mbox data
    is auto-saved, but this buffer does *not* contain the text that's being
    edited in the RMAIL buffer.  So nothing's gained in this case.

That is true.  In the specific case where an auto-save happens while
you are in Rmail-Edit mode, it does not save your edits to the current
message.  Until you finish the edit, those changes are not in the
Rmail buffer.

However, with my fix, at least it correctly saves the Rmail file
itself, instead of clobbering it with the current message.  This
applies to any case where the buffer has been changed.

It would be good, some day, to set up autosaving for the view buffer
during Rmail Edit.  But that's not a bug fix, and I don't suggest we
do it now.

Re: Upcoming 23.1 release

[Richard Stallman]

    > Emacs DTRT?  If so, I'd suggest to try to fix this before the
    > release.  If it didn't DTRT in Emacs 22.3, I'm okay with postponing
    > the fix.

    BTW.  I don't know how to reproduce the bug (i.e. turning off of
    auto-save) in Emacs 23.  Do you?

I cannot tell you an exact recipe.  I just saw that my Rmail buffer
had buffer-saved-size = -1.  This was after I had copied a message
into it into it using rmail-output.

If you turn on auto-save in an large Rmail buffer with many messages
in it, I would guess it will always turn itself off on the first attempt
to auto-save, because the current buffer text (which is just one message)
will always be much smaller than the whole file.

Re: Upcoming 23.1 release

[Richard Stallman]

    In Emacs 22.3, if one turns on auto-save in the Rmail buffer, would
    Emacs DTRT?

There was nothing special about an Rmail buffer
that would make it fail, so it probably worked.

This bug is caused by buffer-swapping, which was not present in Emacs 22.

Re: Upcoming 23.1 release

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > As mentioned earlier, the 23.1 release is currently scheduled for this
  > Wednesday.

A tiny patch that should be harmless (but also probably not very useful
for most people either).  Please feel free to apply it to the branch if
you want to.

This was caught because yesterday there was a bug in dealing with local,
and that variables which disabled the `no-byte-compile'.   
Which just says that `no-byte-compile' is a terrible idea nowadays.


* term/vt420.el (terminal-init-vt420):  Fix typo.

--- vt420.el    22 Oct 2007 11:21:19 -0700      1.7
+++ vt420.el    20 Jul 2009 09:38:52 -0700      
@@ -1,5 +1,4 @@
-;; -*- no-byte-compile: t -*-
-(defun terminal-init-vt420
+(defun terminal-init-vt420 ()
   "Terminal initialization function for vt420."
   (tty-run-terminal-initialization (selected-frame) "vt100")
   ;; Make F11 an escape key.

Re: Upcoming 23.1 release

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> A tiny patch that should be harmless (but also probably not very useful
> for most people either).  Please feel free to apply it to the branch if
> you want to.

I checked in your fix for the typo, thanks.

I didn't remove the no-byte-compile line, though, because I don't
understand the original rationale for it.  Maybe it's because
byte-compiling doesn't provide any advantage for such a small file?

usefulness of no-byte-compile [was: Re: Upcoming 23.1 release]

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > I didn't remove the no-byte-compile line, though, because I don't
  > understand the original rationale for it.  Maybe it's because
  > byte-compiling doesn't provide any advantage for such a small file?

On a modern machine byte-compiling does not really provide too much
visible speedup for quite a lot of elisp code.

The decision not to byte compile some things was taken at a time when it
took a while to byte compile, and storing extra files was not very
desirable.   Nowadays none of those matter at all. 

But byte-compiling has the advantage that warnings help catch potential
problems that are only caught by users at run time.  (And warnings have
caught quite a few issues since we have cleaned up the sources).

So IMNSHO we should reconsider the decision not to byte compile some
things, and just compile everything that is not specifically excepted
(like in loadup.el).

Re: Upcoming 23.1 release

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> As mentioned earlier, the 23.1 release is currently scheduled for this
> Wednesday.

Correction: that should be next Wednesday, the 29th, as my earlier email
said.

Sorry for the confusion :-P

Re: Upcoming 23.1 release

[Jason Rumney]

Chong Yidong wrote:
> (ii) a bug in vertical-motion
> involving continued a particular combination of tab characters
> (Bug#3879),

I'm not sure it is safe to just leave this one. Perhaps changing the 
default of line-move-visual to nil will avoid this bug.  I'm not sure 
that anyone addressed the concerns about this new feature breaking 
macros either.

Re: Upcoming 23.1 release

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

> Chong Yidong wrote:
>> (ii) a bug in vertical-motion
>> involving continued a particular combination of tab characters
>> (Bug#3879),
>
> I'm not sure it is safe to just leave this one. Perhaps changing the
> default of line-move-visual to nil will avoid this bug.  I'm not sure
> that anyone addressed the concerns about this new feature breaking
> macros either.

I'm trying find a safe fix for this.

Re: Upcoming 23.1 release

[Kenichi Handa]

In article <87ws63cij1.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> As mentioned earlier, the 23.1 release is currently scheduled for this
> Wednesday.

> There are a couple of problems which probably can't be fixed without
> destabilizing the branch and significantly delaying the release.  These
> are (i) the rmail auto-save issue, (ii) a bug in vertical-motion
> involving continued a particular combination of tab characters
> (Bug#3879), and (iii) the remaining issues with the Cocoa port.  I think
> it's OK to leave these for 23.2.  If anyone has objections to these or
> other issues, now is the time to raise them.

I've just got a bug report about tar-mode on Windows.
Here's the translation of the report (original in Japanese)

----------------------------------------------------------------------
On Windows, when we edit a tar file in tar-mode, the file is
broken.  It seems that this is because
default-buffer-file-coding-system is japanese-shift-jis-dos,
and thus this eol-conversion takes effect on writing a tar
file.
----------------------------------------------------------------------

At the moment, I'm too busy to verify that report.  But, if
this bug really exists, it should be fixed before the
release, and I believe the fix is not that difficult.

---
Kenichi Handa
handa@m17n.org

Re: Upcoming 23.1 release

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Tue, 21 Jul 2009 09:43:24 +0900
> Cc: ynyaaa@ybb.ne.jp, emacs-devel@gnu.org
> 
> I've just got a bug report about tar-mode on Windows.
> Here's the translation of the report (original in Japanese)
> 
> ----------------------------------------------------------------------
> On Windows, when we edit a tar file in tar-mode, the file is
> broken.  It seems that this is because
> default-buffer-file-coding-system is japanese-shift-jis-dos,
> and thus this eol-conversion takes effect on writing a tar
> file.
> ----------------------------------------------------------------------

On Windows, the value of default-buffer-file-coding-system is always
SOMETHING-dos.  So this fact alone is not the correct explanation,
because tar-mode works for me with iso-latin-1-dos.

Please ask the user to provide a reproducible test case.

Thanks.

Re: Upcoming 23.1 release

[Lennart Borgman]

On Mon, Jul 20, 2009 at 8:32 PM, Chong Yidong<cyd@stupidchicken.com> wrote:
> As mentioned earlier, the 23.1 release is currently scheduled for this
> Wednesday.
>
> There are a couple of problems which probably can't be fixed without
> destabilizing the branch and significantly delaying the release.  These
> are (i) the rmail auto-save issue, (ii) a bug in vertical-motion
> involving continued a particular combination of tab characters
> (Bug#3879), and (iii) the remaining issues with the Cocoa port.  I think
> it's OK to leave these for 23.2.  If anyone has objections to these or
> other issues, now is the time to raise them.


There are some serious problems with frame creation on w32. It can
crash Emacs and things can become unusable.

However most of the times it works, but it might be worth
noting/mention somewhere.

* Some notes about it:
The problems are sometimes very subtle and sometimes it is big
problems. I just saw for example that w32-shell-execture stopped
working so I had to restart Emacs. I probably see these problems
because I am using winsav to restore frames. (To get things working I
closed some frames and restarted Emacs with just one frame opening at
startup.)

I have just been able to reproduce this in a reliable way for one
specific case (for which I filed a bug report), but it happens in
other cases too. Since it often seems to happen with several frames
created at once I wonder if some data structures happen to be shared
without protection then. Just an idea - I do not know the code for
frame creation.

Re: Upcoming 23.1 release

[Yavor Doganov]

Chong Yidong wrote:
> (iii) the remaining issues with the Cocoa port.  I think it's OK to
> leave these for 23.2.

It would be nice if the GNUstep port at least builds (Bug#3652).

Re: Upcoming 23.1 release

[David Reitter]

On Jul 22, 2009, at 7:55 AM, Yavor Doganov wrote:

> Chong Yidong wrote:
>> (iii) the remaining issues with the Cocoa port.  I think it's OK to
>> leave these for 23.2.
>
> It would be nice if the GNUstep port at least builds (Bug#3652).

It would also be nice if any variant of Emacs built on the upcoming  
Mac OS X 10.6 (bug #3708).

Re: Upcoming 23.1 release

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 22 Jul 2009 09:55:41 +0300, Yavor Doganov <yavor@gnu.org> said:

> Chong Yidong wrote:
>> (iii) the remaining issues with the Cocoa port.  I think it's OK to
>> leave these for 23.2.

> It would be nice if the GNUstep port at least builds (Bug#3652).

Does GNUstep provide a meaningful implementation of -[NSFontDescriptor
matchingFontDescriptorsWithMandatoryKeys:]?  According to *1, it seems
to be just a stub and always return nil.

*1: http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/NSFontDescriptor.m?rev=26619&dir_pagestart=100&view=auto

If no versions of GNUstep provide the method effectively, including
the header just for passing compilation doesn't looks faithful.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Upcoming 23.1 release

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 24 Jul 2009 09:46:56 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> Does GNUstep provide a meaningful implementation of
> -[NSFontDescriptor matchingFontDescriptorsWithMandatoryKeys:]?
> According to *1, it seems to be just a stub and always return nil.

Correction: not nil but an empty array.  Anyway it's not a meaningful
result.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Upcoming 23.1 release

[Yavor Doganov]

YAMAMOTO Mitsuharu wrote:
> > Does GNUstep provide a meaningful implementation of
> > -[NSFontDescriptor matchingFontDescriptorsWithMandatoryKeys:]?
> > According to *1, it seems to be just a stub and always return nil.
> 
> Correction: not nil but an empty array.

Yes, you are right.  I filed a bug in the GNUstep tracker just in
case.  I hope it's fixed soon...

> Anyway it's not a meaningful result.

Definitely.  By "at least" I meant that you can at least build
Emacs.app and run it with -nw, which is practially the only way to use
it anyway.

Perhaps it's worth adding a comment in the code like the one below?


--- nsfont.m	24 юли 2009 16:02:17 +0300	1.26.2.3
+++ nsfont.m	24 юли 2009 18:05:49 +0300	
@@ -473,6 +473,10 @@
     if (isMatch)
 	[fkeys removeObject: NSFontFamilyAttribute];
 
+    /* As of 2009-07-24, GNUstep's implementation of
+       -[NSFontDescriptor matchingFontDescriptorsWithMandatoryKeys:]
+       is incomplete and the method always returns an empty array.
+       GNUstep bug: https://savannah.gnu.org/bugs/index.php?27099  */
     matchingDescs = [fdesc matchingFontDescriptorsWithMandatoryKeys: fkeys];
     if (NSFONT_TRACE)
 	NSLog(@"Got desc %@ and found %d matching fonts from it: ", fdesc,

Re: Upcoming 23.1 release

[Adrian Robert]

YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:


> Does GNUstep provide a meaningful implementation of -[NSFontDescriptor
> matchingFontDescriptorsWithMandatoryKeys:]?  According to *1, it seems
> to be just a stub and always return nil.
> 
> *1:
http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/NSFontDescriptor.m?rev=26619&dir_pagestart=100&view=auto

You're right.  Not exactly a stub, but not going to work.  Barring
some sudden efforts by the GNUstep developers we will need to pull
back some portion of the code from the previous implementation
(NSFontManager-based) to support GNUstep.  For now it will return
a fallback font, but the user will not be able to change it.