8/2 State of the Edwin, many questions

[Jim Shargo]

We've been stoking the fire beneath Edwin for the better part of the
summer, and we're really starting to see steam. We're on the cusp of
getting fundamental mode loaded in and worked through. This is going to
come in probably three stages:

* Establishing comtabs, modes, and keystrokes to the point where they
will support fundamental mode
* Ensuring working consistency in our scaffolding and cleaning it up for
the spotlight
* Implementing the actual functions run by keystrokes

It seems like the ideal path to a working Edwin is:

* Decide on a standard for documentation
** This is pretty much a PRIORITY-1 issue that will open up this project
big time. Should we settle on detailed file headers, contracts/details
on critical functions and types?
** Is http://goo.gl/xwWq a decent standard for writing commits?
* Make documentation and big-fix passes on keystrokes
** There are a few major bugs we need to beat down in the keystroke
implementation before it's ready for prime time. For instance, the
contract for a key-value is that it's either a string or a symbol.
However, make-key and kbd produce character key-values and sometimes a
value happens to be recursive. More on that when I isolate the problem.
** Professor Shivers believes that having a fixed set of symbol-keys
might be ideal... however, I believe that is not necessary. What are the
feelings of the group on this?
* Test what we get from this to hell
* Once we have a (kbd ...) interface to Edwin, either port the tterm.scm
file to Duncan's termcap library or scrap together a blind-man's interface.

And then the world is our oyster. Once we have that, we're open to most
anything. I'd suggest building up the rest of the editor--file IO,
frames, windows, the rest of buffers... and only then moving on to a
display system or two. Somewhere in the mix, we should really put a day
in and do the restructuring business once and for all. We could put a
few days in and, now that we're much more comfortable with everything,
make documentation passes as well.

Thoughts? Please share!

-- js

[Jeff Dlouhy]

> We've been stoking the fire beneath Edwin for the better part of the summer,
> and we're really starting to see steam. We're on the cusp of getting
> fundamental mode loaded in and worked through. This is going to come in
> probably three stages:
>
> * Establishing comtabs, modes, and keystrokes to the point where they will
> support fundamental mode

