=head1 Kephra Philosophy
=head2 Main Principle
Is simply freedom. Because even programmer are a human beeings first
and inherently want to feel free, joyful and creative (productive).
And you are not free if it doesnt run on your operating system,
is gigantic in proportions, slow, has a lot dependencies
or can't just be copied around.
The usage is also crippled if important features are missing or
you have to use or learn something you don't want to.
The beginner is glad to do his stuff by simple and visually assisted methods.
But experts are only happy when they can control every detail and powerful tools
let them achieve their goals as fast as they think. True freedom includes both
and a smooth path between them.
Freedom also means not to get stuck in old ways,
but also discover unheard solutions, not being afraid to change things.
And the full delight can only manifest if it's pleasant to look at.
Aiming toward less code and only necessary functions is first the first rule
for several reasons. Yes it is the basis for a small, fast and maintainable
program. But also the only option since our dev team is frankly basically me.
Nonetheless all the tools you need should be on your workbench.
Either provided my Kephra or well integrated, originating from third party
software or the operating system. This enables uninterrupted workflows and
functions that solve complex tasks at once.
Kephra makes it easy to integrate your favorite program too.
Even if its tempting to fulfill many needs with very little effort,
we don't want to open many construction zones. Working at one problem at a time
enables us to see it from many angles and be more creative with the solution
which will fit better with all other details and can be left untouched till
several pressing needs push us in the right direction for the next level.
Most of the time the program will appeal much more mature.
Because programmer spend so much time with their editor
it should match their individual preferences.
Thats why most features and visuals can be disabled and configured
via a typed commands, a dialog and config files.
Yet many setting can changed most quickly in place of their display by mouse.
For deeper modifications theres is an extensive plugin API.
But basically any internal function can be called at the own risk,
since it's all plain Perl, the language that also supports your favourite
programming style. For most radical changes I would not agree with -
make a fork. The license (GPLv2) gives you all rights you want, except
to publish your alternative version with less rights for others.
hg (what we use) or git
The main idea is verly perlish:
be friendly to the starter and the expert at same time and build
an approachable path between both states without giant gaps.
Starter need something like a notepad or textfield in the browser
with sane defaults that make most explanations superlfluous.
Experts want power to do more with less, change quickly between proven presets
and tweak their tools for the current task.
Beside that two categories people are very different
and a tool they spend so much time with should look and behave exactly
how they prefer for maximal joy and productivity.
Even thatswhy every feature should be optional, configurable and extendible.
But there has to be a common ground - some simple rules,
that can guide you everywhere so you need much less documentation.
We dont try push every function into plugins but tend more towards a thicker
core, which parts are well tuned to act together.
This will not only give a better user experience,
but also helps code reuse and leads to a smaller, faster and safer program.
And with todays VCS like hg (what we use) or git you already have
decoupled development and a much lesser need for separation in that field,
than with centralized version control systems.
Nevertheless in case you want to add completely new features, we support plugins
with a wide API and if you brave enough: call every functon the program has.
Thats possible because plugins are written in same language as the app.
To have less visual clutter and reduce the amount of the extentions,
we look at what greater purpose serve several parts like shell extention and
compiler-output and vi-like commands and created one place to communicate
with whatever, called IO unit. And surely you can extend it for speaking
to your favorite tool too.
Talking with the outside world is important because often you have to to
solve your task and we just can't rebuilt any important software,
but prefer to concentrate at what were good at - writing a fast yet powerful editor.
At a core an editor is a control center for information.
The infos should be sucked from any source, transformed and stored,
so you can find it easily - no matter if you want to write a program,
tweak the configs on a server or push a command to your OS.
For that reason we plan for a mighty snippet library, that not only holds
chunks of text to be inserted in you current document.
These snippets can also be executed by any software e.g. as shell scripts,
web pages or Kephra macros.
like typing, cursor and pointing at things he can see
can only feel free with powerful tools at their fingertips,
that might even change the fabric of the software itself.
=head2 Long Explanation
I started from the awareness that one editor was missing features,
another was too klunky, ugly here, unorganized UI there, slow,
painful key bindings, ... So lets start another half baked project, right?
Because there is nowhere a platform you seriously can build upon the perfect editor,
sensible tradeoffs are unavoidable.
=item * easy to use
=item * all basic tools included
=item * more power with less effort
=item * can automate everything
=item * extensible on many levels
=item * full introspection
=item * all parts work together
=item * beautiful in all details
=head2 Why Perl
=item * flexible, human friendly syntax
=item * has very good native Regex support
=item * mature technology
=item * CPAN