can a command specify overwrite selection behavior?

can a command specify overwrite selection behavior?

[Xah Lee]

i have this code that inserts date.

(defun insert-date ()
  "Insert current date."
  (interactive)
  (insert (format-time-string "%Y-%m-%d"))
  )
(put 'insert-date 'delete-selection t)

the last line is to make sure that if i have a text selection, just
overwrite it.

but it doesn't work.

i wrote to FSF about it i think last year as a bug report, i think
Richard Stallman himself turned it down.

but in my daily use, this is quite annoying.

with i think recent interest in behavior of text selection, can this
be made to work?

thanks.

 Xah

Re: can a command specify overwrite selection behavior?

[Xah Lee]

On Aug 31, 10:33 pm, Xah Lee <xah...@gmail.com> wrote:
> i have this code that inserts date.
>
> (defun insert-date ()
>   "Insert current date."
>   (interactive)
>   (insert (format-time-string "%Y-%m-%d"))
>   )
> (put 'insert-date 'delete-selection t)
>
> the last line is to make sure that if i have a text selection, just
> overwrite it.
>
> but it doesn't work.
> ...

work around:

(defun insert-date ()
  "Insert current date."
  (interactive)
  (when (region-active-p)
    (delete-region (region-beginning) (region-end) )
    )
  (insert (format-time-string "%Y-%m-%d"))
  )

RE: can a command specify overwrite selection behavior?

[Drew Adams]

> > i have this code that inserts date.
> >
> > (defun insert-date ()
> >   "Insert current date."
> >   (interactive)
> >   (insert (format-time-string "%Y-%m-%d")))
> >
> > (put 'insert-date 'delete-selection t)
> >
> > the last line is to make sure that if i have a text selection, just
> > overwrite it. but it doesn't work.

Actually, it does work, Xah.

If you just try `M-x insert-date' then you won't see that it works.  That's true
also of any other command with a `delete-selection' property.  That has to do
with the region being deactivated when you exit the minibuffer.

