>On Fri, Sep 07, 2001 at 11:19:18AM -0500, Jeremy Nelson wrote:
>>>I wished that autocompletion to be context-dependant
>>>(nickname, command, command arg, channel name) as in irssi
>>>and worked in vim-style (sequensially substituting in editline,
>>>instead of listing all choices)
>>>
>>>Should it better be implemented in code (as context_completion command)
>>>or in script ?
>>
>>This is by policy the responsibility of a script to do this.
>What and where are those policies ?
Ok, Ok. So maybe "policy" is the wrong word. "Agreed upon principle"
is more precise. Here are the principles:
--- snip here ---
* Functionality with no excuses: If what you want to do is allowed by
the protocol, is reasonable to implement, and isnt soundly hated by
all the other users, we'll do it (eventually). EPIC does not stop you
from doing something just because i, or someone else, thinks that you have
no business doing it. We try to not let EPIC get in your way. Many times,
due to time (or interest) constraints, a perfectly good feature goes
un-implemented. Self-initiative (eg, code it yourself, send me a patch)
goes a long way towards getting your features into release quickly.
* Remaining an attractive replacement of the stock client: One of my running
primary goals is to reduce the CPU usage of the client. By all accounts,
we have been very successful doing this. We have made sure to balance this
goal as much as possible with not letting memory consumption get out of
control. We have tried to fix bugs and design deficiencies in the stock
client without introducing unreasonable restraints on the users. Taken
altogether, EPIC is intended to be as sysadmin-friendly as the stock client.
EPIC is neither "more user friendly" or "less user friendly" than the stock
client, but it is *much* more "scripter friendly".
* A almost-completely open design environment: For the sake of efficiency,
i do the release engineering. Because of various contraints on my time,
i am not always able to do releases as often as users would like me to,
but *everything* i release to anyone, i release to *everybody*. No release,
no matter how small, is withheld from the public. I gladly take suggestions
from users, and almost all new features/functionality are direct user
requests. I IRC frequently and am often available for direct conversation.
I try to (as much as possible) release something at least once a week, and
when development is cruising along, can release once per day.
--- snip here ---
"Functionality with no excuses" covers the principle that EPIC's job is to
provide tools and your job is to put them together the way you need them.
EPIC has from the day it was created been about *scripting* -- and I don't
expect this to change any time soon. ;-)
Jeremy
_______________________________________________
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list
