Re: How to develope wily?

hi tommy:

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

there is really no master plan for the current wily. there are
a few acme compatibility glitches and font issues that should be
addressed. yes there has been some spotty unreleased development
on it. i got distracted for a while with a derivative that is now
abandoned. if you have enhancements that you feel the community
(such as it is :) would want, we can discuss that. i still owe
everyone a fully-patched next version.

> 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?

whichever is easier. 9lib needs quite a overhaul as you have
read in the past to support fonts properly etc. that is a lot
of work, but switching to acme libs is also non trivial.

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

i don't really care for autosave, and i almost never lose any edits
because it is so trivial (and automatic for me) to save work.
but if everyone wants such a thing...

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

ok.

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

have you looked at how this is handled in acme?


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

you know we have given some thought to adding a more comprehensive
extension languge to wily to take care of some of these; i had a
version with tcl (long time ago when tcl was actually tiny)
working... i am not sure what the right answer is. i am not
interested in ad-hoc solutions, and am not interested in sticking
a monstrous language interpreter into wily... but if you have a
well-thought-out scheme, my mind is open. 

> 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?

i do not think sam code will graft easily, plus i do not like
that code, no matter who the author is (rob :). i started writing
the edit function from scratch, but could not work on it for over
a year.

i'm glad you are enjoying wily. if you are interested in doing
some fresh work, i'm interested in anything that does acme as well
as the unix port or better. i am not interested in changes that
confuse plan9/acme community any more than we already have. (many
plan9/acme users have expressed frustration in the past. go take
a look at plan9 archives...)

cheers.

oz