all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Upcoming 23.1 release
@ 2009-07-20 18:32 Chong Yidong
  2009-07-20 18:44 ` Eli Zaretskii
                   ` (6 more replies)
  0 siblings, 7 replies; 34+ messages in thread
From: Chong Yidong @ 2009-07-20 18:32 UTC (permalink / raw)
  To: emacs-devel

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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:32 Upcoming 23.1 release Chong Yidong
@ 2009-07-20 18:44 ` Eli Zaretskii
  2009-07-20 18:51   ` Chong Yidong
                     ` (2 more replies)
  2009-07-20 18:55 ` Dan Nicolaescu
                   ` (5 subsequent siblings)
  6 siblings, 3 replies; 34+ messages in thread
From: Eli Zaretskii @ 2009-07-20 18:44 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:44 ` Eli Zaretskii
@ 2009-07-20 18:51   ` Chong Yidong
  2009-07-20 19:06     ` Eli Zaretskii
  2009-07-21 14:41     ` Richard Stallman
  2009-07-20 19:02   ` Chong Yidong
  2009-07-21 14:41   ` Richard Stallman
  2 siblings, 2 replies; 34+ messages in thread
From: Chong Yidong @ 2009-07-20 18:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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)




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:32 Upcoming 23.1 release Chong Yidong
  2009-07-20 18:44 ` Eli Zaretskii
@ 2009-07-20 18:55 ` Dan Nicolaescu
  2009-07-20 19:06   ` Chong Yidong
  2009-07-20 20:05 ` Upcoming 23.1 release Chong Yidong
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 34+ messages in thread
From: Dan Nicolaescu @ 2009-07-20 18:55 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:44 ` Eli Zaretskii
  2009-07-20 18:51   ` Chong Yidong
@ 2009-07-20 19:02   ` Chong Yidong
  2009-07-20 20:42     ` Eli Zaretskii
  2009-07-21 14:42     ` Richard Stallman
  2009-07-21 14:41   ` Richard Stallman
  2 siblings, 2 replies; 34+ messages in thread
From: Chong Yidong @ 2009-07-20 19:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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?




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:51   ` Chong Yidong
@ 2009-07-20 19:06     ` Eli Zaretskii
  2009-07-20 19:37       ` Chong Yidong
  2009-07-21 14:41     ` Richard Stallman
  1 sibling, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-07-20 19:06 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:55 ` Dan Nicolaescu
@ 2009-07-20 19:06   ` Chong Yidong
  2009-07-21  3:16     ` usefulness of no-byte-compile [was: Re: Upcoming 23.1 release] Dan Nicolaescu
  0 siblings, 1 reply; 34+ messages in thread
From: Chong Yidong @ 2009-07-20 19:06 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

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?




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 19:06     ` Eli Zaretskii
@ 2009-07-20 19:37       ` Chong Yidong
  2009-07-20 20:36         ` Eli Zaretskii
                           ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: Chong Yidong @ 2009-07-20 19:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:32 Upcoming 23.1 release Chong Yidong
  2009-07-20 18:44 ` Eli Zaretskii
  2009-07-20 18:55 ` Dan Nicolaescu
@ 2009-07-20 20:05 ` Chong Yidong
  2009-07-20 22:58 ` Jason Rumney
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 34+ messages in thread
From: Chong Yidong @ 2009-07-20 20:05 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 19:37       ` Chong Yidong
@ 2009-07-20 20:36         ` Eli Zaretskii
  2009-07-21  1:20         ` Stefan Monnier
  2009-07-21 14:41         ` Richard Stallman
  2 siblings, 0 replies; 34+ messages in thread
From: Eli Zaretskii @ 2009-07-20 20:36 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 19:02   ` Chong Yidong
@ 2009-07-20 20:42     ` Eli Zaretskii
  2009-07-21 15:31       ` Chong Yidong
  2009-07-21 14:42     ` Richard Stallman
  1 sibling, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-07-20 20:42 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:32 Upcoming 23.1 release Chong Yidong
                   ` (2 preceding siblings ...)
  2009-07-20 20:05 ` Upcoming 23.1 release Chong Yidong
@ 2009-07-20 22:58 ` Jason Rumney
  2009-07-20 23:12   ` Chong Yidong
  2009-07-21  0:43 ` Kenichi Handa
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 34+ messages in thread
From: Jason Rumney @ 2009-07-20 22:58 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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.





^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 22:58 ` Jason Rumney
@ 2009-07-20 23:12   ` Chong Yidong
  0 siblings, 0 replies; 34+ messages in thread
From: Chong Yidong @ 2009-07-20 23:12 UTC (permalink / raw)
  To: Jason Rumney; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:32 Upcoming 23.1 release Chong Yidong
                   ` (3 preceding siblings ...)
  2009-07-20 22:58 ` Jason Rumney
