* Re: gnus-summary-catchup turns ticked into unread [not found] ` <b4mps2zzivn.fsf@jpl.org> @ 2007-08-06 14:22 ` Richard Stallman 2007-08-14 0:28 ` Richard Stallman 1 sibling, 0 replies; 5+ messages in thread From: Richard Stallman @ 2007-08-06 14:22 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: emacs-devel The function definition for the XEmacs version of pop-to-buffer is as follows. There's no difference between XEmacs 21.4 and 21.5. The optional ON-FRAME is boolean, so there seems no way to keep the compatibility. (defun pop-to-buffer (bufname &optional not-this-window-p on-frame) ... If optional third arg is non-nil, it is the frame to pop to this buffer on. I am sure that few callers pass the argument NORECORD to pop-to-buffer. So I think an incompatible change would be ok, adding the ON-FRAME argument before NORECORD. What do others think? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gnus-summary-catchup turns ticked into unread [not found] ` <b4mps2zzivn.fsf@jpl.org> 2007-08-06 14:22 ` gnus-summary-catchup turns ticked into unread Richard Stallman @ 2007-08-14 0:28 ` Richard Stallman 2007-08-16 1:54 ` Katsumi Yamaoka 1 sibling, 1 reply; 5+ messages in thread From: Richard Stallman @ 2007-08-14 0:28 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: emacs-devel [I sent this message a week ago but did not get a response. Could we get the discussion moving again?] The function definition for the XEmacs version of pop-to-buffer is as follows. There's no difference between XEmacs 21.4 and 21.5. The optional ON-FRAME is boolean, so there seems no way to keep the compatibility. (defun pop-to-buffer (bufname &optional not-this-window-p on-frame) ... If optional third arg is non-nil, it is the frame to pop to this buffer on. I am sure that few callers pass the argument NORECORD to pop-to-buffer. So I think an incompatible change would be ok, adding the ON-FRAME argument before NORECORD. What do others think? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gnus-summary-catchup turns ticked into unread 2007-08-14 0:28 ` Richard Stallman @ 2007-08-16 1:54 ` Katsumi Yamaoka 2007-08-16 18:39 ` Richard Stallman 0 siblings, 1 reply; 5+ messages in thread From: Katsumi Yamaoka @ 2007-08-16 1:54 UTC (permalink / raw) To: rms; +Cc: emacs-devel >>>>> Richard Stallman wrote: > [I sent this message a week ago but did not get a response. > Could we get the discussion moving again?] > The function definition for the XEmacs version of pop-to-buffer > is as follows. There's no difference between XEmacs 21.4 and 21.5. > The optional ON-FRAME is boolean, so there seems no way to keep > the compatibility. > (defun pop-to-buffer (bufname &optional not-this-window-p on-frame) > ... > If optional third arg is non-nil, it is the frame to pop to this > buffer on. > I am sure that few callers pass the argument NORECORD to > pop-to-buffer. So I think an incompatible change would be ok, adding > the ON-FRAME argument before NORECORD. > What do others think? I worry that changing the arguments list of such a generic function in Emacs causes further confusion. For instance, since Gnus supports Emacs 21, 22, 23 and XEmacs, source codes that use `pop-to-buffer' and need to use the NORECORD argument will have to get more complicated. We might, if anything, give up using that argument, since it doesn't seem to be very important in the codes in question actually. It also might suggest that such arguments that are not indispensable and are incompatible with versions of Emacsen will be doomed to be not used. So, I think we have nothing to do for `pop-to-buffer'. Regards, ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gnus-summary-catchup turns ticked into unread 2007-08-16 1:54 ` Katsumi Yamaoka @ 2007-08-16 18:39 ` Richard Stallman 2007-08-17 1:22 ` Katsumi Yamaoka 0 siblings, 1 reply; 5+ messages in thread From: Richard Stallman @ 2007-08-16 18:39 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: emacs-devel I worry that changing the arguments list of such a generic function in Emacs causes further confusion. I think that compatibility in the long term will do more good than the short-term confusion. We might, if anything, give up using that argument, since it doesn't seem to be very important in the codes in question actually. That means that Gnus can easily avoid being affected the confusion. Right? So I conclude it is ok to change this. It also might suggest that such arguments that are not indispensable and are incompatible with versions of Emacsen will be doomed to be not used. I think that an arg which is compatible between future Emacs versions and XEmacs could be used easily enough, when there is a need to use it. So I tend to think we should go ahead with this change, unless there is some other reason not to. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gnus-summary-catchup turns ticked into unread 2007-08-16 18:39 ` Richard Stallman @ 2007-08-17 1:22 ` Katsumi Yamaoka 0 siblings, 0 replies; 5+ messages in thread From: Katsumi Yamaoka @ 2007-08-17 1:22 UTC (permalink / raw) To: rms; +Cc: emacs-devel >>>>> Richard Stallman wrote: > I worry that changing the arguments list of such a generic function > in Emacs causes further confusion. > I think that compatibility in the long term will do more good > than the short-term confusion. > We might, if anything, give up using that argument, since it doesn't > seem to be very important in the codes in question actually. > That means that Gnus can easily avoid being affected the confusion. > Right? Indeed. I agreed with you, and made changes in Gnus so as not to use the NORECORD argument in `pop-to-buffer's. (The changes will be merged into Emacs soon.) > So I conclude it is ok to change this. > It also > might suggest that such arguments that are not indispensable and are > incompatible with versions of Emacsen will be doomed to be not used. > I think that an arg which is compatible between future Emacs versions > and XEmacs could be used easily enough, when there is a need to use it. You're right. It's much better than we do nothing. > So I tend to think we should go ahead with this change, > unless there is some other reason not to. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-08-17 1:22 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20070702160929.C21251C8115@galatea.esat.kuleuven.be> [not found] ` <b4mmyydn5r2.fsf@jpl.org> [not found] ` <b4m64501nt8.fsf@jpl.org> [not found] ` <E1I6GBH-0006d2-HI@fencepost.gnu.org> [not found] ` <b4mejjn1usy.fsf@jpl.org> [not found] ` <E1I6Y2D-00062v-Iq@fencepost.gnu.org> [not found] ` <b4mr6nhjgq1.fsf@jpl.org> [not found] ` <E1I8Nlq-0000oX-F6@fencepost.gnu.org> [not found] ` <b4mps2zzivn.fsf@jpl.org> 2007-08-06 14:22 ` gnus-summary-catchup turns ticked into unread Richard Stallman 2007-08-14 0:28 ` Richard Stallman 2007-08-16 1:54 ` Katsumi Yamaoka 2007-08-16 18:39 ` Richard Stallman 2007-08-17 1:22 ` Katsumi Yamaoka
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).