called-interactively-p

[Stefan Monnier]

Following the discussion we had here around interactive-p and
called-interactively-p, I've just installed the following changes:
- called-interactively-p takes a parameter `kind' which can be
  either `interactive' or `any', the first corresponds to what
  interactive-p used to do and the second to what called-interactively-p
  used to do.
  The function still works if called without any argument, but the
  byte-compiler will complain about the missing argument (it's the best
  trade-off I could come up between breaking compatibility and
  enouraging people to pass as argument).
- interactive-p is marked obsolete.  This is not quite as simple as it
  sounds, because interactive-p has its own byte-code.  So we'll have to
  improve our "obsolescence" infrastructure if we want to handle this
  right.  For now, all the "make-obsolete" does in the end is to make
  C-h f tell you the function is obsolete, which seems good enough for
  now, especially given the 300 or so calls to interactive-p we still
  have in our own code.


-- Stefan

[Juanma Barranquero]

On Thu, Oct 1, 2009 at 20:15, Stefan Monnier <monnier@...> wrote:

> especially given the 300 or so calls to interactive-p we still
>  have in our own code.

98 now.

 49 cedet
 29 org
  7 erc
  6 gnus
  5 other packages

    Juanma

[Carsten Dominik-3]

On Oct 2, 2009, at 5:59 AM, Juanma Barranquero wrote:

> On Thu, Oct 1, 2009 at 20:15, Stefan Monnier  
> <monnier@...> wrote:
>
>> especially given the 300 or so calls to interactive-p we still
>>  have in our own code.
>
> 98 now.
>
> 49 cedet
> 29 org

I will take care of the ones in Org.

- Carsten

>  7 erc
>  6 gnus
>  5 other packages
>
>    Juanma
>
>

[Carsten Dominik-4]

On Oct 9, 2009, at 10:50 AM, Carsten Dominik wrote:

>
> On Oct 2, 2009, at 5:59 AM, Juanma Barranquero wrote:
>
>> On Thu, Oct 1, 2009 at 20:15, Stefan Monnier <monnier@...
>> > wrote:
>>
>>> especially given the 300 or so calls to interactive-p we still
>>> have in our own code.
>>
>> 98 now.
>>
>> 49 cedet
>> 29 org
>
> I will take care of the ones in Org.

Well, it turns out that I don't know a good way to take care of this.
I would like to have Org be compatible with Emacs 22 and also XEmacs,
and I don't know how I can do this with the new `called-interactively',
except for creating diverging code bases.

Advice would be appreciated.

Thanks.

- Carsten
>
>> 7 erc
>> 6 gnus
>> 5 other packages
>>
>>   Juanma
>>
>>
>

- Carsten

[Stefan Monnier]

> Well, it turns out that I don't know a good way to take care of this.
> I would like to have Org be compatible with Emacs 22 and also XEmacs,
> and I don't know how I can do this with the new `called-interactively',
> except for creating diverging code bases.

Yes, this is a problem.  The best I can offer is to use a macro that
expands to either of the alternatives (a function wouldn't work because
it would cause interactive-p to always return nil).

(defmacro org-called-interactively-p (kind)
  (condition-case nil
      (progn (called-interactively-p nil)
             ;; If the call didn't signal an error, then the new form
             ;; is supported: use it.
             `(called-interactively-p ,kind))
    (wrong-number-of-arguments
     ;; Probably Emacs-23.1.
     (if (equal (eval kind) 'interactive)
         `(interactive-p)
       `(called-interactively-p)))
    (error
     ;; called-interactively-p seems not to be supported, fallback
     ;; on the good ol' interactive-p.
     `(interactive-p))))

Of course the above code is guaranteed 100% untested.


        Stefan

[Andreas Roehler]

Stefan Monnier wrote:

>> Well, it turns out that I don't know a good way to take care of this.
>> I would like to have Org be compatible with Emacs 22 and also XEmacs,
>> and I don't know how I can do this with the new `called-interactively',
>> except for creating diverging code bases.
>
> Yes, this is a problem.  The best I can offer is to use a macro that
> expands to either of the alternatives (a function wouldn't work because
> it would cause interactive-p to always return nil).
>
> (defmacro org-called-interactively-p (kind)
>   (condition-case nil
>       (progn (called-interactively-p nil)
>              ;; If the call didn't signal an error, then the new form
>              ;; is supported: use it.
>              `(called-interactively-p ,kind))
>     (wrong-number-of-arguments
>      ;; Probably Emacs-23.1.
>      (if (equal (eval kind) 'interactive)
>          `(interactive-p)
>        `(called-interactively-p)))
>     (error
>      ;; called-interactively-p seems not to be supported, fallback
>      ;; on the good ol' interactive-p.
>      `(interactive-p))))
>
> Of course the above code is guaranteed 100% untested.
>
>
>         Stefan
>
>
>

Remember thread "interactive-p and called-interactively-p".
Think Drew Adams was right and your first response too.

Otherwise we see things going still more complicated.

Cheers
Andreas

[Carsten Dominik-4]

On Nov 5, 2009, at 8:13 PM, Stefan Monnier wrote:

>> Well, it turns out that I don't know a good way to take care of this.
>> I would like to have Org be compatible with Emacs 22 and also XEmacs,
>> and I don't know how I can do this with the new `called-
>> interactively',
>> except for creating diverging code bases.
>
> Yes, this is a problem.  The best I can offer is to use a macro that
> expands to either of the alternatives (a function wouldn't work  
> because
> it would cause interactive-p to always return nil).

And a macro will only work if the user runs compiled code, right?

- Carsten

>
> (defmacro org-called-interactively-p (kind)
>  (condition-case nil
>      (progn (called-interactively-p nil)
>             ;; If the call didn't signal an error, then the new form
>             ;; is supported: use it.
>             `(called-interactively-p ,kind))
>    (wrong-number-of-arguments
>     ;; Probably Emacs-23.1.
>     (if (equal (eval kind) 'interactive)
>         `(interactive-p)
>       `(called-interactively-p)))
>    (error
>     ;; called-interactively-p seems not to be supported, fallback
>     ;; on the good ol' interactive-p.
>     `(interactive-p))))
>
> Of course the above code is guaranteed 100% untested.
>
>
>        Stefan

- Carsten

[Stefan Monnier]

>> Yes, this is a problem.  The best I can offer is to use a macro that
>> expands to either of the alternatives (a function wouldn't work because
>> it would cause interactive-p to always return nil).
> And a macro will only work if the user runs compiled code, right?

I don't think so: it should work correctly in either case.


        Stefan