@ 2009-07-21  0:43 ` Kenichi Handa
  2009-07-21  3:10   ` Eli Zaretskii
  2009-07-21  3:55 ` Lennart Borgman
  2009-07-22  6:55 ` Yavor Doganov
  6 siblings, 1 reply; 34+ messages in thread
From: Kenichi Handa @ 2009-07-21  0:43 UTC (permalink / raw)
  To: Chong Yidong; +Cc: ynyaaa, emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 19:37       ` Chong Yidong
  2009-07-20 20:36         ` Eli Zaretskii
@ 2009-07-21  1:20         ` Stefan Monnier
  2009-07-21 15:05           ` Chong Yidong
  2009-07-21 14:41         ` Richard Stallman
  2 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2009-07-21  1:20 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel

> 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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-21  0:43 ` Kenichi Handa
@ 2009-07-21  3:10   ` Eli Zaretskii
  0 siblings, 0 replies; 34+ messages in thread
From: Eli Zaretskii @ 2009-07-21  3:10 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: cyd, ynyaaa, emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* usefulness of no-byte-compile [was: Re: Upcoming 23.1 release]
  2009-07-20 19:06   ` Chong Yidong
@ 2009-07-21  3:16     ` Dan Nicolaescu
  0 siblings, 0 replies; 34+ messages in thread
From: Dan Nicolaescu @ 2009-07-21  3:16 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:32 Upcoming 23.1 release Chong Yidong
                   ` (4 preceding siblings ...)
  2009-07-21  0:43 ` Kenichi Handa
@ 2009-07-21  3:55 ` Lennart Borgman
  2009-07-22  6:55 ` Yavor Doganov
  6 siblings, 0 replies; 34+ messages in thread
From: Lennart Borgman @ 2009-07-21  3:55 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:51   ` Chong Yidong
  2009-07-20 19:06     ` Eli Zaretskii
@ 2009-07-21 14:41     ` Richard Stallman
  2009-07-21 15:38       ` Chong Yidong
  1 sibling, 1 reply; 34+ messages in thread
From: Richard Stallman @ 2009-07-21 14:41 UTC (permalink / raw)
  To: Chong Yidong; +Cc: eliz, emacs-devel

    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.





^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 19:37       ` Chong Yidong
  2009-07-20 20:36         ` Eli Zaretskii
  2009-07-21  1:20         ` Stefan Monnier
@ 2009-07-21 14:41         ` Richard Stallman
  2 siblings, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2009-07-21 14:41 UTC (permalink / raw)
  To: Chong Yidong; +Cc: eliz, emacs-devel

      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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:44 ` Eli Zaretskii
  2009-07-20 18:51   ` Chong Yidong
  2009-07-20 19:02   ` Chong Yidong
@ 2009-07-21 14:41   ` Richard Stallman
  2 siblings, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2009-07-21 14:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: cyd, emacs-devel

    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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 19:02   ` Chong Yidong
  2009-07-20 20:42     ` Eli Zaretskii
@ 2009-07-21 14:42     ` Richard Stallman
  1 sibling, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2009-07-21 14:42 UTC (permalink / raw)
  To: Chong Yidong; +Cc: eliz, emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-21  1:20         ` Stefan Monnier
@ 2009-07-21 15:05           ` Chong Yidong
  2009-07-21 15:42             ` Stefan Monnier
  0 siblings, 1 reply; 34+ messages in thread
From: Chong Yidong @ 2009-07-21 15:05 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel

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)




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 20:42     ` Eli Zaretskii
@ 2009-07-21 15:31       ` Chong Yidong
  2009-07-22  1:43         ` Richard Stallman
  0 siblings, 1 reply; 34+ messages in thread
From: Chong Yidong @ 2009-07-21 15:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-21 14:41     ` Richard Stallman
@ 2009-07-21 15:38       ` Chong Yidong
  2009-07-22  1:43         ` Richard Stallman
  0 siblings, 1 reply; 34+ messages in thread
From: Chong Yidong @ 2009-07-21 15:38 UTC (permalink / raw)
  To: rms; +Cc: eliz, emacs-devel

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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-21 15:05           ` Chong Yidong
@ 2009-07-21 15:42             ` Stefan Monnier
  0 siblings, 0 replies; 34+ messages in thread
From: Stefan Monnier @ 2009-07-21 15:42 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-21 15:38       ` Chong Yidong
@ 2009-07-22  1:43         ` Richard Stallman
  0 siblings, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2009-07-22  1:43 UTC (permalink / raw)
  To: Chong Yidong; +Cc: eliz, emacs-devel

    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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-21 15:31       ` Chong Yidong