I hacked on this for most of the day sunday. I noticed that you were
not loading in edwin:command-tables alongside edwin:modes. This is an
initially challenging problem defining the structure for it, since
they are both mutually dependent. You need to use 'define-structures'
(note its plural) and then it will work. I will commit my changes
tonight. But here is what it will look like (note this is slightly
different from the one I'll commit):

;;; From edwin48/tests/packages.scm
(define-structures
((edwin:command-table edwin:command-table/interface)
(edwin:mode edwin:mode/interface))
(open scheme aliases edwin:command srfi-1 srfi-69 srfi-89 srfi-78
define-record-type* errors keystroke aliases keystroke-discloser
edwin:string-table edwin:doc-string sorting)
(for-syntax (open scheme macro-helpers))
(files (scsh macros)
modes
comtab))

> * Ensuring working consistency in our scaffolding and cleaning it up for the
> spotlight

I'm not sure I understand what this means? :-P

> * Implementing the actual functions run by keystrokes

Most of these are done aren't they?

> It seems like the ideal path to a working Edwin is:
>
> * Decide on a standard for documentation
> ** This is pretty much a PRIORITY-1 issue that will open up this project big
> time. Should we settle on detailed file headers, contracts/details on
> critical functions and types?

I couldn't agree any more with you. I don't have much trouble getting
back into the code after a period of time, but thats since I've lived
with the code for a while. There are a lot of things though that
require background knowledge that are not apparent from reading the
source (i.e. bucky-bits, MIT-Scheme's code walker, Emacs conventions,
ect)

Last summer I asked Eli about how portable PLT's Scribble
(http://docs.racket-lang.org/scribble/) is and he said that its not
portable between Scheme's yet, but wouldn't mind if someone made it
so. ;-)

Nonetheless we should figure out on some syntax that might be suitable
for something like Doxygen or Scribble. Unlike Emacs, our source is
ironically not self documenting.

> ** Is http://goo.gl/xwWq a decent standard for writing commits?

Sounds good. I think thats what we've been doing for the most part.

While we're on the subject of conventions, lets all make sure we have
these settings in our .emacs:
(setq-default tab-width 2)
(setq-default indent-tabs-mode nil)
(setq-default show-trailing-whitespace t)

Also 'M-x untabify' 'M-x delete-trailing-whitespace' anything you
might have that has tabs (I came across a few yesterday)

Another tip for auto-formatting is to select a S-Expr and hit C-M-\ to
do auto-indenting, but don't trust it blindly for things like project
files.

http://www.emacswiki.org/emacs/AlignLet - Is also a nice little helper.

> * Make documentation and big-fix passes on keystrokes
> ** There are a few major bugs we need to beat down in the keystroke
> implementation before it's ready for prime time. For instance, the contract
> for a key-value is that it's either a string or a symbol. However, make-key
> and kbd produce character key-values and sometimes a value happens to be
> recursive. More on that when I isolate the problem.
> ** Professor Shivers believes that having a fixed set of symbol-keys might
> be ideal... however, I believe that is not necessary. What are the feelings
> of the group on this?

Most of the trouble I ran into yesterday was also with keystrokes. I
am punting this one to Duncan since he knows the most about the kbd
macro. I think that this is a small hurdle that will get
fundamental-mode working and then a lot more of the system going.

> * Test what we get from this to hell

Look at my test directory, there is already some setup for a basic
tester using some off the shelf srfis.

> * Once we have a (kbd ...) interface to Edwin, either port the tterm.scm
> file to Duncan's termcap library or scrap together a blind-man's interface.

I have not looked at this too closely.

> And then the world is our oyster. Once we have that, we're open to most
> anything. I'd suggest building up the rest of the editor--file IO, frames,
> windows, the rest of buffers... and only then moving on to a display system
> or two. Somewhere in the mix, we should really put a day in and do the
> restructuring business once and for all. We could put a few days in and, now
> that we're much more comfortable with everything, make documentation passes
> as well.

Since I've been 2,700 miles away, I must have missed this
restructuring talk. Can someone fill me in or point me to a e-mail I
might have overlooked?

Things are winding down for me at Apple, so I now have some time to
devote to hacking on Edwin. Sorry that I've been MIA lately.

- Jeff

[Jeff Dlouhy]

I committed some initial cleanup I did for getting more of fundamental-
mode working. I still have some other modified files that has gotten
me further along, but they are not in a ready state at the moment.

I know most of you are running nuscsh, but I've found that by eating
our own dog food and using Roderic's scsh 0.7 has been really helpful.
It gives a lot more insightful errors and makes it a lot easier to
track down bugs and see where you are duplicating imports in packages.
If you have some time, try setting it up as long as it does not
completely hork your system.

Keep up the great progress guys!

- Jeff

[Duncan Mak]

On Wed, Aug 4, 2010 at 12:17 PM, Jeff Dlouhy <jeff....@gmail.com> wrote:

I know most of you are running nuscsh, but I've found that by eating
our own dog food and using Roderic's scsh 0.7 has been really helpful.
It gives a lot more insightful errors and makes it a lot easier to
track down bugs and see where you are duplicating imports in packages.
If you have some time, try setting it up as long as it does not
completely hork your system.

If Roderic could get the TTY stuff ported over, it will probably be enough for us to move over; until then, we can't use it because we will need the TTY functionality to read from the keyboard.

Hmm.. or do we? Is READ enough for reading something like (kbd (ctrl x) (ctrl c)) ?

--
Duncan.

[Jim Shargo]

I merged my repo with Duncan's--including Jeff's most recent
commits--and I'm now hosting my branch on github:

http://github.com/mustermark/edwin48

You should all be able to add it as a remote, merge, checkout and diff
to your heart's content.

On 8/4/10 12:17 PM, Jeff Dlouhy wrote:
> I know most of you are running nuscsh, but I've found that by eating
> our own dog food and using Roderic's scsh 0.7 has been really helpful.
> It gives a lot more insightful errors and makes it a lot easier to
> track down bugs and see where you are duplicating imports in packages.
> If you have some time, try setting it up as long as it does not
> completely hork your system.
>

I spent an hour or two trying to get this set up, but I had no luck.
It's throwing me into terminal-support. Halp?

-- js