Skip to content
This repository has been archived by the owner on Nov 4, 2019. It is now read-only.

Get busy

Jump to bottom
rsms edited this page Jan 7, 2011 · 34 revisions

Get busy -- a general TODO list

Having a Sunday all to yourself? Itchy coding fingers? Grab something from this list and start hacking!

Remember, fixing bugs may be boring but it makes for a good nights sleep -- check Open tickets in the issue tracker for bugs and problems which need some sweet hack love.

Investigate if/why "Cmd+Q causes crash in -[KDocumentController windows]" bug

When terminating Kod it sometimes causes a BAD_ACCESS memory violation.

This has not been reported with the latest rsms/master (as of writing), so there need to be an investigation wether this was caused by another bug which have been fixed, or if this bug still persists and need to be fixed.

  • Ticket: Ticket 81
  • Currently hacking on this: (no one)

Adding ODB support

http://www.barebones.com/support/develop/odbsuite.html is a text editor interface used and supported by many OS X editors () and applications utilizing external text editors (for instance Hog Bay Software's QuickCursor).

According to Hog Bay Software, the following applications already support this interface (this is not an exclusive list): "BBEdit, Espresso, MacVim, Smultron, SubEthaEdit, TextMate, TextWrangler, and WriteRoom".

This document gives a good overview of the interface specification: http://www.barebones.com/support/develop/odbsuite.html

  • Ticket: (none)
  • Currently hacking on this: (no one)

Override default syntax highlighter

Pointers from rsms:

  • You want to query the +[KLangMap sharedLangMap] object for a list of language ID's and descriptions.
  • Probably add a read-only property for accessing langIdToInfo_ which maps language id to an info dictionary (human readable title, etc)
  • Then the current document has a langId property which can be key-value-observed (you want to setup and tear down KVO in -[KStatusBarController updateWithContents:])

Note(rsms): There's work going on to replace the current sytnax highlighter with a more sophisticated and flexible system. However, this is in a longer time perspective.

Needs:

  • Slim dropdown in footer, to the right of the line/column numbers

  • Selecting option from it recomputed highlighting for the current viewed tab

  • Remember the choice, so when you close the file and reopen, it opens as the highlighter you selected (not the default chosen one)

  • Ticket: Ticket 53

  • Currently hacking on this: (no one)

A better and more flexible text parsing system

Kod currently uses Source Highlight to tokenize and parse text. This is a very limited system which has other issues as well (like being GPL so we can't patch it).

We want to have a system which have the following features:

  • Flexible and minimal core -- provide just enough low-level hooks to be able to do almost anything
  • High performance
  • Parallelize-able -- parsing should not be performed in the main thread as to avoid blocking the UI
  • Parsers written in JavaScript and executed by libv8 (libnode).
  • High-level human readable syntax "definitions" -- modeled on top of a universal/basic parser implementation

There is currently a kod-node API which should be "final" enough to start basing this work upon.

Syntax-aware indentation

Indentation controlled by the active text parser. See http://boredzo.org/blog/archives/2008-11-05/tabs-vs-spaces-redux

  • Ticket: Ticket 76
  • Currently hacking on this: (no one)
  • Depends on: New text parser system

Command-T "jump to file"

As described in https://github.com/rsms/kod/blob/master/ideas/location-bar-as-command-input.psd

Which would behave like https://github.com/jamis/fuzzy_file_finder (which is a derivative of http://www.vim.org/scripts/script.php?script_id=1984). Demonstrated in this short screencast: http://s3.amazonaws.com/buckblog/videos/fuzzyfinder_textmate.mov

  • Ticket: (none)
  • Currently hacking on this: @puls
  • Repository: puls/kod@jump

A better user experience when working on "projects"

There are two common use-cases when it comes to document editing behavior for products like Kod:

  1. Quickly edit a single file (a todo list, taking down notes during a phone call, run a quick script, preview some file, etc)

  2. Build something that involves more than one file (aka a "project")

Now, number 1 is not an issue, but number 2 is.

There are many ways existing tools deal with this, but the most common one is to display a user interface representing a single file system hierarchy (that is, a directory tree of files and folders). Many software projects are structured using the file system. However, there are both limitation and redundancy involved in this solution.

Example of a good fit for file system transparency/presentation

Let's take an example which illustrates when a 1:1 file system representation is a very suitable fit:

  • A small website in PHP
  • Limited number of files
  • The file system hierarchy has a higher importance (i.e. putting a file in /hello/index.php or /foo.php changes the behavior of the product)

Example when a direct file system representation is a less good idea

Now, let's instead take an example where the project is a little bit more complex. This time we look at actual software projects

  • There are over 3100 files (after ./configure && make in node/master at the time of writing this, not counting "."/hidden files or directories)
  • 30 of those files (and folders) are in the root of the project
  • In 95% of the case you are interested in contents of only two directories (/src and /lib) and a few single files from other subdirectories.
  • There are 57 C++ and .h source files in the /src directory
    • Most of these files has an implicit structure and semantics -- for instance, if you work on the network functionality you are interested in the i/o group of source files (node_net.{cc,h}, node_io_watcher.{cc,h}, and so on). You're also interested in the /deps/v8/v8.h file.
  • You also sporadically jump into less frequently visited source files for a short amount of time (i.e. to look up a function prototype or a convention)

Using a 1:1 file system representation in this case is more of a pain then it helps -- not only are more than 99% of all files presented to you uninteresting for the task at hand, but it also slows things down as the application need to read many files and also takes up much of the expensive "screen real estate".

We need a better abstraction and representation!

Example of where this has been done already

Well, look at the Kod project in Xcode:

  • Contains more than 1200 files (not counting subprojects like chromium-tabs or dependencies)
  • 200 of these files live in /src and constitute the core part of the project

Same things apply here as to the example with nodejs we outlined earlier. But what differs here? Well, when you open kod.xcodeproj you are not presented with one big list of thousand files, but are instead presented with a set of natural source file groups (represented by files in /src), "targets" (represented by files in /xcconfig and /build), linked libraries, etc. Here the implicit semantics and structure are being visualized in an explicit manner.

For a developer, this means that when she decides that "do_funky_stuff.{h,c,cc...}" is better grouped with the "Funky features" part of her program, rather than "Doing stuff" group, all she need to do is to alter the upper layer of structure (i.e. associate the files with another group). If she where to work directly with the file system, such a change would imply massive amounts of work (updating all #include references to the affected files, update makefiles, etc).

Conclusion

We would like to investigate and research into this with Kod with the following few "milestones":

  • Not require a "kod.project" file to be put somewhere

  • Allow for both the use-case of working with a file system structure and larger, more complex projects that span over different file system branches

  • Being simplistic and limited rather than feature rich (we must not "design for everyone")

  • Ticket: (none)

  • Currently working on this: (no one)

Clone this wiki locally