Re: gnus-summary-catchup turns ticked into unread

Re: gnus-summary-catchup turns ticked into unread

[Richard Stallman]

    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?

Re: gnus-summary-catchup turns ticked into unread

[Richard Stallman]

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

Re: gnus-summary-catchup turns ticked into unread

[Katsumi Yamaoka]

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

Re: gnus-summary-catchup turns ticked into unread

[Richard Stallman]

    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.

Re: gnus-summary-catchup turns ticked into unread

[Katsumi Yamaoka]

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