@ 2009-07-22  1:43         ` Richard Stallman
  0 siblings, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2009-07-22  1:43 UTC (permalink / raw)
  To: Chong Yidong; +Cc: eliz, emacs-devel

    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.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-20 18:32 Upcoming 23.1 release Chong Yidong
                   ` (5 preceding siblings ...)
  2009-07-21  3:55 ` Lennart Borgman
@ 2009-07-22  6:55 ` Yavor Doganov
  2009-07-22  7:24   ` David Reitter
  2009-07-24  0:46   ` YAMAMOTO Mitsuharu
  6 siblings, 2 replies; 34+ messages in thread
From: Yavor Doganov @ 2009-07-22  6:55 UTC (permalink / raw)
  To: emacs-devel

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





^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-22  6:55 ` Yavor Doganov
@ 2009-07-22  7:24   ` David Reitter
  2009-07-24  0:46   ` YAMAMOTO Mitsuharu
  1 sibling, 0 replies; 34+ messages in thread
From: David Reitter @ 2009-07-22  7:24 UTC (permalink / raw)
  To: Yavor Doganov; +Cc: emacs-devel

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





^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-22  6:55 ` Yavor Doganov
  2009-07-22  7:24   ` David Reitter
@ 2009-07-24  0:46   ` YAMAMOTO Mitsuharu
  2009-07-24  0:53     ` YAMAMOTO Mitsuharu
  2009-07-24 15:47     ` Adrian Robert
  1 sibling, 2 replies; 34+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-07-24  0:46 UTC (permalink / raw)
  To: emacs-devel, yavor

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-24  0:46   ` YAMAMOTO Mitsuharu
@ 2009-07-24  0:53     ` YAMAMOTO Mitsuharu
  2009-07-24 15:10       ` Yavor Doganov
  2009-07-24 15:47     ` Adrian Robert
  1 sibling, 1 reply; 34+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-07-24  0:53 UTC (permalink / raw)
  To: emacs-devel, yavor

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




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-24  0:53     ` YAMAMOTO Mitsuharu
@ 2009-07-24 15:10       ` Yavor Doganov
  0 siblings, 0 replies; 34+ messages in thread
From: Yavor Doganov @ 2009-07-24 15:10 UTC (permalink / raw)
  To: emacs-devel

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,






^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Upcoming 23.1 release
  2009-07-24  0:46   ` YAMAMOTO Mitsuharu
  2009-07-24  0:53     ` YAMAMOTO Mitsuharu
@ 2009-07-24 15:47     ` Adrian Robert
  1 sibling, 0 replies; 34+ messages in thread
From: Adrian Robert @ 2009-07-24 15:47 UTC (permalink / raw)
  To: emacs-devel

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.







^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2009-07-24 15:47 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-20 18:32 Upcoming 23.1 release Chong Yidong
2009-07-20 18:44 ` Eli Zaretskii
2009-07-20 18:51   ` Chong Yidong
2009-07-20 19:06     ` Eli Zaretskii
2009-07-20 19:37       ` Chong Yidong
2009-07-20 20:36         ` Eli Zaretskii
2009-07-21  1:20         ` Stefan Monnier
2009-07-21 15:05           ` Chong Yidong
2009-07-21 15:42             ` Stefan Monnier
2009-07-21 14:41         ` Richard Stallman
2009-07-21 14:41     ` Richard Stallman
2009-07-21 15:38       ` Chong Yidong
2009-07-22  1:43         ` Richard Stallman
2009-07-20 19:02   ` Chong Yidong
2009-07-20 20:42     ` Eli Zaretskii
2009-07-21 15:31       ` Chong Yidong
2009-07-22  1:43         ` Richard Stallman
2009-07-21 14:42     ` Richard Stallman
2009-07-21 14:41   ` Richard Stallman
2009-07-20 18:55 ` Dan Nicolaescu
2009-07-20 19:06   ` Chong Yidong
2009-07-21  3:16     ` usefulness of no-byte-compile [was: Re: Upcoming 23.1 release] Dan Nicolaescu
2009-07-20 20:05 ` Upcoming 23.1 release Chong Yidong
2009-07-20 22:58 ` Jason Rumney
2009-07-20 23:12   ` Chong Yidong
2009-07-21  0:43 ` Kenichi Handa
2009-07-21  3:10   ` Eli Zaretskii
2009-07-21  3:55 ` Lennart Borgman
2009-07-22  6:55 ` Yavor Doganov
2009-07-22  7:24   ` David Reitter
2009-07-24  0:46   ` YAMAMOTO Mitsuharu
2009-07-24  0:53     ` YAMAMOTO Mitsuharu
2009-07-24 15:10       ` Yavor Doganov
2009-07-24 15:47     ` Adrian Robert

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.