Re: [emacs-w3m:11603] Re: interactive-p obsolete

[Tim Cross]

On Wed, Jul 6, 2011 at 9:22 PM, Andreas Röhler
<address@hidden> wrote:
> Am 06.07.2011 09:09, schrieb Tim Cross:
>>
>> I don't believe the argument of not being able to use the new function
>> because of the need for backwards compatibility is valid. You can
>> solve this problem in a number of ways and maintain backwards
>> compatibility. In fact, its not uncommon to have to do this or that
>> different from wanting to maintain compatibility with emacs and xemcas
>> etc. If there is some other argument for not making the change, I'd be
>> interested in hearing it.
>>
>> Tim
>
> Hi Tim,
>
> from my perspective --which might miss the point anyway-- exist several
> reasons for reverting the change.
>
> First: what is the gain? IMHO new function is more difficult to use, slows
> down writing, needs more reflection than the old one.
>
> So to say: some classic over-specification.
> We must not differentiate here, better a simple one-for-all-function not
> bothering for specific argument: just interactive-p
>
> Alltogether new design evens doesn't deliver the basics needed, saying:
>
> "This function is meant for implementing advice and other
> function-modifying features.  Instead of using this, it is sometimes
> cleaner to give your function an extra optional argument whose
> `interactive' spec specifies non-nil unconditionally ("p" is a good
> way to do this), or via (not (or executing-kbd-macro noninteractive))."
>
> : hodge-podge
>

Hi Andreas

My main point was that backwards compatibility, as suggested in your
original post, was not sufficient justification to revert things as it
is trivial to add code that would provide this compatibility.
Furthermore, in many cases, packages already have this compatibility
layer in order to support both GNU Emacs and XEmacs (see the org-mode
example which has since been posted). However, while I may have things
a bit mixed up, as I understand it, there are some good reasons for
the change. It isn't just a change made  for the sake of it. Some may
debate whether the reasons are sufficient, but for me they seem
reasonable.

Others with more experience and better memories are probably able to
fill in things better, but from memory, there are some problems with
the use of interactive-p because people misinterpret what it means and
because they tend to use it without thinking about what 'interactive'
means.  Its one of those subtle issues that you may think you
understand and everyone else understands in the same way until you
begin to talk to others. You then find out there are a number of
situations where it isn't as clear as it originally seemed and that
you do need to think about the context where you use such a test and
what it is you really are wanting to test for.

I also believe the water was made even more 'muddy' by the fact that a
form of called-interactive-p, without an argument, already existed.
People found it hard to know when to use called-interactive-p or
interactive-p or what the difference was or why there was both. To
clarify matters, one had to go.

There was a discussion a couple of years back regarding this. At the
time, it was recognised that fixing it would improve elisp in the
long-term, but doing so was going to cause some pain. I believe that
the result, called-interactive-p with an optional argument and the
marking of interactive-p as obsolete was considered the solution with
the least pain and best outcome and seems like a reasonable compromise
to me.

Once interactive-p is actually removed, we will realise the benefits
of having a single predicate to test for 'interactive' and because of
the additional argument, possibly a predicate that is applied after
more thought as to what the programmer is really testing for,
hopefully resulting in code where intentions are clearer and
therefore, easier to maintain.

Tim