emacs-devel
[Top][All Lists]
Advanced

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

Re: Shift selection using interactive spec


From: David Kastrup
Subject: Re: Shift selection using interactive spec
Date: Wed, 26 Mar 2008 12:32:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Juri Linkov <address@hidden> writes:

>> Changing a command's behavior after the thought can be dealt with by
>> using advice.
>>
>> Attaching properties is a can of worms that does not work for anonymous
>> functions.
>
> But an interactive code does not work when a spec is a Lisp expression
> that is not a string.  So just as an interactive Lisp expression should
> call a special function `shift-translation-handler' explicitly,
> anonymous functions can call the same function as well (though it is
> not recommended to use anonymous functions for commands).  So both these
> approaches are on a par in this regard.

Which two approaches are you discussing here?  I don't see that your
argument addresses anything regarding properties.

> But using properties seems to be more preferable since there is a need
> to implement more related features like delete-selection-mode and
> inventing more funny interactive codes doesn't seem like a wise thing
> to do.

Attaching information magically to symbols rather than the actual
function seems much more unwise to me.

> The only problem I see is that properties currently are hard to
> discover.

That is because properties are not part of a function, but part of a
symbol.  And a symbol has all of function cell, value cell, property
list and name.  Those are disparate things.  Storing information about
the function in the property list scatters the information and makes it
impossible to use the actual function rather than the referring symbol.

> I think that just as `C-h f' describe-function displays information
> when the function is advised, we should change `C-h v'
> describe-variable to display information about attached variable
> properties as well.

But we are talking right now about _functions_.  And it is a mistake to
consider the property list part of either variable or function: it has
different scopes and is independent from both variable or function.

> Also as Kim already noted supporting external packages using the
> interactive specification code approach would be a nightmare.  So it
> seems it would be the best to go the way Kim suggested and just
> reimplement in C cua-selection-mode with properties that was proven by
> time and experience to be the right solution.

Uh, "could be made to work" does not imply "right solution".

-- 
David Kastrup




reply via email to

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