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