Source

Kephra / lib / Kephra / Philosophy.pod

=head1 Kephra Philosophy

=head2  Principles

=over 4

=item * easy to use

=item * more power with less effort

=item * automate everything

=item * extensible on many levels

=item * full introspection

=item * all parts work together

=item * beautiful in all details

=back


=head2  Explanation

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.


=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.



=head2  Strategies

To

=head3  TIMTOWTDI

=head3  Plugins

 (no pluganization)
 
 

=head2  Why Perl

=over 4

=item * flexible, human friendly syntax

=item * has very good native Regex support

=item * mature technology

=item * CPAN

=back


=cut