=head1 Kephra Philosophy
=head2 Main Principle
... is simply freedom. Because even programmers are human beings in the first
place and inherently want to feel free, joyful and creative (productive).
And you are not free if it doesn't run on your operating system ...,
or is gigantic, slow, has a lot of dependencies or can't just be copied around.
The usage is also crippled if important features are missing or
you have to learn something you don't want to in order to get your work done.
The beginner is glad to do his stuff by simple and visually-assisted methods,
however experts are happiest when they control every detail and achieve their
goals as fast as they can think.
True freedom consideres both types of users and a smooth path to become an expert.
Freedom also means not to get stuck in old ways,
but combine the best (not the most popular) ideas available and not being
afraid to make own inventions.
And the full delight can only manifest if it's beautiful on every level.
Aiming toward less code and only necessary functions is the first rule
for several reasons. Yes it is the basis for a small, fast, clean and maintainable
program. But also the only option since our dev team is frankly basically just me.
Because half baked solutions are not really enjoyable,
we try to develope our features to functional and visual perfection
before we publish them in a version marked as stable.
Thats why Kephra has very few open construction zones at a time.
Nonetheless all the tools you need should be on your workbench.
Either provided by Kephra or well integrated, originating from the operating
system or third party software. This enables uninterrupted workflows and
functions (or macros) that solve complex tasks at once.
Kephra makes it easy to integrate your favorite program too.
An editor should fully match all preferences of its user,
that spends so much time with it.
Several types of communication with the program (like notepad, vi, emacs) we
plan to support and most features and visuals can be configured and disabled
via a typed commands, a dialog and config files.
Yet many setting can be changed most quickly in place of their display by mouse.
For deeper modifications use the extensive plugin API, that can be even
left behind (with risk). There is no special plugin language - it's all Perl,
which also supports your individual coding style.
hg (what we use) or git
that integrate very well with the rest of the program.
For most radical changes - send a patch. And if that gets rejected - make a fork.
The license (GPLv2) gives you all rights you want, except
to publish your alternating program with less rights for others.
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