2008-07-20: I'm thinking about resuming work on Sasshi. The other items don't do what I want. This is my list of things I want:

App is small and loads quickly.
Global keystrokes to (1) bring up the app, and (2) start a new note.
Data is saved as text, so that it can be edited outside Sasshi.
You can get a sorted, filtered list of just the text entries you want.
Text uses markup, which can be printed or exported as is, or converted into formatting beforehand.

This stuff is nice but definitely optional:

Regex-based syntax highlighting (using rules stored in an entry or file).
Regex-based text collapsing (not merely "code collapsing").
Themes + CSS for exporting nice-looking documents.

The GUI of Sasshi could just be that of a regular text editor, but it would have a drawer or dialog box for building a sorted filtered subset of the file for viewing, printing, or export to (X)HTML.

What is out there:

MyNotes. Apparently does not keep data as text. It does apparently offer themes, though. (Recommendation.)
iNotePad.
Scrivener. This is a word processor, probably too hefty for what I want.
VoodooPad

(2008-07-09: Jeez, just download Scrivener and play with that for a while. See if you can export outlines as text, change them in a text editor, and reimport them back into Scrivener.)

Overview

"Sasshi" (Japanese: "notebook" or "pamphlet") will be a text editor for Mac OS X. What distinguishes Sasshi from other text editors is that it treats a text file as a series of entries, and it is designed to deal with multiple entries in various ways -- by hiding (or "folding") all entries that don't match certain criteria, by moving multiple entries together so that they are contiguous within the file, by sorting them, by printing or searching or exporting only certain entries and not others, and so on.

The Sasshi editor window has an entry list contained in a side drawer. The entries listed are those that match the criteria specified by the current filter. Clicking an entry in the list selects it; double-clicking the entry moves the cursor to the start of that entry.

Filters are additive; each new filter acts on the entries allowed by the previous filter. Thus there is a "show all entries" command, and individual filters can be taken off.

Entries

Filters

Styles

Feature list

Keystrokes
- Move to the first, previous, next, or last entry
- Move to the top or bottom of the current entry
- Expand or collapse the current entry
- Set filter: Display all entries in the file
- Set filter: Display all entries containing the selected text [use the selected text as the filter criterion]
- Undo (pop) filter (this requires that filters be kept on a stack)
- Make entry match current filter criteria (add fields and text to the entry if needed)
Search and replace
- Use regular expressions
- Preview all changes before any are made.

Programming

Implementing features

The IDEKit might be worth investigating. It promises "programmer source code editing, including syntax coloring, popup functions, and split frames."

Regular expressions

Download a library of functions for handling regular expressions -- AGRegex or more likely RegexKit.

Jumping to an entry

Hold text in linked lists of blocks? Internally, Sasshi keeps each entry as an object, consisting of the entry text, the number of lines the entry has, and pointers to the next and previous entries. The entry list in effect contains pointers to individual entries within this linked list, simplifying the task of figuring out which line number to jump to when an entry name in the list is doubleclicked.

Insert special characters into text? Sasshi could also insert special characters before each entry -- characters that are not echoed in the editor but are used internally to track the location of each entry. Each entry would get a certain sequence of characters, e.g., Chr(1) followed by a series of digits followed by Chr(2). Each item in the entry list has both an entry's name and its internal ID instead of a line number. To find an entry, given its ID, we just search the string for the ID enclosed in the opening and closing special characters.

I think the advantage, overall, goes to the linked list of blocks. There is work to be done whenever loading or saving, switching between one long text and the series of blocks, but entries can be rearranged at will, and there is no need to go hunting for an entry. An index could be added, with one index object for every entry in the file. In addition, this scheme allows me to purge infrequently used entries to disk, thus making it easier to deal with large (multi-megabyte) files.

Entry folding

You "fold" an entry by hiding all lines except for the entry's name line. The editor needs to display a widget to the left of the line, which toggles between "expanding" the entry (adding its lines back into the editor display) and "collapsing" it (removing its lines).

Other things

Icons

One idea for an icon: a hardbound book (triangular protectors on the two corners away from the spine), with two or three bookmarks sticking out of it, laying on a red sash.

Old stuff, unorganized

2008-07-07:

