Hello Abu!
Abu Unaysah <[email protected]> wrote:
|Peace,
And peace upon you.
..I looked at your website, and that made me realize again how
much i admire Arabic and Chinese/Japanese/ calligraphy! An act of
contemplation and devotion that brings up such beauty.
It is so deeply regrettable that the small craftsman cease in
favour of that global and efficient industrial dishwater, that all
those small candles get steamrolled, that so much knowledge is
lost. That mothers can no longer generate a valuable trousseau
for their daughters with the artistical work of their hands.
There can be no doubt we are guilty.
And that i'm illiterate, lazy and ignorant.
|There should be an option for the `write' command (w) to overwrite
|the destination file instead of appending. Either a `writeoverwrites'
|option or another command `Write' (W).
That indeed addresses a real shortcoming!
I'd go for `W' ^.^, but we already have `Save' and those three
(sSw) are in the standard...
Hmm. As a vim(1) user i'm used to ":w!" etc., what do you think
of a "!" command suffix, as in "w!" / "write!" / "save!" etc.,
which has the potential of being applicable to more commands as
time goes by, starting off with `write'?
It'll currently need a bypass-hack to implement this, because we
don't have "command contexts" that are passed around, but i think
it is well worth the effort. *Especially* given that attachments
that'll be written out currently simply overwrite the destination
without even asking any question, which actually has to be changed
for v14.9, too!
My idea would thus be: add a "!" command suffix, use it for
`write' immediately. If set, replace existing files instead of
appending to them. For attachments, ask in interactive mode
wether an existing file should be overwritten, default to "yes" if
the "!" suffix has been given, to "no" otherwise. In non-
interactive mode the defaults will be always chosen. I think this
should do no harm, the scriptability of S-nail is more or less
a joke at the moment anyway, hard to believe that change hurts
someone. What do you think?
|There should be a facility to pass arguments to definable macros.
|It would be nice to be able to do something like:
|
| define wm arg1 arg2 {
| !rm arg2
| w arg1 arg2
|}
Ah! That would be nice!! ó_ò
It is still a very long road until we get to something like this.
As of today i'm inclined to the view that extending macros isn't
really the way to go, because too much had to be changed: e.g.,
how to address only a specific header / attachment / etc., where
to put the output to, how to reintegrate possible changes? How to
handle errors correctly?
So at the moment i think that after the rewrite of the core
machinery, that hopefully ends up as v15, we will have some kind
of object based core. Then i come back to an idea i had many
years ago (but actually inspired from the Java JNI) and that Nokia
did for Qt more or less (i was too frustrated to really look back
then), and that is an export machinery for the internal objects.
So if we ever get there it should be easy to write bindings in,
e.g., perl(1), and to already ship with an optional Lua binding.
That will give the most freedom for users and allow them to do
about just anything they desire, and will also be the most
efficient way to do things. (But that is a long road.)
|so that one could work around the above `write' command shortcoming
|with:
|
| ~wm msgnum filename
And that would indeed allow multiple different approaches to solve
your problem, even if the core machinery is still too restricted
to do what you want to do, different to the macros-with-arguments,
as shown here. That is, if you have a Message object then you can
access the Headers object and the Body object and the Attachments
object directly and can furtherly dive into what you want.
So i think this has to be the way to go.
--steffen
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
__________________________________
[email protected]
