Source

Kephra / lib / Kephra / Philosophy.pod

=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 methods like
typing, cursor and pointing at things he can see.
But experts can only feel free with powerful tools at their fingertips,
that might even change the fabric of the software itself.
And for the beginner again has to exist an approachable path
to become an expert.

Freedom also means not to get stuck in old ways,
but discover alwas better solutions and not being afraid to change things.

The full delight can only manifest if it's pleasant to look at. 



=head2  Strategies


=head3 Simple

Aiming toward less code and only necessary functions is first the first rule
vor several reasons. Yes it is the basis for a fast, small, clean
and maintainable program. But also the only option since our dev team
is frankly basically me.


=head3 Complete

Even if its tempting to fulfill many needs with very low 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.
That 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.


=head3 Integrated



=head3 Beautiful

details
free software



=head3 License



=head3 Extensible


=head3 meta

=head3 integrated

=head2  Details

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  Goals

=over 4

=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

=back



=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