(Possible feature where you toggle between the "project" file and the "common" file? The common file is where you keep all your clips and everything you want to be available no matter what you're working on; the "project" file is the one you open in the file picker or by double-clicking it in the Finder.)

(Alternative to opening a single huge file: Open multiple files at once, but press Cmd plus a number key to switch among up to ten open files.)

It's a text editor with "folding" and "bookmarks."

It's a text editor, not a card editor, so the editor window displays the entire file.

The editor still looks for three kinds of lines, though:

An entry-name line begins with three percent signs (%%%) by default. The text on this line is the name of the entry that follows. This name appears in the list window.
- This line has a triangle to the left of it. This is used to expand or collapse the entry.
- You can change the regular expression used to match entry-name lines in Preferences.
An entry-comment line begins with two percent signs (%%) by default. Any text on this line is not printed or exported, but is searched and therefore can be used for "metadata" for the entry in which the line appears.
- You can change the regular expression used to match entry-comment lines in Preferences.
An entry-field line is any line, commented or not, with the "entry-field" format ("field name = value" by default). The editor can search not only for entries where a field contains a specific value, but also for entries where a field value is greater than or less than a given value.

The entry list

Clicking once on an entry name in the list window selects the entry.
Double-clicking the entry name collapses the current selection and moves the cursor to the first text line in the entry (the first line that is not an entry-comment line).
List items appear in the order in which they are found in the file. Thus dragging an item name up or down in the list moves the entry up or down in the file (immediately after the entry onto which the dragged name is dropped).
Commands in the list window:
- Sort entries by name
- Sort entries by criteria...
- Apply filter to list (i.e., get a subset of the list)
- Show all entries

What would my editor have that other text editors don't?

Filters. A filter is a set of criteria that an entry either does or does not match. When a filter is applied, all entries that match those criteria are expanded, and all entries that don't (other than those containing some or all of the current selection) are collapsed. (NOTE! All a filter does is to expand or collapse entries. Other commands can be restricted to operating only on the expanded entries. Also, a filter does not prevent you from expanding any collapsed entries.)
- A filter can be assigned a name, saved, and reapplied.
Commands related to filtered lists of entries.
- Expand all entries.
- Apply filter to the entries shown. (Each filter you apply is applied only to the entries left expanded by the previous filter. Thus there is a need for an "expand all entries" command.)
- Move expanded entries within the file to the location of the first of the entries (so that all the entries are contiguous within the file).
- Sort expanded entries according to criteria in the comment lines (e.g., look for comment lines with a format like "field name = value").
- Restrict searches, printing, exportation, etc. to the expanded entries (or allow them to work on ALL entries in the file).
Styler. The styler searches for regular expressions in the text of an entry and applies formatting (foreground color, font, style, background color, maybe even borders) to any text that matches. This is useful not only to implement syntax highlighting for programmers, but also to highlight all instances of a given word or phrase.
Preview for global search-and-replace. The editor should show you a search-and-replacement preview pane so you can see the lines containing matches, and what each line would look like after replacement, so you can click an item in the pane to go to the line referenced, or veto a number of proposed replacements before clicking the "Replace Checked Occurrences" button.

Version 2 would involve a rewrite of the file-handling code. It would be nice to have file operations handled in a separate thread, so that you can work on huge files without having to wait for things to load and be resaved. The plan was to develop a system where only some of the file is in memory, and lines are loaded from the file on demand. However, I'd also want the scrollbars in the editor to behave AS IF the whole file were loaded. This is a bit more than I'm ready to chew at this point, so the special code for handling huge files can be deferred.

2008-07-05: GUI update.

The main window has three parts, from left to right:

Filter pane. This describes the current filter -- the starting list of entries, the criteria that entries in that list must match to show up in the list pane, and the criteria used for sorting the list. It also includes instructions followed after the list is determined -- what highlighting (automatic formatting) to use on which entries, what hotkeys to assign to which entries, what colors and fonts and backgrounds and decoration to apply to each entry, which entries to display expanded or collapsed in the list pane, etc.
List pane. This is a list of the entries allowed by the current filter. Each entry is displayed as a "header" with the entry name, the hotkey that opens the entry in the editor (if one has been defined), a button to open the entry in the editor, and a triangle that can expand the header (to display the entry metadata and text) or collapse it (to hide the text). You click a header once to select an entry (click several to select multiple entries); you can double-click a header to open the entry in the editor. (Opening one entry in the editor saves the contents of the entry already in the editor.) If a header is expanded, you can select text from the entry (without opening the entry in the editor) and copy it into the entry in the editor or into the clipboard.
Editor. This is where you edit the contents of an entry.

Thus the editor never contains more than one entry at once.

Also note: The filter is a first-class object. Each entry in a list produced by a filter can:

be displayed in the list pane
have a particular "style" applied to it
be exported to a file (one file per entry or one file containing all entries)
be passed to an external script

The list can also be passed to another filter, and each entry in that list can also have each or any of the above actions applied to it, and so on.

Miniproject: FilterPOC (POC = "proof of concept")

Application reads data from a file: (1) the file to open, and (2) the tags to look for. Application opens the file specified and reads the lines from the file, retaining only the lines of entries containing the tags specified. The app closes the file when it reaches the end of the file, and reports the results (number of entries found, time taken to open the file, memory consumed by the entries, and probably the text of the entries). Purpose: To demonstrate reading part of a large file without consuming ungodly amounts of memory. (For this, the file to open needs to be very large, e.g., many megabytes in size.)

Application will likely use a 64KB buffer, read in 64KB at a time, and scan the data for characters 10 and 13 (line endings).

I'll need to learn how to "realloc" a buffer to keep enlarging it so that I can keep appending data until the end of a line or an entry is reached.

2008-07-04: On how entries appear in the editor.

A person should be able to work on multiple projects at once, each with a different set of filters on the current file. However, ALL projects use the same ONE editor window, it's just that when you switch to a different project (a different view or filter), a different set of entries is shown.

The editor just displays a subset of the full file, built from just the entries allowed by the filter. The list, though, can show "stubs" between entry names. You can click a stub to see a list of hidden entries; you can click one of these to add the entry name to the list and to insert the entry into the editor. (You should also be able to hide a displayed entry.)

Filter history!

Searches and filters need to be saved to a history. You should be able to go back through the history and save a search or a filter permanently by giving it a name.

2008-07-03: To do:

Study Objective-C and Cocoa this weekend.

New object:
Thing *myThing = [[Thing alloc] init];
Call object method:
something = [theObject method: arg]
Call object method with two arguments:
[myFraction setTo: 1 over: 3] // (The method is the "setTo:over:" method)

Look for samples of source code to learn from.

HyperJeff:

Amnesia monitors CPU and memory usage -- if you want to be able to use more memory when usage is low and purge memory when usage is high, i.e., to make your app a "team player."
AquaLess is a Cocoa GUI version of the CLI "less" command. You might get hints from this one on how to capture standard output from another program.
Bean the word processor is open source, so you might learn a few things from it, but the package is 1.7MB in size.
Borkpad is a simple text editor, similar to Mac OS 9's NotePad.
Borkwalk is a very simple alarm-popup app.
And so on.

You might also look at:

TextForge -- open source Cocoa text editor, lots of features.
MacVim
Don't forget Smultron.
And of course don't forget TextEdit (source code in the /Developers folder at home).

Write up your notes.

Three percent signs mark the START of an entry and will be followed by an optional entry name.
Two percent signs mark a metadata or "tag" line, followed by a tag name. A tag name beginning with an asterisk should (by default) be hidden from the editor (*created, *author, *modified).
Scripting:
- Scripting function: takes tag name, returns list (array) of all values assigned to that tag (by entries currently displayed). USES: Assign a filename to each entry, get these filenames and delete those files (before writing the text of an entry to a new file whose name is taken from the entry's "filename" value).
Work on ways in which these various tools can be used. The styler can be used to highlight certain words or names (1) to see how often you use them, (2) to alert you when they appear in text you've inserted or pasted in, etc. (The styler can do a lot more than just color the keywords, strings, and comments in a bit of source code.)

Write "learning code."

Build the sample code in your books (such as Programming in Objective-C) to get yourself accustomed to using the tools.
Build a simple text editor.

2008-07-02: Make plans to ditch this website. Host your scratchpad app on Google. Back up all your website crap onto your hard disk at home, and turn it into scratchpad files.

More ideas here, such as a search-and-replace dialog box that displays all of the matching lines AND what they'd look like after the replace, BEFORE ANY replacements have been made (presumably so you can veto some of the replacements listed).

IDEA FOR AN ICON: One of those 4x4 puzzles where you unscramble a picture or put numbers in order by pushing squares around. The picture is of a piece of paper with a "T" on it.

Flashcard mode

Display entries randomly. An entry needs a %%flashcard keyword, a %%question field, and an %%answer field to qualify as a flashcard. The entry text might contain more information.

(Alternative: A field might mark the beginning of a section; the actual question and the actual answer might be in the text, flanked by entry lines.)

Automatter (automatic formatter) or "styler"

Syntax-highlighting definitions are implemented as searches. The system searches for each word, phrase, pattern, or regular expression in a whole list of them, and highlights each occurrence of each item in a given color (or character style). (NOTE: To handle strings in a C program, you might highlight keywords first, then go back and highlight all strings, which recolors any keywords within strings.) Syntax-highlighting should thus be accessible, if you just want the editor to highlight all instances of particular words or names.

(Musing: Maybe you can use more than color. Maybe you can use fonts, sizes, and styles. Maybe you can even use this to generate live links. If that's the case, you can use the "formatter" [for that is how I'm starting to think of it] to implement a markup system right within the editor. Thus a line that begins with exclamation points is displayed in large bold letters, text between asterisks is displayed in bold, etc.)

(A side issue: Use the same search patterns that the formatter uses, but instead insert and delete text, e.g., change "!Title" to "<h1>Title</h1>".)

You should also be able to switch formatting schemes at will, and also to use two or more at once.

Text-file handling

History? How about keeping older versions of entries around automatically?

Other features

Outlines. The list of entries can be displayed as an outline, based on entry metadata. This can be either a "parent" (if the entry is to be a child of the "parent" named) or a "level" (a number). (Probably just a level, as in MS Word.) A parent can be expanded to reveal its children, or collapsed to hide them. And of course the list can be switched from "list mode" to "outline mode" and back.

Calendars and alarms. Perhaps the app should keep track of entries with special date fields and alert you when a given date is coming by displaying the entry in a popup, or summarizing the entry in a special "alert" pane at the top of the window (hopefully one that WON'T interrupt your typing, but instead will play a sound or an animation or something). [You also have to know that people are going to want integration with iCal and Address Book if you go this route.]

Statistics -- counting characters, lines, words, sentences in each entry and in all entries displayed, and in all entries in a file. Displaying the most recently updated entries.

In-text commands. You should be able to enter "8x5" and get "40" in the text. You'd probably hit a key, say Cmd+M for macro, and enter either a direct command, or the name of a macro (or external script) to run. The output of the macro or script will be inserted into the text.

Popup entries. You can assign an entry to a key, so that when you hit the key, the entry pops up in a side window. (Easiest way to do it: Reserve a number of keys for popups, rather than allow the user to assign ANY key.) BONUS: App's windows automatically arrange themselves so that you can see everything on the screen.

Pop current entry out into a window. Press a key to display the current entry by itself in a new window (editable or read-only?).

2008-07-01:

Keyboard shortcuts:

Cmd+A - Select all text in editor.
(Cmd+B - bold) (book? send selection to clipbook and give it a name???)
Cmd+C - Copy selection to clipboard.
Cmd+D - [Finder: Duplicate] (duplicate clip and insert it at cursor???)
Cmd+E - force the editor into its regular "editor mode" (needed for macros if we use other keys to activate modes)????
Cmd+F - Find or replace text (NOT "filter").
Cmd+G - Go to entry or line. (If the entry is not in the current view, it is added.)
Cmd+H - hide app/window??
Cmd+I - Show Info (for selected text and/or selected entries and/or the whole file)
Cmd+J - Jump to next occurrence of the text typed (incremental search). This activates a mode that "fades out" after a couple of seconds.
Cmd+K - Show character palette
Cmd+L - lowercase???
Cmd+M - minimize???
Cmd+N - New file. (Creating a new entry: Start a new line, enter followed by an entry name.)
Cmd+O - Open file.
Cmd+P - Print.
Cmd+Q - Quit the application.
Cmd+R - Run macro, script, or special command.
Cmd+S - Save changes to original file. (Changes are autosaved to auxiliary files in the background.)
Cmd+T - List available templates. Enter first few characters of a template's name and hit Enter to create a new entry from a copy of that template. [The Font palette is useful only when defining styles; you don't need it while editing text.]
Cmd+U - uppercase???
Cmd+V - Paste text from clipboard.
Cmd+W - Close window.
Cmd+X - Cut selection to clipboard.
Cmd+Y - Redo.
Cmd+Z - Undo.
Cmd+[ - Go back.
Cmd+] - Go forward.
Cmd+? - Help.
Cmd+< - Make text smaller.
Cmd+> - Make text bigger.
Cmd+Minus - Collapses current entry (where the cursor is).
Cmd+Plus - Expands current entry (where the cursor is).
Shift+Cmd+F - Set/build/apply filter.
Shift+Cmd+I - Toggle the display of normally invisible characters.
Shift+Cmd+T - Select (or build) a stylesheet. (after the Shift+Cmd+T shortcut in "Pages")

2008-07-07: Needed: Keyboard shortcuts to:

Jump to the next "Find" occurrence. The current "Find" criteria remain in place even after you've closed the "Find" dialog box, so you can keep moving around in the document using those criteria. (ADDED: You can also name, save, and reload search criteria using the "Find" dialog box.)
Jump to the previous "Find" occurrence.
Insert a clip (from the file whose entries are used as clips)

In addition to the file you're working on, the app keeps open a "common" file (equivalent to the "personal workbook" in Excel). This common file contains clips, templates, syntax-highlighting definitions, and other things you might want available no matter which file you're working on. (Clips, templates, etc. can also be stored in the main file.)

Field names are abbreviations, descriptions of which are stored elsewhere (and are brought up whenever you are editing a field with that name). For example, %c indicates the date when the entry was created; %m, the date when the entry was last modified; %n, the entry name; %a, the author; etc.

2008-06-30: Different approach. The editor has a subset of the whole file -- all entries matching current criteria, separated by separator lines. You see the percent signs; they are not hidden. Setting new criteria simply changes the entries in the editor once; it does not produce a watch that continues to remove entries that do not match. Thus you can add new entries that don't match, e.g., if you have an idea or a name or a phone number you need to type in right now.

The left side is just a list of entry names -- in essence, bookmarks to the entries currently in the editor. Add an entry, and a new bookmark appears; delete an entry, and its bookmark disappears. Clicking a bookmark moves the cursor to the top of that bookmark's entry. (Update 2008-07-02: If you move the cursor from entry to entry within the editor, the selection in the list should move to the name of the entry where the cursor is located.)

2008-06-30: Quick observation: "mac os x textshuffler" returns no results on Clusty. Google returns exactly ONE reference -- to a GZIP file from a .ru site, where "TextShuffler" is apparently the name of a (source code) class.

2008-06-28: Try to work through Cocoa (articles). In F-Script, you can load the contents of a file into a string like this:

text := NSString stringWithContentsOfFile:'/myscript.txt'.

To start, you might learn about NSString and NSMutableArray and see if they have methods for reading from and writing to files. NSString has a method initWithContentsOfFile (Mac OS X 10.4 or later). For files, explore NSStream.

Test app to write

The app should look for a given file, open it, read in only entries with specific criteria, and display the text of those entries on its main window. The test requires that the file contain entries that don't match those criteria. A real proof-of-concept test would use a file containing many thousands of entries.

What I've read so far suggests that, if you want to read a file line-by-line, you gotta write code to do that yourself. You can create an NSFileHandle object to a file and keep reading N bytes from the file, but you'd have to scan the input for newlines.

Notes and Questions

What will be our "model", our "view", and our "controller"?
- The model is essentially the internal data -- the entries from the open file(s).
- The view is the user interface.
- The controller is the code that communicates changes between the model and the view and makes sure that the two agree with each other.
The view:
- How is the text file displayed?
  - The display uses two views.
    - The list view displays all of the entries allowed by the current filter setting; the entries here are read-only. The list view may display entries as passages of text separated by horizontal lines, or it may display them as cards on a tackboard.
    - The editor displays the text of the currently selected entry.
The app will be a "document-based application."
Classes:
- You most likely won't need to extend the NSDocumentController class.
  - When you create a new file, "an NSDocumentController object gets the appropriate NSDocument subclass from the CFBundleDocumentTypes property in the application’s information property list, allocates an instance of this class, and initializes this instance by invoking the NSDocument method initWithType:error:."
  - When you open an existing file, "the NSDocumentController object displays the Open panel, gets the user’s selection, finds the NSDocument subclass for the file (based on its document type information), allocates an instance of this class, and initializes the object and loads document data by invoking the NSDocument method initWithContentsOfURL:ofType:error:."
  - "In both cases, the NSDocumentController object adds a reference to the document object to an internal list to facilitate the management of its documents. It has a notion of the current document as the document whose window is currently main. (The foremost application window that is the focus of the user’s attention is called the main window.)"
  - "The NSDocumentController object manages the Open Recent menu for the application, maintaining a list of the URLs of documents the application has recently handled. It notes recent documents during the opening, saving, reverting, and closing of documents."
- You WILL need to extend the NSDocument class, and create from it a class that knows how to load, manipulate, and save your files.
Saving to huge files. The app may create a temporary folder for each open file. The folder contains temporary data from the original file, particularly entries changed from the original file, and a list of entries deleted. When saving "for real", when building a new version of the entire file, the new file is built within this folder, and the original file is replaced only when the new file is complete.
Autosaving (OS X 10.4 and later).
Any text editor needs to know how to load and save text files.
I want to read in only PART of a file -- that is, only those entries that match the current criteria. This could mean that I need to re-read the file whenever the user switches to different criteria. (Entries that matched previous criteria but don't match current criteria may be kept around or dumped from memory.)
- Implication: The app has to keep the file locked against being changed by other apps while the app has one or more entries open, particularly if the app identifies an entry by its size and location within the file.

2008-06-29: A more achievable goal than a full-blown text editor, especially for someone like me who is new to Objective-C and Cocoa, would be an app that just reads a text file and displays only those entries that match certain criteria. You'd do your work in an actual text editor, then preview the results in the other app. This app could also export the entries to a single file or to one file per entry, and maybe send the text of each entry to another app, e.g., one that converts markup to HTML.

What can be achieved with just shell scripts?

Suppose I use a regular text editor for editing, a browser for previews, and scripts to convert marked-up text to HTML and to write files. What can shell scripts do? Can a script convert Colino markup to HTML, or would I need to write a C program to do that?

Edenki again

One feature you can't have by farming this stuff out to command-line scripts is a list of names of pages within the text file. It'd be nice to click on a page name and go right to the page.

2008-06-28: Maybe doing stuff over the Internet isn't always the best way to go -- because I've had too many instances of my connection being flaky or even of losing my connection altogether for awhile. Maybe I really should be "living in text files" and trying to come up with a way to make working with multiple texts on a hard disk easier. (If I want to access my stuff from multiple locations, I should be carrying my stuff around on a USB drive, not renting Web space.)

On keeping everything in one big text file, see also:

I thought of having large text files, but splitting each file up into "cards" or "entries" or "chunks" using a regular expression for a delimiter.

The text should be editable in any text editor. However, I'd use a special program at home to edit individual entries, and to display entries sorted and filtered (so that only those entries matching certain criteria appear in the editor window).

I wonder how easy it would be to create an entry-filtering text editor with F-Script? (NOTE: Source code for OS X TextEdit is in "Macintosh HD/Developer/Examples/AppKit/TextEdit".)

Edent

"Edent" is short for "edit entries." This is my code name for my most recent idea (2008-06-28) for a text editor: Edit a single huge text file, but recognize certain lines as borders between "entries" within the file. In other words, edit a text file as a collection of text entries. These entries can be filtered (so that the editor displays only those entries that match certain criteria), and they can be sorted (by fields that you can assign to each entry).

(Alternate name: "Edenki" -- "EDit ENtries in a wiKI." This is if we implement entry names and links to entries.)

You should be able to set these conventions in a Preferences dialog, but the default conventions are:

The border between entries is a line containing nothing but three percent signs.
A custom field is a line that begins with two percent signs (followed by other text).
A system field (used by Edent itself) is a line that begins with three percent signs (followed by other text).

First things first

First I have to learn how to write a bare-bones text editor in F-Script or whatever.

Eventual features

(Let's not go overboard. Edent's core functionality is its ability to treat a text file as a collection of entries, and to output a subset of these entries.)

Core features

Export sends file as displayed (sorted and filtered) to a new file (or to stdout)
- Send text to script. Send whole file, displayed entries, or selected text as input to a script; capture script's output in a temporary entry.

Features to make working within Edent more convenient

Find
- Supports regular expressions
- Checkbox: "Hide entries without a match".
- Restrict next find to previous search results
Instant find. You press a key to turn on "Instant Find". Then, as you type each letter of the string to look for, Edent filters out any entries that don't have that string (and, perhaps, highlights where in each entry the string occurs).
Clipboard
- Multiple clipboards, saved to disk as entries in a "global" file. These would be the basis for a "glossary" of "abbreviations" you could type and then expand.
Scriptability (so that a script can load a file, apply a sort and filter, and export the results to a file or to stdout)
Automatic (system) fields such as author and date. (This allows entries to be sorted by date.)
Entry history. Whenever an entry is changed from within Edent, its previous version is saved to a history file, so that old versions of an entry can be retrieved.
Entry templates. You can create a new entry by making a copy of an existing entry. Edent may have a "global" file of entries, always open, that serves as a collection of templates for you to use.
- Keyboard shortcuts to create a new entry with one template or another. For example, Cmd+T to create a trivia entry, Cmd+D to create a to-do entry, etc.
Saves and restores full environment state. When you quit Edent, a record is made of which files and entries are open and where they are in the workspace. When you reopen Edent, the files and entries are reopened and restored to their previous locations.
- Save and restore workspace. You should be able to save and reopen the workspace under a given name. This workspace includes the sort and filter options being applied. Use this to go from one project to another.
Special handling for gigantic text files. Edent should be able to handle multi-megabyte files without loading all of the file into memory.
Folding. Entries should be collapsible into and re-expandable from just a header.
Links among entries. One entry should be able to contain links or references to other entries. (This requires that the linked-to entry has some kind of identification.) This would be the basis for annotations, for example. It would also let you use a text file as a Wiki.
Entry names. Each entry can have a name, which other entries can use to create links to that entry.
Links to "views." Each view (sorted list of filtered entries) can have a name, and an entry can link to this view. Clicking on the link leads to an "entry" consisting of all of the entries in the view.
Browser mode. View each entry as a "page", with live links to other entries. Go to another page within the current view (first, prev, next, last, specify by name/number).
Browsing history even in edit mode, so if you go to another entry, you can (1) see a list of entries you've visited and (2) return to a previously visited entry.

Internals

A file is broken down into entries, each stored in an array or list of strings. The file itself (when it comes time to save the file) is represented by a list of entry IDs (or pointers into this entry list). The current view is also represented by a list of entry IDs.

All entries from all open files go into a single list, so that a view can reference entries from multiple files.

Future features, such as outlines and corkboards, may be built based on the fact that a view can reference entries so freely.

NOTE: To accommodate huge files, not all entries may actually be in memory. An entry object might not have the entry text, but only a filename, entry position, and entry size. (The entry object needs a property "complete" that is set to True only if ALL of an entry, all content and all metadata, is in memory. The object may contain SOME of an object's metadata, for example, so that Edent can determine whether the object needs to be read into memory if a new filter is applied.)

Simplicity

I want the program to be as conceptually simple as possible.

Entry-file format. Text documents are stored in this, as will be clipboards, saved workspaces, glossaries of abbreviations, and macro libraries (should I implement those), so that any of these things can be edited from within Edent.
Metadata. Anything in Edent that can be stored to disk and that has metadata will implement that metadata as custom-field lines like those in an Edent document.
Two-second modes. Archy makes you hold down a LEAP key while typing your search text; other apps make you work through a dialog box. My idea is to have a "dialog box" (a mode) that goes away if you don't do anything with it in a short time.

Learning Objective-C and Cocoa

OrganizerProjectScratchpad