From: Stephen White <steve@...>
Date: 2000-11-09T01:08:16+09:00
Subject: [ruby-talk:6171] Re: Thoughts on a Ruby browser

On Wed, 8 Nov 2000 hal9000@hypermetrics.com wrote:

> Just a few thoughts.

That was a cool wish-list. We want a lot of things in common!

Here's my wish-list, unfortunately not as organised as yours. I've
cut and pasted the IDE specific parts from a couple of my projects,
so each paragraph may or may not have anything to do with the
preceding paragraph. :)

I hated cutting some of the ideas out, but I've tried to keep it within
some scope of the Ruby IDE project. I'd be interested in feedback on
how much you guys like these ideas, and which ones should be dropped
ASAP. :)

These are written as fairly readable notes to myself, not written
for a public audience, so please feel free to ask for clarification.

Here goes...

  Editor with knowledge of code, like a syntax highlighter on steroids.
  Syntax highlighting, code completion, code folding view is attached to
  Module 1's code view. eg, in high level view, set "IO view", then zoom
  into box to reveal details (eg, it's just a box with a name, then it's
  a box with a brief description, then it's a box with a long description
  (eg, document) then it's a box with an API listing, then it's in the
  editor itself with the code folds set to show the I/O routines, with
  all the non-IO stuff folded up.

  Language parser, which can extract information like lists of functions,
  function calls, which functions are called by what, what function calls
  a function makes, etc. this is used to implement language extensions,
  eg this is enough information to write macros that can automatically
  find every switch() statement, and parse through it to convert it to a
  if else if else if else if type statement. because the ability to write
  macros that understand the structure of code means it's just as able to
  convert existing code as it is to create new extensions

  eg, the high level viewer ('a') can use the parser engine to extract
  out short descriptions of the code so on mouseover on a node, it can
  pop up with the series of short descriptions derived from the #include
  file chain so I could mouse-over the "math" node, and be told by the
  #include files in it that the node is using IEEE specifications. I can
  zoom in and see that the module supplying the IEEE math functions also
  provides ISO functionality

  Test harness system. While you're writing a module, you specify the
  expected values (eg, NULL allowed? exp will never be 0, etc) and some
  sanity checks on the return value, eg, if you pass it "1", you should
  always get "4" in reply. just quick tests, like g_assert()'s in Gtk+

  Now, while you're editing the code, the test system can retrieve your
  cursor location to find out what section of code you're in. WHen you
  modify it, it can use the code parser to check if your modified code is
  currently syntaxically compilable. if so, it can compile your code and
  run the appropriate test harness against it. so while you're editing
  "fred()", it will continually be running your test harness against it.
  So while I'm editing the part of my code that displays a menu, every
  change I make to the code will show up on the screen straight away,
  without me having to do the compile/run/navigate to right
  bit/curse/edit cycle

  CM system. Hooks into CVS systems, but uses code parser to handle it
  intelligently. main problem with CVS is that it doesn't know what it's
  handling, so it can't perform the simplest sanity checks. CM system
  would also use editor to display differences in a collaborative manner.
  Eg, code becomes hyperlinked when there's a patch offered against it,
  or a patch would affect the code being referred to

  because the code parser can trace through the effects of changed code -
  eg, a function is no longer called, so that function becomes
  highlighted to show the patch change. The viewer would also be able to
  show the same thing on a wider scale - all programs that have
  highlighted functions can become highlighted themselves, so the little
  nodes in the high level viewer get highlighted too. so if I change a
  bit of core code, most of the tree can go red

  bug reporting system. Hooks into IRC, email, slashdot type webpage and
  bugzilla. go into an IRC channel, say 'I have a problem'. Get assigned
  a tag number, and when talking about it on IRC, can use the tag number
  to attach information to the question being asked. if the problem isn't
  resolved, all information on the tag gets posted to email. then any
  replies to that email can tag on more information, or just yak online.
  if the tag is still outstanding after a week or so, it can go onto a
  slashdot type web page which the developers can read. and finally, it
  can end up as an official bug on a bugzilla style system, which feeds
  into module 6 of 9 as a SPR on a section of code, as highlighted in
  blue in the code editor or high level viewer

  Attach Doom, IRC chats, mailing lists, newsgroups, bug reports, shared
  code viewing, relevant links, associated document, FAQ to modules. eg,
  if I'm editing regex.c of Ruby, if I select "chat" then I could talk to
  anyone else also editing regex.c in Ruby. This would be implemented by
  creating a #ruby/ext/lib/regex.c channel on an IRC server so it's very
  easy to do. if there's nobody there, I could switch to a higher level
  view in the code editor and try a chat there. Eg, I might find Linus in
  "linux/", but I would find Alan Cox in "linux/net".

  Or the lines between modules could be corridors, and the modules and
  structures in them could be rooms and features in rooms, so a goto
  would translate to a BFG 9000, then it'd be possible to play Doom in
  the code

  the concept of IRC channels applies to mailing lists too (could just be
  one mailing list with special subject headers), and the incoming mail
  could be fed into Module 5 of 9, creating highlights on the high level
  viewer for which sections of code have been commented on today

  The shared code viewing could attach the editors together, so someone
  could be in IRC chat and scroll around to show the people he's talking
  to the sections of code he's talking about, eg "hi guys, this is the
  bit that confuses me" <scroll scroll> see, where my cursor is.

  an interpreter, so it can run a program interpretively and capture all
  states and variable changes which show up in the code viewer as lines
  or colour changes. For profiling and debugging, I'd like to be able to
  do things like get a wrong result and have this dial on the window so I
  can wind the program backwards and forwards in time. So I can get the
  wrong result, say "show me all writes to this variable" and have a bar
  along the bottom showing me all the writes.

  Move mouse to window close box, chord middle/right to pop up hook menu.
  Hook menu will offer list of recent hook points, which will read
  something like "GUI, PROGRAM, OS", with submenus like "drawbox,
  drawtitle, drawwindow", "mainwindow, main, name", also informative
  hooks like "path, memuse, diskuse". Then I can hook my code in by
  intercepting drawbox and testing to see if PROGRAM/name is "xv" and
  it's inside "mainwindow". That way, I know when to interrupt and draw
  my own little box. List of hook points will be recent events, function
  tracebacks, status.

  Attach the function and command that changed the variable into the
  array[code] structure. This way, it's possible to see how something was
  calculated and how it came through the program. That would be another
  debug feature level, and would help a lot in being able to learn how a
  program was written as you can just click on the bit you want to know
  about and get a full traceback and which functions and what variables
  were involved in creating that display.

  As well as the idea for arranging programs in spreadsheet cells or in
  regexp statements, also allow programmers to lay out their code in
  shapes like in lines (a sequence of triggers with "pre-trigger" and
  "trigger" and "post-trigger" sections of code to be run), a spreadsheet
  of cells (eg, formulaes that use values from other functions, or mapped
  over a screen display with each pixel being a ray-trace thread), or a
  sphere of cells to model a silver ball in 3D, onto the physical model
  of whatever's being built, etc.

  Different colours can be assigned to symbols before a function, symbols
  after a function, function names, variable names, code near the
  beginning of a block compared to code at the end of a block, code at a
  deeper indent level, and so on. Put in some simple mathematical rules
  to keep the colours differentiated as they change, so the really bad
  settings can all be avoided. HSV?

  Carry the differences further, eg, maximise the differentiation between
  programming conventions, like caps first letter for Classes and little
  first letter for member functions. Also make differences very visible
  while typing a line with matching symbols ('s, "'s, etc, so it's very
  clear which inner phrase is being finished off. Also highlight the
  phrase the cursor is resting on.

  Make it very easy to hide and show types of comments so comments
  starting like "//3/ would be a level 3 comment, so take them out when
  viewing at level 2 or 1. Then this can be used to hide debugging code
  that pops up little windows when a test for "x < 3" doesn't get met. 
  Mark out this code by marking a set of lines as a Level (eg, 4). Allow
  an option where you can choose to save the file without any Level 3 or
  4 lines for compiling, so
  #ifdef's don't have to be used for eliminating debug code from the
  production compile. Of course, the editor will keep its own file so the
  lines don't get lost!

  Create a system where unconverted code can call the old function call,
  and new code calls the new function (of the same name) which then calls
  the old function with the required data.  This allows the old and new
  system to run in parallel with the same code. The old system provides
  the definitive output, and the new system is compared against it.

  Echo this in the editor by highlighting code needing attention (the
  function calls themselves are highlighted, not blocks of text).

  Make shortcut keys to different help screens, as I often want to be
  able to compare several sections of documentation by looking at them at
  the same time.

  Also allow to right click on a variable name and see what variables it
  can access and what function calls it can make.

  find some way of always keeping the program compiled while you're
  working on the source code. The compiler can indicate whether the code
  is compilable or not (or this could be built into the editor), and the
  program can be running in the background. The compiler/monitor should
  keep record of what inputs the program has received, to keep feeding
  into each re-invocation of the program every time the insta-compile
  succeeds. Programmer gets instant feedback on what his code is doing.

  Editor should be able to parse source code enough to identify poor
  programming practices, like using raw numbers instead of constants
  which have been defined in system files, passing large structures by
  value instead of by reference, or creating instantiations in the middle
  of statements (instead of assigning to a variable), possible buffer
  overflow situations, possible memory leaks, and so on.

  It is important in all of this that the editor should not impose any
  style or usability constraints. All information should be communicated
  without changing the user interface - eg, via change of colour or only
  showing when clicking on the section concerned, but not imposing any
  limits on how the code is structured or indented or typed.

  Text editor can also highlight levels of bracket indentation.

  Offer the facility to very quickly look up what the value of the define
  is, how a type has been defined, how a struct has been declared, etc -
  without having to look through the manuals.

  Also make it easy to link to other parts of the same document, so
  information can be repeated and yet only has to be changed in one
  place, which is made even easier by using the same external references.

  Editor should have insertable code fragments to do common jobs; eg,
  little skeletons for commonly called functions... eg, "open binary
  file" skeleton with the "fopen, fread, fclose" sequence and little
  explanations for each one. Do same for "select()" with polled or
  call-back variations, same for firing off a thread, piping to an
  outside program, etc. Also the same for accessing variables inside
  structures.

  Editor should be able to show psuedo-code, possibly automatically added
  by the insertable code fragment, instead of actual code and flip
  between them.

  Editor should automatically change all references to function names and
  variables when the original is edited, to allow easy renaming of
  things.

  Menu items along the top of a window is a common concept, and menu
  buttons are another common concept, so Microsoft wasted their time
  making menu items look like menu buttons. So this angle can be extended
  into a new concept; the more conventions that are made for common
  actions, the more efficient the interfaces will be. Eg; Holding down
  the right mouse button and flicking right could mean the same as "go to
  file menu", but holding down the right mouse button and flicking left
  could mean "go to document menu".

  Provide informational function calls to allow scripts to easily
  accomplish what's needed (eg, "goto variable definitions; insert
  'struct base *root = NULL'; find fred definition, change to 'struct new
  fred;'"). Also "was fred.equine used?".

  Map source code onto graphed representation, which can then have rules
  applied to prove safe usage (eg, file variable can impose the rules
  that it should always be opened first, can only be used by either
  printf or puts, not both, and should always be closed.

  Allow editor to mark dependencies in the code so if something changes
  then something else should change. So editor can highlight stuff that
  needs to be upgraded when changing a function or module.

  Lots of little keys to jump around, eg; jump to variable declaration,
  jump to beginning of loop declaration, etc.

  Helpfule shortcut would be to write the code, highlight it, then be
  able to press a "loop" or "goto" key and cursor up to the desired
  location, then the editor can put in the for/while construct, put
  spaces in the right place and format code correctly.

  Window and menu property editors and designers are available for GUI
  programming. Write one of these editors for C structures? So I can put
  up a structure, and see how well it links to others of its type or
  links to others of a different type, then make the editor churn out
  code for traversing it, sorting, searching etc.

  Should automatically include the right modules as functions are used.

  Example of called code having access to called code is to allow the
  called code to ask questions like "did you fopen this first?", sort of
  like compiler hints to find problems at compile time instead of run
  time like many of these problems currently are...

  For the document thing, the hyperlinks in the document should only pop
  up a brief explanation box, which can then be further drilled. The
  primary document is then primarily a viewpoint, expressed as a
  particular collection of references. This primary document is then in
  turn referred to by other documents. The referring document is the one
  that provides the brief explanation, and may only be a part of the
  referenced document.

  Should be able to place private comments on any document or web page
  that is persistent and will re-appear on the document the next time it
  is read (eg, like scribbling notes in the margins of a textbook). The
  comments should be sortable into categories, and accessed without going
  back to the document.

  The comment can be marked public or private, addressed to other people,
  and in general sent around like a post-it note version of email. Also
  has benefit of allowing people to write much shorter notes to
  themselves to remind them of things, as the note will be surrounded by
  the context.

  Books about programming languages and manuals are difficult to
  understand because they don't have any way of pointing to whatever the
  fuck they're talking about. Make it so that portions of an example (eg,
  bit of code, picture of object) are highlighted when the mouse is held
  over the relevant bit of text.

  This also has a benefit the other way; right clicking the example
  (example picture, suitably informed real picture, or GUI output from a
  program) can bring up the relevant portion of explanatory text. This
  means that I could right click on a close box and get a list of all the
  functions involved with it - eg, the GUI functions, the program
  functions, the hooked functions, etc.

  Have a glossary of terms, to apply invisible softlinks to all
  occurrences of those terms. Highlighted links should be visible for
  those the authors is recommending the viewing. Eg, I want to look up
  what "mutable" means in the Python documentation, but it would be
  distracting to hyperlink every occurance of that word due to the
  highlighting.

  Make the editor offer code formatting modes, like being able to move
  functions up and down or from file to file (will check prototypes and
  insert #include's as required), blocks of variable definitions up and
  down, and other common formatting changes.

  Also offer a range of very detailed formatting options, like whether
  you break after the return definition in a function. Could also offer
  style things like changing "while(1)"s to "for(;;)"s. Or display
  function definitions in K&R C style, while saving it as ANSI C. Or
  reverse an if/then/else expression.

  Don't present the options in a menu... put the cursor over what's wrong
  and select what options are available. The editor should be
  programmable, so extra code manipulation options can be added, like
  GIMP modules. Even if it's an arcane (eg, YAL) function, it can be
  added to the list of available options.

  Also offer colour highlighting, like put cursor over ()'s, and select
  "highlight" to highlight brackets, or do "if/highlight" to highlight
  flow control statements, or algebraic expressions. Or highlight the
  same type of code the cursor is over.

  Also offer option to remove stuff from the view. Stuff like error
  checks, the variable types in function declarations (just move cursor
  over variable in question to see what type it is, or position the
  cursor in the braces of a function call to see the parameter type
  expected and the parameter type being passed. Or can look at the
  #include structure to see how the overall code is joined together.

  Menu structure when clicking over an identifiable piece of code, eg
  over a left brace marking the start of a function:
    [Cursor/] over left function braces: [Colours/] [Increase]/[decrease]
      function braces highlighting
        priority
      [Format/]
        Space [before]/[after] left function brace [Move/] this function
          [up]/[down] one function To a different file [View/]
        [Fold]/[unfold] this [function]/[block] of code [Language/]
      Toggle enhanced switch (will tell you if can't disable) Put this
      function into [debug] mode View project #include structure
    [Run/]
      Run this function with parameters equal to ("fred", 1)

  The [Run/function] option above can be achieved by fast pathing the
  code through main onwards, each being called with the correct test
  parameters to properly set up the environment before calling the
  function that is being developed.

  Provide zoom-in and zoom-out levels on blocks of code. Eg, Zoom-out on
  error checking code, zoom-out on contents of if-then-else's, with the
  zoomed-out portion having a brief description. As the zoom-outs get
  higher level, the description of what was zoomed out will also be at a
  higher level. This gives a great way of zooming around a program at a
  higher level, and being able to drill in as desired.

  Allow programmer to write in psuedo-code as far out as they like, then
  let them flesh it out in real code while keeping the psuedo so the
  clarity doesn't get lost. Problem is that moving code out to functions
  introduces vagueness, so need descriptive label for function call (eg,
  sentence to name function, not word) or keep the psuedo-code.

  A new kind of website could be where new concepts are introduced as
  newsy tutorials. Eg, have Slashdot-like updates like "Perl: New Array
  Type Added", and the contents of the update will be an easy as possible
  tutorial on how to use the new feature. Also stuff like "Word: upper()
  macro being removed" and an explanation of how to work around it if you
  use that macro. Could also have a patch that will automatically go
  through existing code and highlight where the change could break
  something. Changes to distributions (eg, Debian upgrades to glibc),
  changes to existing hardware standards, new features in protocols, etc.
  Get this site noticed by submitting stories to Slashdot, with my
  profile linked back to the site.

  Any sufficiently complex problem has a number of ways of being
  approached. A program can be viewed as a set of files, a set of
  windows, a keyword triggered parser, or a syntax triggered parser, etc.
  There should be multiple ways of viewing source to reflect this.

  Replace "make" with utility that traces through C source to work out
  for itself what the dependencies are.

  Part of the problem with programming GUI interfaces is that the
  paradigm has shifted from single stream of execution towards a widget
  activated point of view, but editors haven't followed suit. Write an
  editor view that does, by taking a widget editor (eg, glade) and adding
  the ability to attach code to signals on a widget.

  Create a way of extracting library dependences out of source trees and
  create a graph of dependencies. That way, the impact of changes can be
  determined, and code patches can be sent out to auto-update code (eg,
  "every oldlibcall() is now newlibcall()" or whatever) and can goto
  places and print up recommendations for updating code.

  Before writing the editor, have a code viewer that enables the user to
  assign colours to things, to be able to trace back through the code.
  Eg, to find everywhere in the code where a value has been used (eg,
  want to know where in the code a return value from a function was used,
  where that value was stored and which functions use that value), so I
  can click on the function call and do "highlight retval" which will
  switch all the right areas to a readable but different colour scheme.

  Have the ability to zoom out so far back that it's possible to see all
  the lines of code at the same time (obviously not readable, just the
  colour schemes), plus the ability to have multiple files open at once
  so zooming out far enough will show the whole project in with all the
  requested colours. It will be possible to query "if I change this func,
  how much code will I have to fix up?" or "if I remove this value from a
  structure, how much code will I have to fix up?" and have a visual
  overview of the result.

  Also allow recognisation of functions and being able to group them into
  common descriptions, eg, all fopen, fread, fwrite calls are grouped
  into "ANSI C System I/O Routines" or all calls to maths libraries are
  grouped into "Math Calls, uses IEEE1234 calls" - the last portion is a
  contributed comment from the library the code is using, so each bit of
  the library code is able to provide a succinct description of the code
  being looked at. Able to zoom in and out to find the section that
  writes to the printer, and so on. So font functions and printer
  functions and so on can provide the brief "fonts, ID=gfont.
  licenses=GNU,BSD" and so on, all for free as the library provides the
  data. This will allow very accurate high level overviews of what the
  code does and how it does it, eg with what kind of function calls (does
  it use select() or a polling algorithm? How much of it is
  multithreaded?).

  These views of the code can be viewed with colour to show whether the
  result is good or bad according to a template criteria. Eg, should use
  g_vsnprintf calls instead of vsprintf according to Gtk goggles.

  Make it easy to go through colour schemes in the editor, or right click
  on text and arrow back and forth through different schemes, rather than
  an overly complex general purpose colour picking dialog widget.

  Make environment more dramatic, like new letters typed in get slammed
  in as words of fire, with smoke drifting up from the letters as they
  cool down into normal text. Rotate and tilt text, be able to back away
  from it and see other text files laid out in this 3D world.

  Map the classes to a Doom map, so it's possible to play Doom in the
  corridors of the class connections, with the room size being determined
  by the size of the code in the class. Design disagreements can be
  sorted out by fighting in the area of code being disputed.

  When typing a '(', make the editor auto-insert a ')' at the opposite
  bracing level. If the programmer types a ')' before then, then the
  auto-insert is cancelled.

  Handle brace balancing by having { automatically insert a } at the end
  of the current block, and } deleting the matching } of the preceding {.
    for { do {{{ ...   $  ...  {{          }}^ ........... }}}
    
  Allow multiple views into the structures like "network guy view of the
  world", where the directory structure presented to the user is trimmed
  down to only the stuff a network person would be interested in. Also
  allow for overlaid structures like "personal, network, default".

  Functions in classes should never call methods defined in its own
  public interface, as this ties the public interface to implementation
  details. Public interface should provide a service only.

  A structure navigator (eg, 'a'), with zoom in and zoom out capabilities
  (kinda like Nautilus). Easy to rearrange stuff, change views (eg, lines
  can be #include links, function calls, variable references, or any
  other form of interdependence)

  Zoom in and out of sections, have pre-defined views, eg view the code
  from a network perspective or a memory perspective

  Uses a background picture, so you can have an abstract picture of what
  you're trying to build, and place the code in the appropriate places.
  (background picture would obviously change for different views of the
  same code)

  Yal should run a function over and over again while its being edited
  (every time the syntax checks out that it's runnable, no errors, it
  should automatically compile and run while being edited) so the
  programmer can see the results of his changes, instantly.

  Yal should let you type in constants directly, then automatically
  abstract it into a constants database.

  Write a graphical debugger, that draws representations of what the
  program is doing. Eg, organise the standard libraries into banks of
  access points, and draw lines to represent the calls the program is
  making. Have multiple viewpoints to emphasise libraries under
  investigation, and other methods of representation to emphasise
  particular patterns of access. Eg, have accesses to libraries plotted,
  or program calls plotted, or thread paths or size of mallocs or size of
  parameters passed on stack (to spot where structs are being passed
  instead of pointers) or areas of memory that more than one thread
  access. Or draw program space with *.c files as objects, and draw lines
  for memory accesses.

  Memory leaks would be easy to spot as they would be drawn lines on the
  screen that don't go away, and where they're drawn from will identify
  the partner in crime. Or draw function calls to each other to show how
  tightly tied together certain functions are or what changes would need
  to be made in calling code if I wanted to change something.

  Also could do it from the system point of view and draw maps showing
  all programs swapping around in the MMU and page-faults and IRQ lines
  and average queue lengths.

  Yal could implement drag-drop programming by dragging connections to
  the desired sections, which would insert the correct function calls and
  the correct variable declarations, initialisation calls, and all that
  gumpf. The programmer then just sticks all the stuff into the right
  order and glues it together.

  Allow the programmer to write code testing for what conditions he wants
  to know about, and the editor can rewrite this into callback stubs that
  performs the masking in the right order so having so many concurrent
  tests for events doesn't translate into a slowdown. Plus this also
  simulates the ability to embed code into your function calls which the
  remote end runs rather than internal to your own function.

  For the editor, a useful function would be to make relevant lines also
  come up on the screen when some text is visible. Eg, inside a function,
  relevant lines like global variables, function declarations or a link
  to relevant documentation, could be visible in another window.

  This can be implemented as manual links across to start with
  (especially to cope with the documentation part), then the parser can
  start including function declarations and external functions used and
  global variables used in addition to the manually added references.

  The editor could have localised undos... eg, you can edit code and each
  displayed function would be in its own undo region.

  Perhaps programmer could write variable accesses (eg, array or
  whatever) and then have pull down menus of what kind of data structure
  they want behind that access. Eg, linked list for slow but easy to
  insert, or hashed for fast but chews up a lot of memory.

  Also make it possible to point to the data element you want and get the
  address for it, so programmer doesn't have to mentally navigate the
  variable types to get what they want.

  editor can do smart paste, putting variable declarations up with the
  variables and code where the cursor is, and depending on the settings
  on the code, copy the beginning stuff to the beginning and end stuff to
  the end.

  Make it really easy to temporarily output or monitor variables with
  full identification while developing code. Eg, a macro or something.

  It should be possible to identify where in a program it will write to a
  particular data location. It should then be possible to click on the
  data location and get a list of all functions that read/write the
  location.

  Have ctrl-tab and shift-ctrl-tab to make cursor jump around in editor
  like alt-tabbing between windows. Have "new" and "delete" cursors, and
  also allow ctrl-tab's to jump between files.

  Plot function calls as a connected graph, then zoom in and out of the
  project. Plot on data access as well for multiple views of the code.

  Place information tags on sections of code, so it's easy to see what
  the code does from a high level to work out which section of code to go
  into. Eg, maths library can add a label to the overall description to
  say which maths calls are being used. So at a higher level, a block of
  code which contains other blocks of code will have a tag like "File
  I/O, select() calls, TCP/IP calls, sets NO_DELAYACK".

  Make it possible to move viewpoint along code streams, rather than
  expanding and collapsing lists (very unintuitive interface!).

  Another editing function... point at a variable and convert its method
  between singly linked lists, doubly linked lists or other data
  structures by finding all references to that variable and renaming the
  function calls to the data manipulation routines and replacing them
  with another.

  After typing a variable name, there should be a popup to show what type
  it is or whether it will be a newly created variable. After the ='s,
  popup should show functions that return the same type. After function
  name is typed, popup shows current parameter type and variables and
  functions that have matching function types. Have tab completion and
  all that too.

  Have different ways of drawing data structures, eg binary trees. Plot
  out a representive sample of the tree, then plot out in a different
  colour when there is something there. The view should be 2D to start
  with, but 3D could be used later. Could draw as 2D with the 3D lists
  being drawn too close to read, then zoom in and swivel to see the list
  properly. Zoom in can offer the option of switching to a more local
  view with more detail too.

  Embed questions/answers from mailing list in source code itself, to be
  extracted out into document.

  In editor, highlight all other instances of word under cursor (eg,
  variable name, function call, etc. Also do lesser highlighting of same
  families.

  Just drawing function relationships isn't enough. Should be able to
  bring up diagram, drag functions around, and have these changes saved
  into the source code (eg, comment after function) or into some project
  file.

  The way to implement real time debugging as you change the text is to
  perform a editor level syntax check, compiling and running over and
  over again every time there is a change that is syntaxically correct.
  The result is kept displayed in a window. A command line flag is passed
  to the program to tell main() which test harness to call. The test
  harness is supplied by the programmer to call the function being
  developed with some test values in the variables to have meaningful
  live displays in the function being written.

  There could be a library of useful display formats for showing what is
  happening inside that function. Eg; "Y_INT(a);" or "Y_LIST(b)", where
  these are macros that evaluate to nothing when not debugging, but are
  calls to provided functions that display useful information about the
  variable being probed. These calls can be positioned in useful places
  rather than just at the beginning or at the end.

  Could also have graphical display routines that display symbols and
  links for structures and lists so mistakes become immediately obvious
  in its graphical form. Can be a set of programmer defined macros that
  call simple functions that hook into the debug library

  This system can follow the transistion between types, as each claiming
  bit of code knows what type it is and doesn't need to know what it's
  claiming from, only the handle and co-ords. So hanging trees off lists
  will work fine. Child may want to supply its size to the parent so it
  can more sensibly place its own hooks.

  The test harness can do tests to certify whether or not the function is
  operating correctly, in addition to exercising it. It can also define
  different views of the code being tested so information flow could be
  emphasised, or variable accesses, etc.

  Dependent functions can also have their test suites run, to find out if
  the changes in the lower level functions breaks anything in the higher
  level functions. Provide co-ords so graphical output of all functions
  can be run together in a coherent diagram.

  The editor can make creating this test harness easy by looking up the
  type of variable being passed to the structure and creating a form with
  the appropriate prompts and "check for NULL pointers?" checkboxes. This
  could automatically put in "g_assert()"'s into the actual code. It
  could also use the cursor position to know which function is being
  coded at that moment and supply the appropriate argument to the program
  to test that function so it can keep a window by the side of the editor
  showing the function going through its paces.

  When trying to find some obscure type, eg GdkGC, display all the
  available functions and variables that have GdkGC's in their structure
  somewhere.

  When learning a new language, mouseover can pop up an english
  description for the syntax under the cursor. See
    http://www.mit.edu/~ocschwar/parse.c.pl

  Have "world according to this function" and "world according to this
  file" views. Function shows what variables it uses (and where they're
  from) and what it calls (and where) and who calls it (and where). File
  level shows all global variables and functions exported into public
  view, and what stuff it imports for its own use. Note that *.h files
  are only for prototypes, and don't have proper control over symbols
  visible at link time. It only works because programmers fix up warnings
  about not having available prototypes.

  Make it possible to toggle applicable syntax, so you could have your
  "connections" viewer goggles on and only see the lines with connections
  with all error correction code stripped out, etc. Or your GUI widget
  goggles and see little icons of the widgets being referred to next to
  those lines of code, etc.

  When functions are called, make it possible to place a description or
  test cases onto the function - eg, library functions allow things to be
  put together in certain ways, but once a particular method has been
  used, it must be used in a consistent way. So either I can make a call
  and read any caveats that other parts of the program have placed on
  using that function. eg, I might write a marshalling function that
  keeps track of all file handles allocated. So I can place a caveat on
  the fopen() function to tell the programmer to use my_fopen() instead.
  It also applies the other way, like I write a function returning a
  range 1-10, and I write another function that assumes the range starts
  at 1, then I should be able to place a caveat that the range must start
  at 1 or something breaks. These caveats can be checking code that gets
  imported or items in a list checkbox that have to be checked in any
  code that uses the function. The programmer shouldn't be forced to
  comply, or tick all items, but it should be there in case the
  programmer wants to incorporate this system into their programming
  methodology.

  This is trying to make it possible to do gradual migrations from one
  module to another (eg, when upgrading sections of the program from
  bubblesort to quicksort, the program should continue functioning even
  if only some of the functions have been converted. It does this by
  running bubblesort alongside the new quicksort stuff until bubblesort
  gets explicitly turned off.

Maybe this calls for a Wiki? :)

-- 
  steve@deaf.org