To see that it works, bind it to a key and then use the key:
(global-set-key [insert] 'insert-date)

Re: can a command specify overwrite selection behavior?

[Xah Lee]

On Dec 10, 3:37 pm, "Drew Adams" <drew.ad...@oracle.com> wrote:
> > > i have this code that inserts date.
>
> > > (defun insert-date ()
> > >   "Insert current date."
> > >   (interactive)
> > >   (insert (format-time-string "%Y-%m-%d")))
>
> > > (put 'insert-date 'delete-selection t)
>
> > > the last line is to make sure that if i have a text selection, just
> > > overwrite it. but it doesn't work.
>
> Actually, it does work, Xah.
>
> If you just try `M-x insert-date' then you won't see that it works.  That's true
> also of any other command with a `delete-selection' property.  That has to do
> with the region being deactivated when you exit the minibuffer.
>
> To see that it works, bind it to a key and then use the key:
> (global-set-key [insert] 'insert-date)

thanks Drew for this tip. I didn't know about it.

btw, why the distinction on how the command is called?

all i recall about this issue is that i entered a bug report and
Richard Stallman specifically don't consider it a bug.

 Xah

RE: can a command specify overwrite selection behavior?

[Drew Adams]

> > To see that it works, bind it to a key and then use the key:
> > (global-set-key [insert] 'insert-date)
> 
> thanks Drew for this tip. I didn't know about it.
> btw, why the distinction on how the command is called?

When you hit a key to invoke a command, you are not passing through `M-x'.

> all i recall about this issue is that i entered a bug report and
> Richard Stallman specifically don't consider it a bug.

I agree with him that it is not a bug.  But none of us (you, me, or even His
Grand Gnuness) is perfect. ;-)

Re: can a command specify overwrite selection behavior?

[Xah Lee]

On Dec 13, 9:16 am, "Drew Adams" <drew.ad...@oracle.com> wrote:
> > > To see that it works, bind it to a key and then use the key:
> > > (global-set-key [insert] 'insert-date)
>
> > thanks Drew for this tip. I didn't know about it.
> > btw, why the distinction on how the command is called?
>
> When you hit a key to invoke a command, you are not passing through `M-x'.
>
> > all i recall about this issue is that i entered a bug report and
> > Richard Stallman specifically don't consider it a bug.
>
> I agree with him that it is not a bug.  But none of us (you, me, or even His
> Grand Gnuness) is perfect. ;-)

Drew, what i didn't understand is why the insert-date property makes a
distinction on whether a command is called by name or by a keyboard
shortcut?

 Xah

RE: can a command specify overwrite selection behavior?

[Drew Adams]

> Drew, what i didn't understand is why the insert-date property makes a
> distinction on whether a command is called by name or by a keyboard
> shortcut?

Ah, good question.  Here's the answer:

(defun delete-selection-pre-hook ()
  (when (and delete-selection-mode
             transient-mark-mode mark-active
	       (not buffer-read-only))
    (let ((type (and (symbolp this-command)
		         (get this-command ; <=======
                          'delete-selection))))

If you debug this (use `message', not `debug-on-entry'!), you'll see that when
you use `M-x' the value of `this-command' is `execute-extended-command', not
`insert-date'.  And `execute-extended-command' does not have a non-nil
`delete-selection' property.

`execute-extended-command' is a bit special wrt `this-command' and
`last-command'.  It DTRT in the end, essentially removing itself from the party,
but that's only at the end.  While `execute-extended-command' is executing, it
is the value of `this-command'.

People sometimes get thrown off by this kind of thing, and similar things wrt
`M-:' (and `C-x C-e', `C-M-x'...).

The thing to remember is that `M-x' and `M-:' are themselves keys that are bound
to commands, and that even though they invoke or evaluate other stuff (and that
other stuff is what we focus on), that is not the same as just invoking or
evaluating the other stuff directly.  They add their bit to the mix, and
sometimes that makes a difference.

It can help to remember that EVERYTHING in Emacs is a COMMAND.  Or, rather,
every user interaction is via a command.  Outside Emacs we are not used to
thinking that way (because outside Emacs it is not true).  But even when you hit
a letter key such as `g' Emacs invokes a command (by default,
`self-insert-command').

Always.  Well no, you can undefine keys: (global-unset-key "a") etc., but as a
general rule it is true.

(I know that you know all of this, but I find it's worth reminding myself from
time to time.  Emacs interaction is all about commands.)

Re: can a command specify overwrite selection behavior?

[Xah Lee]

On Dec 22, 9:12 am, "Drew Adams" <drew.ad...@oracle.com> wrote:
> > Drew, what i didn't understand is why the insert-date property makes a
> > distinction on whether a command is called by name or by a keyboard
> > shortcut?
>
> Ah, good question.  Here's the answer:
>
> (defun delete-selection-pre-hook ()
>   (when (and delete-selection-mode
>              transient-mark-mode mark-active
>                (not buffer-read-only))
>     (let ((type (and (symbolp this-command)
>                          (get this-command ; <=======
>                           'delete-selection))))
>
> If you debug this (use `message', not `debug-on-entry'!), you'll see that when
> you use `M-x' the value of `this-command' is `execute-extended-command', not
> `insert-date'.  And `execute-extended-command' does not have a non-nil
> `delete-selection' property.
>
> `execute-extended-command' is a bit special wrt `this-command' and
> `last-command'.  It DTRT in the end, essentially removing itself from the party,
> but that's only at the end.  While `execute-extended-command' is executing, it
> is the value of `this-command'.
>
> People sometimes get thrown off by this kind of thing, and similar things wrt
> `M-:' (and `C-x C-e', `C-M-x'...).
>
> The thing to remember is that `M-x' and `M-:' are themselves keys that are bound
> to commands, and that even though they invoke or evaluate other stuff (and that
> other stuff is what we focus on), that is not the same as just invoking or
> evaluating the other stuff directly.  They add their bit to the mix, and
> sometimes that makes a difference.
>
> It can help to remember that EVERYTHING in Emacs is a COMMAND.  Or, rather,
> every user interaction is via a command.  Outside Emacs we are not used to
> thinking that way (because outside Emacs it is not true).  But even when you hit
> a letter key such as `g' Emacs invokes a command (by default,
> `self-insert-command').
>
> Always.  Well no, you can undefine keys: (global-unset-key "a") etc., but as a
> general rule it is true.
>
> (I know that you know all of this, but I find it's worth reminding myself from
> time to time.  Emacs interaction is all about commands.)

hi Drew. Very useful info i do not know about. Thanks.

 Xah

Re: can a command specify overwrite selection behavior?

[Ilya Zakharevich]

On 2010-12-22, Drew Adams <drew.adams@oracle.com> wrote:
>> Drew, what i didn't understand is why the insert-date property makes a
>> distinction on whether a command is called by name or by a keyboard
>> shortcut?

> (defun delete-selection-pre-hook ()
>   (when (and delete-selection-mode
>              transient-mark-mode mark-active
> 	       (not buffer-read-only))
>     (let ((type (and (symbolp this-command)
> 		         (get this-command ; <=======
>                           'delete-selection))))
>
> If you debug this (use `message', not `debug-on-entry'!), you'll see that when
> you use `M-x' the value of `this-command' is `execute-extended-command', not
> `insert-date'.  And `execute-extended-command' does not have a non-nil
> `delete-selection' property.
>
> `execute-extended-command' is a bit special wrt `this-command' and
> `last-command'.  It DTRT in the end, essentially removing itself from the party,
> but that's only at the end.  While `execute-extended-command' is executing, it
> is the value of `this-command'.
>
> People sometimes get thrown off by this kind of thing, and similar things wrt
> `M-:' (and `C-x C-e', `C-M-x'...).

Essentially, I read this as a detailed explanation of the way this bug
is triggered.  If one understands the mechanism of this bug so well,
why not fix it?  AFAICS, this subroutine is placed in a wrong hook; it
should be executed later...

Puzzled,
Ilya

RE: can a command specify overwrite selection behavior?

[Drew Adams]

> Essentially, I read this as a detailed explanation of the way this bug
> is triggered.  If one understands the mechanism of this bug so well,
> why not fix it?  AFAICS, this subroutine is placed in a wrong hook; it
> should be executed later...

What bug?  What subroutine?  What hook?  What should be executed later than
what?


This behavior is _by design_.

Delete-selection mode works by your telling Emacs how you want particular
commands to behave wrt an active region.

In the example, Xah told it to make command `insert-date' delete the active
region before it does its own thing of inserting a date.  Xah did not tell it to
make command `execute-extended-command' delete the active region before it does
its own thing of reading and then invoking a command.

Emacs is just doing what it was told to do.

There are many ways to evaluate a sexp (or invoke a command).  Many of them also
do additional things, besides just evaluating (e.g reading, pretty-printing).
Or they evaluate in different contexts (e.g. interactively or not).

These differences in behavior are _by design_, not bugs.

Re: can a command specify overwrite selection behavior?

[Ilya Zakharevich]

On 2010-12-25, Drew Adams <drew.adams@oracle.com> wrote:
>> Essentially, I read this as a detailed explanation of the way this bug
>> is triggered.  If one understands the mechanism of this bug so well,
>> why not fix it?  AFAICS, this subroutine is placed in a wrong hook; it
>> should be executed later...
>
> What bug?

One discussed in this subthread.

> What subroutine?  What hook?  What should be executed later than
> what?

Can't answer these questions: the posted code is not complete.

I expect the subroutine you posted is put into some hook.  This hook
is executed when M-x-handler had no chance yet to change
last-command/this-command.  Hence the hook should better be executed
later than this.

> This behavior is _by design_.

Could you show me the design document specifying that commands MUST
behave differently when executed by M-x?

> Emacs is just doing what it was told to do.

This is a complete nonce.  EVERY piece of software "is just doing what
it was told to do".  Still, some are more buggy, some are less.

Hope this helps,
Ilya

RE: can a command specify overwrite selection behavior?

[Drew Adams]

> >> Essentially, I read this as a detailed explanation of the 
> >> way this bug is triggered.  If one understands the mechanism
> >> of this bug so well, why not fix it?  AFAICS, this subroutine
> >> is placed in a wrong hook; it should be executed later...
> >
> > What bug?
> 
> One discussed in this subthread.

You read the thread wrong, IMO.  No bug.

> > What subroutine?  What hook?  What should be executed later than
> > what?
> 
> Can't answer these questions: the posted code is not complete.

Do you mean the snippet from `delete-selection-pre-hook' that I showed?  I'm
sure you know how to find the complete code for it in file `delsel.el'.

> I expect the subroutine you posted is put into some hook.  This hook
> is executed when M-x-handler had no chance yet to change
> last-command/this-command.  Hence the hook should better be executed
> later than this.

If you have a bug to report or you think you have a bug fix or an enhancement
patch, then use `M-x report-emacs-bug'.  The Emacs developers will be glad to
tell you whether they consider it a bug, a welcome bug fix, or a welcome
enhancement patch.

I don't speak for them any more than you do.  But according to Xah, one of those
developers (a certain RMS) already informed him that the behavior he described
is no bug.  One can certainly disagree with the Emacs developers, and I do so as
often as anyone. ;-)  But they are the ones to convince, not me.

> > This behavior is _by design_.
> 
> Could you show me the design document specifying that commands MUST
> behave differently when executed by M-x?

"By design" means on purpose, purposefully, with intention, in an intentional
manner, by choice, deliberately.  And yes, like it or not, most things done by
design are done without any design document.  Did you write a design document
for your mail reply before creating the reply?  Could you show it to me please?
What about a design document for that design document?...

The behavior that was described is part of the intended behavior of `M-x'.  The
purpose of `M-x' includes not only invoking a command but interacting with the
user, on demand.

To that end, `M-x' reads a command, with completion, updates a user-interaction
command history, and does a few other things as well.  Invoking a command is
_one_ part of what it does - one part of what it was designed to do.  `M-x' has
several balls in the air at once.  

That it juggles `this-command'/`last-command' is one (non-trivial) part of its
act.  And yes, anything involving `this-command'/`last-command' is somewhat
limited/fragile.  No question about it.

But if you need a design document to tell that the purpose of `M-x' is more than
just invoking a command then there's probably nothing more I can do for you.  I
pointed out (i.e., admitted) that many of us (i.e., me too) do get tripped up
from time to time and forget this, but when you do think about it it should be
clear.  `M-x' is a UI thing.

At any rate, the original question was about the behavior of
`delete-selection-mode' and why the active region is not deleted when you invoke
a command such as Xah's `insert-date' that is configured wrt `d-s-mode' to first
delete the active region.

I think I answered that.  And yes, it is because of how `M-x' and
`delete-selection-mode' are designed to work - whether or not anyone can find a
design document for either of them.

The code snippet I quoted makes clear the implementation of
`delete-selection-mode' and strongly suggests its design.  The code simply
checks the recorded `delete-selection' property for the value of `this-command'.
That's worth what it's worth, no more.  It is well known that there are
limitations to such a simple approach.  Both `M-x' and delete-selection mode
fiddle with `this-command'; they are both limited by it.

If you want to redesign or reimplement `delete-selection-mode', feel free.  But
its behavior in this case is not some oversight, accident, or mistake, AFAICT.
It is working the way it was intended to work.  And so is `M-x'.

> > Emacs is just doing what it was told to do.
> 
> This is a complete nonce.  EVERY piece of software "is just doing what
> it was told to do".  Still, some are more buggy, some are less.
> 
> Hope this helps, Ilya

Hope it helped you.  I have my doubts that it helped anyone else.

Re: can a command specify overwrite selection behavior?

[Xah Lee]

> > Hope this helps, Ilya
>
> Hope it helped you.  I have my doubts that it helped anyone else.

lol. funny. I see a flamewar brewing, and am getting into the fray
here by participating.

I think both Drew and Llya or even me adds good points in the
discussion.

The way i see this is a bug is in the sense that the purpose of delete-
selection property seems to be thwarted by specific way how emacs
works. Namely, the final effect is that it makes a distinction on
whether the command is invoked by M-x or by a hotkey.

so, i tend to see this is not a desired behavior (call it “bug” or
“feature” or “design” or whatnot).

but overall i guess this is trivial? It would be fruitful if someone
do a survey on how many functions actually use the delete-selection
property, or if some emacs oldbie can tell us that property's history.
Am guessing, these days, if elisp programer want the behavior of
deleting existing text selection in commands they write, a reliable
and easy and explicit way is simply to put in the code

  (when (region-active-p)
    (delete-region (region-beginning) (region-end) )
    )

instead of relying on delete-region property. I think elisp function
property is rather esoteric (e.g. it is not a feature in most langs,
and i don't think it is that much widely known or used in elisp) I
think i learned about it when diddling with cua-mode around 2007. The
fact i learned it i think introduced more trouble, because otherwise
i'd put the explicit code above and i wouldn't have posted this or the
bug report. (does anyone know a list of all built-in lisp properties?
(havn't spend any effort to search the manual...))

i think a good question is: from a core emacs developer's point of
view (such as Richard Stallman, or perhaps Drew Adamns and Llya Z. who
designed the system or know the core system well), would you advice to
actually make use of the delete-selection proprety or just use the
explicit code above?

 Xah

RE: can a command specify overwrite selection behavior?

[Drew Adams]

> how many functions actually use the delete-selection property,...
> Am guessing, these days, if elisp programer want the behavior of
> deleting existing text selection in commands they write, a reliable
> and easy and explicit way is simply to put in the code...
>     (delete-region (region-beginning) (region-end)))
> instead of relying on delete-region property.

Yes, if you just want to delete the region in Lisp code, use `delete-region' (or
`kill-region' if you want to put it on the `kill-ring').

Property `delete-selection' is only for `delete-selection-mode'.  (But nothing
prevents anything else from (ab)using it.)

Delete-selection mode is for _interactive_ deletion of the active region.  In
particular, it is for use by _keys_ bound to commands that are associated with
the `delete-selection' property.

That's the aim of delete-selection mode, IMO.  The idea is not to delete the
region whenever the particular command (function) is invoked, or even whenever
it is invoked interactively (as witnessed by your `M-x' trial).

The idea is to make certain _keys_ delete the active region before doing what
they would otherwise do.  It's about interactive editing using keys.  In
particular, it's about letting new text you type overwrite text you have
selected.

You tried testing your command `insert-date' wrt property `delete-selection' by
using `M-x'.  That's not how delete-selection mode is used (intended to be
used).  The behavior surprised you in your testing, but that was only because of
misunderstanding how `M-x' and `delete-selection-mode' work.

The behavior of _keys_ bound to commands that have a `delete-selection' property
is generally _not_ surprising.  When you tested your command the way users would
presumably use it (bound to a key), you saw that it works.

> I think elisp function property is rather esoteric (e.g. it is
> not a feature in most langs,

Lots of things in Lisp are not features in most languages.  Symbols (in the Lisp
sense) are among them.

In OOL you don't think it is weird for an object to have attributes or
properties, or to have certain possible behavior definitions attached to it.
Well, that's the kind of thing that's going on with Lisp symbols.

Symbols are particular kinds of objects.  They can have various properties (in
the general sense, some of which are symbol properties in the Lisp sense): name,
function cell, value cell, property list of additional (including user-defined)
properties.  In general, the value of a given symbol property can be any Lisp
value.

> would you advice to actually make use of the delete-selection
> proprety or just use the explicit code above?

The `delete-selection' property is for `delete-selection' mode.  My
recommendation would be to use it only for that, its original purpose.  It
provides a way of attaching particular additional behavior (delete/kill the
active region) to particular commands.

Not every command has an associated symbol (a command can be anonymous), but for
a command that is the value of a symbol's function cell, that symbol can serve
as a handy place to attach info that you ultimately want to associate
(indirectly) with the command.

Delete-selection mode uses property `delete-selection' to define some
additional, region-deleting behavior to associate with a command.

That use of a symbol property is one way to modify a command's behavior in a
predefined way (limited choice of predefined behaviors defined by delsel.el).
There are other ways to modify a function's behavior, of course, including
`defadvice'.

Instead of attaching the behavior change to a command in order to manifest it
for a key, one could imagine attaching it more directly to the key.
Delete-selection mode is one way to get the job done of making certain keys
delete the active region.  One could imagine other ways.  There is nothing
sacred about delete-selection mode.

Symbols and symbol properties are powerful parts of Lisp.  But to use them you
need to keep in mind that a symbol and its function-cell value (and the other
property values) are not the same thing.  Similarly, a command and a key that it
is bound to are not the same thing.

Because of these differences there are lots of possibilities of dynamic
attachment, lookup, indirection etc.  And whenever there are such differences
there is also the possibility of a mismatch or confusion.

Add to this the historical/time component of user interaction (command history),
and you get even more possibilities for mismatch/confusion.  Add in the use of
hooks and you get still more.  The more possible attachment points, the greater
the possibility of inappropriate attachment or detachment.

Re: can a command specify overwrite selection behavior?

[Stefan Monnier]

> This behavior is _by design_.

No, it's because of the implementation: a pre-command-hook.

That's one of the reasons why I wanted the shift-select code not to rely
on this-command and things like that, but be triggered by explicit code
in the interactive spec.


        Stefan

RE: can a command specify overwrite selection behavior?

[Drew Adams]

> > This behavior is _by design_.
> 
> No, it's because of the implementation: a pre-command-hook.

To say that (implementation vs design) is to claim that the implementation
somehow mistakes and does not follow the design.  As there is no explicit design
document separate from the code, we cannot make such a distinction.

We can only infer the design and intention from the code itself, code comments,
and some idea about the implementors.  `delsel.el' was written by Matthieu
Devin, a longtime XEmacs developer who worked on the original Lucid Emacs
development.  (I do not know him; I just googled the name from the source file.)

I would seriously doubt that Matthieu was not aware of the subtleties of
pre-command hooks, `this-command', and `last-command'.  My bet is that he opted
for this design with cognizance of any limitations.

Whether his choice is the best one for delete-selection can of course be
questioned, but I see no reason to claim that the implementation does not fit
the design, that he didn't code what he intended.

It appears on the contrary that use of a pre-command hook is the way
delete-selection mode was designed and implemented from the outset.  It is not
some implementation detail that somehow deviates from the chosen approach.  It
is the approach (design and implementation) that was adopted for
delete-selection.

The design could have been different.  And it could always be changed.  But that
was how delete-selection was meant to work AFAICT - with the attendant
limitations of such an approach (which I pointed to).

> That's one of the reasons why I wanted the shift-select code 
> not to rely on this-command and things like that, but be
> triggered by explicit code in the interactive spec.

Arguing that a different approach would have been or would now be better could
be a legitimate argument.  It is not legitimate to argue that this is somehow an
implementation bug, something unexpected or not understood by those who built it
the way they did.  Unless you can show that they didn't know what they were
doing.

I made several references to the limitations of using a pre-command hook and the
inherent problems of simply comparing `last-command' and `this-command'.

That there are such limitations does not mean that the delsel code is not acting
as it was designed.  And it does not mean that delete-selection mode misbehaves,
not doing what its users expect.  It means that those limitations were accepted
from the get-go and are inconsequential for the intended use.

I haven't seen any argument to the contrary, any demonstration that the chosen
design/implementation does not DTRT wrt the intended use.

Every approach has its strengths and its weaknesses.  Late binding, indirection,
procedural attachment, etc. always bring with them possibilities of dislocation
(and sometimes inefficiency), even as they can sometimes offer convenience or
added flexibility.

But let's be clear that delete-selection mode is about the behavior of
interactively using keys to edit text.  That is all that it was meant for AFAIK,
and that is all that the `delete-selection' symbol property was intended for.

Given that as the use case, the existing design does its job quite well.  About
the only real limitation wrt its use case is the inability to use an anonymous
command (since it uses a symbol property).  And that's a negligible case, IMO.

No bug has been shown here regarding delete-selection mode.  The code that Xah
wrote works fine.  He just did not understand that it should be tested the same
way it will be used: bound to a key.  His command shows no behavior that its
user would find surpising or unwanted, assuming that it is intended to be
invoked from a key.

It is not a _bug_ that you do not always and necessarily see the same behavior
invoking or evaluating something using `M-x' or `M-:' or `pp-eval-expression' as
you do invoking or evaluating the same thing non-interactively from Lisp.  These
are different things, and it is normal that they can sometimes have different
behavior.

That was the question raised in this thread: whether it is a bug that `M-x
COMMAND' can sometimes behave differently from COMMAND invoked from a key
binding.  In particular, a command with a `delete-selection' property.

Delete-selection behavior is not intended to be used from `M-x'.  That would be
silly - I see zero argument supporting such a use case.  No design bug here; no
implementation bug.

Re: can a command specify overwrite selection behavior?

[Stefan Monnier]

> Arguing that a different approach would have been or would now be
> better could be a legitimate argument.

I prefer it, but both approaches have their advantages, so I have no
intention to claim that one is better than the other.

> It is not legitimate to argue that this is somehow an implementation
> bug, something unexpected or not understood by those who built it the
> way they did.

Neither did I say it was an implementation bug.  What I said is that it
is a limitation due to the implementation technique, as opposed to
an explicit goal of the design.


        Stefan