emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interactive hat.


From: Alan Mackenzie
Subject: Re: Interactive hat.
Date: Thu, 26 Mar 2009 19:06:03 +0000
User-agent: Mutt/1.5.9i

Hi, Stefan!

On Thu, Mar 26, 2009 at 01:09:48PM -0400, Stefan Monnier wrote:
> > Yes, I hate this feature.  But rather than blinding me, this has
> > opened my eyes to its problems, and I am thus motivated to root them
> > out.  By contrast, those who like the feature will be blind to these
> > problems.

> The feature is a result of a long and painful process.  I have no
> intention to go through it again.  I think the result is pretty clean,
> so I'm not open to changing it, except for minor aspects.

The process was painful in the extreme, I remember it well.  I don't want
to go through it again either.  I'm confident that my suggestion below
doesn't change the status quo; it justs adds a facility for external
maintainers.

> > Anyhow, I've discovered that this problem is not new, and it's
> > already been solved.  XEmacs put a "_" into their interactive string
> > long ago, and there's a macro `defunx' in antlr-mode.el which, when
> > used in place of `defun', strips out the "_" from an interactive
> > string; OK, it does a few other things, too.

> > How about adapting this macro and putting it into a special source
> > file in .../lisp/, and making a discreet mention of it in "Using
> > Interactive" in the elisp manual?  For example: "Note that using
> > \"^\" will prevent your function running in older Emacs versions.  If
> > you need this compatibility, consider using the macro `defunh' in the
> > file lisp/compatibility.el.".

> > I would far rather put the work in here and now than have to field
> > complaints on bug-cc-mode in a year's time, asking why the CC Mode
> > commands don't work with shift-select-mode.

> > So, how about it?  This solution will leave interactive-hat, as it is
> > currently implemented, untouched, and it will stop me moaning about it
> > for ever.

> What about my other suggestion to make it available to interactive
> specs using a Lisp form rather than a string?  That would seem a lot
> simpler and cleaner.

I'm assuming an external package maintainer wanting to use (interactive
"^P\nr"), still have the command work in Emacs <23 and XEmacs, yet not
have to waste time working out for herself how to achieve this.  I think
I might have misunderstood your suggestion.

> So, I've indeed done that, which incidentally simplifies the code.
> Now inserting a "^" in the interactive string is just the same as
> calling (handle-shift-selection), so you can write

>   (interactive
>    (progn (if (fboundp 'handle-shift-selection) (handle-shift-selection))
>           ...blabla...))

No, that's not simpler or clearer.  It's just pushing the work onto the
package maintainer.  And it's a LOT of work.  For example,

    (interactive "^P\nr")

becomes

    (interactive
      (progn (if (fboundp 'handle-shift-selection)
                 (handle-shift-selection))
             `(current-prefix-arg
               ,(if (< (point) (mark))
                    ,@((point) (mark))
                  ,@((mark) (point))))))

, or something equally repulsive, requiring infinitely more debugging
than the string it replaces.  My proposal is to suggest to the maintainer
she copy the macro from .../lisp/compatibility.el into her own sources,
rename it `foo-defunh'[*] and write:

[*] think of this as a hyperbolic defun. ;-)

  (foo-defunh foo-forward-blarg (arg beg end) "..." (interactive "^P\nr") ....)

Although there's a certain tedium involved in that suggestion, it's a
straightforward recipe that doesn't require thinking.

> -- Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]