[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another Emacs incompatibilty
From: |
Emanuel Berg |
Subject: |
Re: Another Emacs incompatibilty |
Date: |
Tue, 25 Aug 2020 08:07:09 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Drew Adams wrote:
> A Lisp symbol is an object of sorts. It has a name
> and possibly other properties/attributes:
>
> * a name - `symbol-name' * a function value -
> `symbol-function' * a variable value - `symbol-value'
> * a property list - `symbol-plist'
Lisp, an OO language!
> You don't need to redefine
> `delete-selection-pre-hook'.
>
> You typically need only put a `delete-selection'
> property on a command's symbol, to get the behavior
> you want for it, which is just delete-the-selection
> in most cases, i.e., value `t'.
OK, now I understand this...
We have a function f that operates on functions a, b,
and c.
If we put configuration in f, it will indeed work for
functions a, b, and c.
However... if someone writes a function d, f will not
be configurable for d, since d didn't exist when
f was written. If we want the same for d, we must
redefine f! Solution: put the configuration in a, b,
c, and d, and it works now and for whatever e, f,
g anyone can come up with. Wonderful!
However (2) ... we can also solve this with
a variable list l that f looks into. Wanna have this
behavior for d, e, f, and g? Just add them to
the list!
This is what my suggestion does [1], only the list is
in f, so yes, it is redefined in that particular
implementation but it is a kill and yank operation
away from having the list a variable instead.
But, for the record, tho I think that solution is
better (easier) _in general_, in this case it is
built to be operated on the command level so here
I recommend a loop which sets the properties...
--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal
- Re: Another Emacs incompatibilty, (continued)
- RE: Another Emacs incompatibilty, Drew Adams, 2020/08/24
- Re: Another Emacs incompatibilty, Emanuel Berg, 2020/08/24
- Re: Another Emacs incompatibilty, Alan Davis, 2020/08/24
- RE: Another Emacs incompatibilty, Drew Adams, 2020/08/25
- RE: Another Emacs incompatibilty, Drew Adams, 2020/08/25
- Re: Another Emacs incompatibilty, Emanuel Berg, 2020/08/25
- Re: Another Emacs incompatibilty, Emanuel Berg, 2020/08/25
- RE: Another Emacs incompatibilty, Drew Adams, 2020/08/25
- Re: Another Emacs incompatibilty,
Emanuel Berg <=
- Re: Another Emacs incompatibilty, Emanuel Berg, 2020/08/25
- Re: Another Emacs incompatibilty, Stefan Monnier, 2020/08/24
- Re: Another Emacs incompatibilty, Emanuel Berg, 2020/08/24
- RE: Another Emacs incompatibilty, Drew Adams, 2020/08/18
- Re: Another Emacs incompatibilty, Eric Abrahamsen, 2020/08/18
- RE: Another Emacs incompatibilty, Drew Adams, 2020/08/18
- Re: Another Emacs incompatibilty, Eric Abrahamsen, 2020/08/18
- Re: Another Emacs incompatibilty, Emanuel Berg, 2020/08/18
Re: Another Emacs incompatibilty, Gregory Heytings, 2020/08/17