How to develope wily?

I am thinking about maybe hacking a little on wily (and its
supporting libraries).  There are some things I want to try
and change or improve (to my taste).  I figure at least some
of it may be stuff that other wily users want too.

Is there some sort of master plan for wily's future
development?  I have skimmed through the latest five or so
years of mails on this list, but I couldn't find out if there
is active development going on right now and if there is a
development version of wily somewhere.  I assume this list
is where to coordinate development.  So shout if you think
any of the following is stupid or could be done in a way that
better suits you/others.


What lib: I understand that the old (pre-lib9) libraries
in the latest "official" wily-0.13.41 are being obsoleted.
And wily is not (yet?) ported to the new libdraw &al that
came with the porting of acme to unix, right, so it will
not be a total waste if I happen to make some improvements
to lib9?  Or should I definitely be helping in porting wily
to libdraw instead?

Autosave: One feature I'm thinking of implementing is autosave,
so I can safely "debug" and hack wily at the same time.
I hope I can extract and reuse the auto-backup code, and make
it autosave dirty files in a $WILYSAVE dir every 30 seconds
and as the first thing in all "immature" code.

Locale: I want to try and code the acme "Locale" command
for wily, so I can change cwd and $PATH (among other things)
in a running wily session.

Clicking B2 on (for example) Snarf gives poor feedback.
A tiny dot swiftly flashes behind the large pointer.  This is
really a problem with my mouse, since the snap in the mouse
button should be enough, but my B2 is a scroll wheel, and it
often snaps even when it fails to actually generate a click.
I want to try and reverse-flash or underline-flash the whole
command selected by a B2 click.

About tab stops: At present tab stops are closely tied to
the font in use (not just in their width); if I change font,
some tab stops might snap to the previous or next position.
This is annoying when trying to keep text aligned.  I want to
try out another way to calculate tab stops.  First calculate
tab stops as in "normal" cursor addressed tty:s, by counting
chars (and expanded tabs) from beginning of line and rounding
up to next tab stop char position.  This char position is
independent of font metrics.  Then calculate the x-position
of this char position.  Fixed fonts are easy and will behave
just the same.  For variable fonts one can use the width of
`0', or have chars_per_tab and tab_width, and do (char_pos /
chars_per_tab * tab_width).  In some cases it will end up
at an x-position before or very near the current x-position.
Then a minimal tab skip has to be used instead, and at this
particular point with this particular font the tab will be
unaligned.  But apart from that, all alignments will be the
same whatever font is being used.

Files with a `:' in their name doesn't work with B3.
I want to try and fix this.  I have a lot of such files in
my maildir-formated mail directories.

Selection of B2:  B2 behave like double-clicking B1, except
it never gets whole lines or whole delimited expressions.
I think it would be nice to write commands in a guide file
like [rm -rf], and than only have to B2B1-click the `r' or
']' to get the '-rf' without precision sweeping.  Likewise a
B2 click on the first char or after the end of a line to
execute a complicated grep|sed|foo expression would be handy.
But I see it's a convention that B2 at the end of the tag
line executes just the last word in the tag line.

Edit: Yeah, that would be nice.  I have tried ssam, but it
crashes with complicated commands, and it only works through
pipes on buffer contents.  It's unlikely I will code this
myself.  Has anyone looked into this; are there any free
source codes that can be cut'n'pasted, like (well) sam?


Well, that's a lot of cheap talking...  we'll see what I
get done.

This is my second go using wily.  I was not sufficiently
opened minded the first time, four years ago.  I have used both
Emacs and vi, each for over six years.  Emacs hurts my fingers
and lures me to edit and write at the same time.  Both emacs
and vi stresses my brain.  Yesterday I had my first exalting
experience with wily.  I am translating po-files to Swedish.
These files have a (loose) syntactical structure, and contains
strings in English and (varying in completeness) Swedish,
and also comments with file:row to where in the source code
the strings are used.  It's wonderful!  I can generate check
lists of lines for different tasks, like updated strings,
consistency and such, and work through them (from bottom and
up, not to invalidate line numbers as I make changes), save
and continue later.  Searching and cut'n'pasting glossaries
is just a click away.  And I get a tremendous overview thanks
to the tiled windows.


-- 
Tommy Pettersson <[email protected]>