From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>, <emacs-devel@gnu.org>
Subject: RE: Odd unused yank-handler arguments
Date: Sun, 2 May 2010 06:54:29 -0700 [thread overview]
Message-ID: <D640F66A247E449EA081196BC55A1109@us.oracle.com> (raw)
In-Reply-To: <jwvtyqqu8xh.fsf-monnier+emacs@gnu.org>
> Any objection to the patch below?
>
> -(defun kill-new (string &optional replace yank-handler)
> +(defun kill-new (string &optional replace)
>
> -(defun kill-append (string before-p &optional yank-handler)
> +(defun kill-append (string before-p)
>
> -(defun kill-region (beg end &optional yank-handler)
> +(defun kill-region (beg end)
1. I don't use the `yank-handler' arg myself, so I don't have any objection a
priori.
2. However, why not give the reason for the change?
To understand this, I'm looking through the code (since Emacs 22, when this arg
was introduced) to try to understand. It seems to all turn around
`insert-for-yank-1', which still seems to respect a `yank-handler' property.
At least in the 1-96 pretest and in your patch, I see no change to the
`insert-for-yank-1' behavior, so this is apparently only to remove the arg for
those three `kill-*' functions. Can you give an idea what is behind the proposed
change?
Perhaps the reason is that those functions should never have had such an arg. Or
perhaps it is that they no longer need it. Or that no existing code using them
uses the arg. Or...
IOW, why not be clear, saying (a) whether there is also some associated general
change to the yank-handler handling and (b) what the particular motivation for
this change is?
Removing an arg is like adding an arg. What's the reason?
next prev parent reply other threads:[~2010-05-02 13:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-02 6:15 Odd unused yank-handler arguments Stefan Monnier
2010-05-02 13:54 ` Drew Adams [this message]
2010-05-02 19:50 ` Stefan Monnier
2010-05-02 19:55 ` Drew Adams
2010-05-02 19:48 ` Kim F. Storm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D640F66A247E449EA081196BC55A1109@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.