+<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
+
<!--
# Copyright Neil Brown ©2015 <neil@brown.name>
# May be distrubuted under terms of GPLv2 - see file:COPYING
-->
-edlib - library for building a document editor
+Edlib - a library for building a document editor
==============================================
edlib is an extensible document editor. It is inspired in part by
emacs, both by its strengths and its weaknesses.
-emacs provides a programming language - E-lisp - for configuring and
+emacs provides a programming language — E-lisp — for configuring and
extending the editor. edlib doesn't. It allows various pre-existing
languages to be used to configure and extend the editor. It does
this by providing a library of core editing tools and providing
bindings to various languages.
-At least, that is the plan. At time if writing, edlib is just a
-demonstration of some of those tools and has no binding yet.
+At least, that is the plan. At time if writing, only provides
+bindings for C and Python, and these are incomplete. Other languages
+should be fairly easy.
The particular value-add of edlib over emacs (apart from the obvious
-"NIH" issues) is that document rendering will be fully extensible. A
-buffer can have multiple views, and each view can show very different
-things, scriptable code is run whenever text rendering is required.
-This should make implementing documents with non-trivial structures a
-lot easier. I hope.
+“NIH” issues) is that both document storage and document rendering are
+fully extensible. A document is not always a text buffer, it could
+also be a mem-mapped files, a directory, or an internal data
+structure.
+Any document can have multiple views, and each view can
+show very different things: scriptable code is run whenever
+rendering is required. This should make implementing documents with
+non-trivial structures a lot easier.
edlib is designed to have well defined abstractions that can be
exported to various languages for them to manipulate. They include
-attributes, text buffers, marks and points, panes, displays, events,
-and keymaps.
+primarily commands, panes and marks, and also
+attributes, documents, displays, events, and keymaps.
+
+Commands
+--------
-attributes
+Commands are the single mechanism by which control is transferred from
+one part of the editor implementation to another. They provide the
+only way for code in one implementation language to invoke code
+written in another language, and they are the preferred way to
+interact between different modules even in the same language.
+
+All commands receive the same types of arguments and produce an integer
+result. The arguments include two panes, two marks, three
+strings, two numbers, two co-ordinate pairs and one command. Extra
+result values can be effected by passing them to a call to the
+“command” argument.
+
+Commands can be used internally to a module and externally for
+communication between modules. Externally visible commands appear
+primarily in two sorts of places. Each “pane” has a command which
+performs all the actions required of, or provided by, that pane. A
+pane may also maintain a set of commands with assigned names that
+are provided to it from elsewhere. In particular the root pane
+maintains a set of global named commands.
+
+Two of the arguments provided to a command have very special
+meanings. One of the strings, known as “key”, identifies what action
+should be performed. For commands that have been assigned a name, the
+“key” string passed will always be exactly the name by which the
+command was found. For commands which are assigned to a pane, the
+“key” could be anything. The command must determine if it understands
+that key. If it does it should perform the action (possibly
+calling some other command internally). If not it should return 0.
+This return code usually causes the caller to look elsewhere for a
+command to perform the desired action.
+
+The other special argument is one of the panes, called “home”. This
+always identifies the pane in which the command was found, either as a
+dedicated 'pane' command or as a named command. One of the primary
+uses of “home” is to access “home->data” which a private data
+structure owned by the pane. The command associated with a
+particular pane is typically the only code which can understand the
+data.
+
+Apart from the return value of zero which indicates “command not
+understood”, a command can return a positive result on success or a
+negative result indicating lack of success. In particular, “-1” is a
+generic failure return code, and “-2” indicates that the command will
+complete asynchronously. Commands only return this if they are
+specifically documented to do say. It is usually only relevant if a
+callback was passed as the “command” argument and it indicates that
+the callback has not yet been called, but otherwise no error has been
+detected.
+
+Panes
+-----
+
+A pane combines a rectangular area of display with some
+functionality. As such it can receive mouse and keyboard events,
+can draw on a display, and can send commands to other panes. As
+previously mentioned, panes can also store module-specific data.
+
+All panes are arranged as a tree with all but the root having a parent
+and many having siblings and children. The “root” pane does not
+correspond to any display, but is still implemented as a pane for
+consistency. The children of the root are the different display
+windows, each of which can use a distinct display technology such as
+“ncurses” or “gtk” or “qt” or “fbdev” or anything else. The root pane
+also has some “virtual display” panes which are used to gather other
+special panes - see “Documents” below.
+
+As well as a dedicated command and private data, each pane has:
+
+- x,y co-ordinates together with width and height. The co-ordinates
+ are relative to the parent, and by recursive addition can be made
+ absolute.
+- a 'z' value which indicates display priority with respect to
+ siblings. When siblings overlap, the sibling with the higher “z”
+ value will be draw “over” siblings with a lower “z” value, including
+ all the children of that sibling (independent of their z value).
+- a selected child referred to as the 'focus'. Keyboard input at a
+ display is forwarded down the chain of focus links until it reaches
+ a leaf pane. This is where handling of the keystroke starts.
+- a set of 'damaged' flag which record if any changes have been made
+ which might affect the display.
+- an arbitrary set of attributes with assigned values.
+
+Each pane may also request notifications from other panes. These
+include, but are not limited to, a notification when the pane is
+destroyed and a notification when a document attached to the pane
+changes. This notifications are effected by calling the panes command
+with a key like “notify:close” and with the second pane argument
+(known as 'focus') set to the pane which is sending the notification.
+
+
+Documents
+---------
+
+A document provides access to whatever data is being edited. There
+can be multiple implementations of a document but they call have a
+common interface.
+
+A “document” is assumed to be a linear sequence of elements each of
+which presents as a single character and may have some attributes
+associated with it. For a “text” document, the characters are
+typically Unicode characters stored as UTF-8 and the attributes, if
+any, are hints for parsing or display.
+For a “directory” document, the elements are entries in the directory
+and the associated character reflects the type of entry. The
+attributes contain the useful information such as file name, size,
+modify time etc.
+
+Documents cannot be accessed directly, but must be accessed through a
+“document access” pane. There can be several panes which access the
+one document though there is always one special pane in a “virtual”
+display. There panes in this virtual display contain all of the
+active documents so a list of documents can be obtained by iterating
+over the children of this virtual display. There is a singleton
+document types called “*Documents*” which lists all active documents.
+By opening a pane on this document, the set of active documents can be
+viewed and modified.
+
+It is (will be?) possible for different panes to provide slightly
+different access styles to the same document. For example one pane
+might present a file as a sequence of bytes while another presents the
+same file as a sequence of unicode characters. Similarly one
+interface may accept arbitrary insert/delete operations while another
+converts all changes to over-writes (maybe).
+
+
+Attributes
----------
An attribute is a simple name/value pair, both being strings.
-Attributes can be associated with various other objects, but
-particularly with characters in a text buffer. Parsing code can
+Attributes can be associated with various other objects, including
+mark, panes, and elements in a document. Parsing code can
annotate a buffer with attributes, and rendering code can use these
attributes to guide rendering. e.g. parsing code can attach
-"spelling=wrong" or "spelling=doubtful" and rendering can underline in
+“spelling=wrong” or “spelling=doubtful” and rendering can underline in
red or whatever.
-text buffer
------------
-
-A text buffer (sometimes just a "text") stores a string of characters
-and an edit history. The characters can be read from a file, or
-manipulated by code. The edit history allows indefinite undo and
-redo.
-
-It is expected that every document will be represented as a text.
-Some views of the document would just display the text, others might
-display the result of parsing the text, still others might just
-display some of the attributes attached to the text.
-
-A text will often be read from and saved to a file in external
-storage. However an extension module might fetch a text over the
-network using some protocol, or might generate it entirely
-algorithmically.
+Currently most attributes have to be stored using a particular
+implementation of attribute storage. I'm not sure I want that in the
+longer term. I'm considering having the pane command support a
+"attribute:get" command though there are still unresolved issues with
+that idea.
-marks and points
+Marks and Points
----------------
-A "mark" identifies a location in a text buffer. The location is
-between two characters (or at the start or end), and the mark remains
-at that location despite any edits that do not affect neighbouring
-characters.
-
-A mark can have a 'type'. All marks of a particular type are linked
-together in text-order so moving among marks of a type is easy.
-
-"Points" are a special sort of mark which have linkage to nearby marks
-of all different types. All modification to the text happen at a
-point.
-
-When a modification happens, the preceding mark of each type is
-"notified". This allows it (or its owner) to adjust to the change,
-such as by reparsing the text.
-
-An example use is to have a type of marks which are used to track line
-numbers. "line-count" marks are places every 500 lines (or so) with
+A “mark” identifies a location in a document. The location is between
+two elements in the document, or at the start or end, and the mark
+remains at that location despite any edits that do not affect
+neighbouring element.
+
+Marks come in three different sorts: ungrouped, grouped, and points.
+All of these appear in document-order a single linked list, all have a
+sequence number in the list so ordering-tests are easy, and each can
+have a set of attributes attached.
+
+As well as identifying a location in a document, a mark can identify a
+location in the display of that document location. When a single
+element in a document is displayed using multiple characters (as for
+example a directory entry might be), the “rendering position” or
+“rpos” can record where in those multiple character the mark really
+belong. I'm not yet sure how useful this is, but it seems like a good
+idea.
+
+An ungrouped mark has no property beyond the above. A grouped marked
+is included in a second linked list with all the other marks in the
+same group. This group is owned by a specific pane and keeps
+information relevant to the task of that pane. A pane responsible for
+rendering part of a document might have marks identifying the start
+and end of the visible portion, and maybe even the start of teach line
+in the visible portion. An ungrouped mark also has a reference to an
+arbitrary data structure which is understood by the pane which owns
+the group.
+
+A “point” is a special grouped-mark which is included in all of the
+other lists of grouped marks. This is achieved by using the external
+reference to hold an auxiliary data structure which is linked in to
+all of the lists. Every pane which views a document owns a point.
+This point is usually where changes to the document happen. When the
+notification mechanism mentioned earlier tells other panes of a chance
+to the document, the point where the change happened is also
+reported. From this point it is easy to find and update nearby marks
+of any mark-group.
+
+An example use is to have a group of marks which are used to track line
+numbers. “line-count” marks are placed every 500 lines (or so) with
an attribute recording exactly how many lines between this and the
-next "line-count" mark. When a change happens, the recorded line
+next “line-count” mark. When a change happens, the recorded line
count is cleared. When a line count or line number is needed, the
-list of "line-count" marks is walked from the start. If any has its
+list of “line-count” marks is walked from the start. If any has its
count cleared, the lines in that section are counted and the record is
updated. Otherwise all that is required is simply adding up a few
numbers.
-Note: the notification of marks on a change is not yet implemented.
-
Marks could be used by a parser to identify key locations which would
allow a renderer to find the important content quickly if it was only
rendering a partial view - such as the headings in outline mode.
-Each mark (and point) has a unique sequence number ordered by position
-in the text. This makes it easy to determine relative order of two marks.
-
-Each view of a buffer will have its own point.
-displays
+Displays
--------
-A "display" displays rendered content and accepts keyboard and mouse
-input. Currently only a single 'ncurses' display is supported, but
-I intend to support multiple 'ncurses' displays and also X11 displays
-and maybe other display/input technologies.
+A “display” is just a pane which can create an image somehow, and
+responds to commands like “draw:clear” and “draw:text”. Displays are
+typically just below the root of the 'pane' tree, but this is not a
+requirement.
-panes
------
+A display is also expected to call "Keystroke" and "Mouse-event"
+commands in response to appropriate events.
-A pane is a rectangular area of a display. It may receive input from
-the display and may render content. Panes are arranged in an
-hierarchy with parents generally responsible for their children.
+Keymaps
+-------
-Each pane can have a 'focus' child. Keyboard input from the display
-goes to the final pane found when following these 'focus' links from the
-root. Mouse input goes to the pane under the mouse which has no
-children also under the mouse.
+A keymap is a mapping from command names to commands. In many cases a
+similar data structure such as a Python “dict” could be used. The
+keymap implemented in edlib has one small advantage in that a range of
+strings can be mapped to a command, then exception can be recorded.
-Panes can have a 'z' depth - higher 'z' numbers are in front of lower
-numbers. This allows for pop-ups and floating windows. For example a
-list of filename completions might appear in a floating window, which
-then disappears when the selection has been made.
+Keymaps are a bit like attributes in that the concept is valuable but
+it isn't yet clear how central a particular implementation should be.
-Each pane must know how to refresh itself, unless the parent does
-that. Various amounts of 'damage' may have happened which lead to
-different amounts of work in refreshing. The design for this is not
-completely clear yet. It currently understand damage to "Size",
-"Content" and "Cursor position".
+Handling Commands
+-----------------
-events
-------
+Now that we have plenty of context, it is time to revisit commands to
+discuss how they are called. It is possible to invoke a specific
+command directly but most often a more general mechanism is used to
+find the appropriate command. There are three such mechanisms which
+each search the pane tree testing different commands until one accepts
+the given “key” name. They each find a starting pane in a different
+way, and then try that pane and then its parent and so on up the tree
+until a pane accepts the command (returning non-zero) or until the
+root is reached.
+
+There are three ways to choose the starting point, which is included
+in the arguments to every command called as the “focus” point.
+
+The first way is for the caller to explicitly set it. This is not a
+very common approach but is needed when a pane acts like a “filter”.
+The handler for a particular command might call that command on the
+parent, then process the result in some way and return that result to
+the caller. This can also be used when the appropriate “focus” has
+already been found. If the handler for some command wants to call
+some other command it will typically pass the “focus” of the first as
+the “focus” to start searching for the second.
+
+The second way is to search out to a leaf of the tree following the
+“focus” links in each pane. The search typically starts at a
+“Display” pane where a keystroke is generated,
+
+The third way is to search out to a leaf of the tree which contains
+some particular x,y co-ordinate. The pane with the highest 'z' value
+which contains the co-ordinate will be chosen. This is typically used
+to find the correct handler for a mouse event.
-Events happen at panes and propagate up parent linkages until a
-handler is found. The handler may invoke further events, which
-typically start at the original pane and themselves propagate up.
-
-Events include:
-
-- keystrokes. These go to the focus pane. They can include
- modifiers (e.g. C-x or META) which cause subsequent keystrokes
- to be reported differently.
-- mouse clicks. These go to the pane under the mouse. Mouse
- movement will eventually be included. Possibly a 'grab' mechanism
- will be needed to direct motion and button release events.
-- text-replace. This requests that a range of text be replaced by
- another range (either can be empty). When a keystroke implies
- a text change, it is not performed directly but instead causes a
- "text-replace" event to be sent. This allows a module to easily
- capture and validate all changes to text without having to capture
- all relevant key strokes and mouse actions.
-- movement. This identifies a unit of text (char, word, line, etc)
- and a count and allows each pane to interpret it in a local context.
- This is similar to "text-replace" in that it allows handlers to
- capture functionality rather than just keystrokes.
-- search. I haven't really thought this through, but it seem like
- useful functionality to specifically delegate.
-
-
-keymaps
--------
+Core Extensions
+===============
+
+These are the basic common objects which can (I hope) be used to build
+a rich document editor. There need to be lots of extensions of course
+to make them useful. The current extensions that are available include:
-A keymap maps keystrokes to commands. It should really be "eventmap"
-as all events are included: key, mouse, replace, movement etc.
-The full unicode character space can be mapped as well as multiple
-mouse clicks and assorted auxiliary functions.
+Text Document
+-------------
-An event in mapped to a "command". Commands can be provided by
-different modules or language bindings. A command receives the target
-pane, the event, and a structure of auxiliary information such as x/y
-co-ordinate for mouse events or a text string to insert.
+A text document stores text in various linked data structured designed
+to make simple edits easy and to support unlimited undo/redo. There
+are a number of allocations, and a list of “chunks” which each
+identify a start and end in one of those allocations. Edits can
+add text to the last allocation, can change the endpoints of a chuck,
+and can insert new chunks or delete old chunks.
+Each chunk has a list of attributes each with an offset into the allocation.
-bindings
---------
+Directory Document
+------------------
-This is totally unimplemented so the details are probably all wrong,
-but it something thing that will be needed.
+A directory document contains a list of directory entries from a
+directory and provides a variety of attributes for each entry. The
+directory can be re-read at any time with incremental changes made to
+the document.
-A "binding" is a connection between the library and some language
-and/or runtime. To load an extension module a binding to the language
-will need to be established, and used to load the module. The binding
-will need access to some global objects such as the global keymap and
-buffer list.
+Ncurses Display
+---------------
-I'm hoping to support multiple threads so that extension modules
-can run in parallel with editing code. For example an extension
-module might start a thread to talk to an IMAP server to keep some
-local buffers up-to-date with arriving mail, and to handle slow
-requests. I imaging threading being closely related to bindings, but
-maybe not.
+The 'ncurses' display can draw text on a terminal window and can set
+various attributes such as colour, bold, underline etc. It also
+receives keyboard and mouse input and sends 'Mouse-event' or
+'Keystroke' commands ... somewhere.
-The first binding types I hope to implement are "C" - which is really
-just loadable shared objects - and Python.
+Line-Renderer
+-------------
+The line renderer is designed to work with any document that presents
+as a list of lines. Lines that are wider than the pane can either be
+truncated (with side-scrolling) or wrapped. The line renderer moves
+back and forwards from the cursor “point” to determine which lines
+should be drawn and sends a “render-line” command to get the
+displayed text for those lines.
-Core Extensions
-===============
+The “text” document provides direct support for “render-line”, but
+needs a better way of provides stable limited-sized lines when at file
+doesn't contain as many newline characters as we would like.
-These are the basic common objects which can (I hope) be used to build
-a rich document editor. There need to be lots of extensions of course
-to make them useful. Some of these "Extensions" are so intrinsic that
-they are part of edlib, not attached through any binding.
+Attribute Format Renderer
+-------------------------
-tile
-----
+The attribute formatter is given a format for each line into which it
+interpolates attributes from each element in the document. These
+lines are provided in response to “render-line” requests so that if
+the line-render and the attribute formatter are both stacked on a
+document, then the attributes of elements in the document can be
+easily displayed.
+
+The format specification is found by requesting the attribute
+“Line-format” from panes starting at the focus and moving towards the root.
+
+Completion Render
+-----------------
-The "tile" handler takes a pane (typically the root pane of a display)
+The “completion” render is a filter. In response to a “render-line”
+call it calls “render-line” on its parent and only returns lines that
+start with a given prefix. It can also add highlights to rendered
+text to distinguish the common prefix from the remainder.
+
+A prefix is set by a “set-prefix” command. The response to this
+indicates if the selected lines have a longer common prefix, and if
+there is in fact only a single matching line. This supports the
+implementation of filename, document name, command name completion
+etc. To complete from a set of names, you just need to provide a
+document which responds to “render-line” with the various options to
+choose from.
+
+Hex Render
+----------
+
+The HEX renderer provides an alternate “render-line” for a document
+which starts each line at a multiple of 16 bytes from the start of the
+document, and formats the next 16 bytes as hex and ASCII. Each
+rendered line start with the byte offset of the start of the line.
+
+Tiler
+-----
+
+The “tile” handler takes a pane (typically the root pane of a display)
and divides it up into 1 or more non-overlapping tiles. Tiles are
grouped in horizonal and vertical stacks. Tiles can be split, can be
-discarded or can be resized. Any of these operations may affect other
+discarded, or can be resized. Any of these operations may affect other
tiles.
-The leaves of the tile tree need to have other handlers attached. The
+The leaves of the tile tree need to have some other pane attached. The
tiler doesn't render anything itself, not even borders. That is left
to the children.
-view
+View
----
-A "view" connects a text to a pane. It holds the text and the point
-and draws borders. A horizontal border at the bottom can report
-the name of the text and possibly other information. A vertical
-border acts largely to separate panes but also serves as a scroll
-bar. The text manager can set attributes on the text identifying
-scroll-bar position, and the "view" will render them and handle mouse
-events to request movement.
+A “view” draws borders around a pane and provides a child pane which
+is slightly smaller to allow for those borders (so it should probably
+be called “border”).
+
+The borders can contain scroll-bars, a document name, or other
+information provided by child panes.
+
+Popup manager
+-------------
+
+The popup manager places a small window with an elevated 'z' value
+somewhere relevant on the display and can provide a simple text document
+for text entry - or can use a provided document. Various key strokes
+are captured to allow the popup to be aborted, or to send the content
+of the mini document to the originating pane.
+
+The popup requests notifications from that pane so that if it is
+closed, the popup automatically closes too.
-text-render
+Line-Counter
+------------
+
+The line-counter uses the model described earlier of placing marks
+every few hundred lines in a document and using them to expedite line
+counting. This currently isn't implemented as a pane. I wonder if it
+should be.
+
+Keymap
+------
+
+“Keymap” allows both global and local keys (or arbitrary commands) to
+be defined. The global mappings are handled at a pane which must be
+stacked before the tiler. A pane to handle local mappings is added on
+demand at the current focus pane.
+
+Search
+------
+
+“search” is like line-counter in that it provides a global command
+rather than a pane. This command can perform a reg-ex search through
+a document. Currently it only searches the per-element characters, so
+it isn't useful on directory listings. It should be extended to work
+with the results of “render-line”.
+
+Messageline
-----------
-Basic text rendering is a core extension. It will probably grow a lot
-of optional features such as wrapping or truncation of long lines,
-mapping attributes to colours etc though a provided mapping, and maybe
-centering or filling based on attributes.
+“Messageline” trims the bottom line off a pane (providing a pane which is
+slightly smaller) and will displays messages in this pane until the
+next keyboard command.
+
+Input
+-----
+
+A pane of this module store some state related to the current input
+context, including a modifier prefix and a repeat count.
+
+When a “keystroke” command is received the prefix is added to the key
+and this is sent as a command to the focus. The command includes the
+repeat count, which gets cleared.
+
+Commands are provided to set a new prefix or repeat count. So for
+example “Meta-1” might multiply the repeat count in the command by 10,
+add 1, and then ask 'input' to set that as the new repeat count for
+the next keystroke.
+
+Emacs Mode
+----------
+
+This provides a set of named commands which can be given to “keymap”
+as a global key map. In provides a number of emacs-like bindings.
+
+Python Interface
+----------------
+
+This module allows python code to be run, provide an interface to
+panes, marks, and commands, and allows commands to be called on a
+given pane. It also allows commands to be defined in python that can
+be called from other modules just like any other command. It is, or
+will be, a complete two-way interface between python and other
+languages to access the core edlib functionality.
+
+
+Pygtk Display
+-------------
+
+This is an under-development display module written in python and
+using pygtk for drawing.
-Simple views will probably use text-render. More complex views won't.
+When a “text” or “clear” request is made on a pane, the module
+allocates a pixmap (arranging for it to be destroyed when the pane is
+closed) and performs the drawings there. When a refresh is required,
+the various pixmaps are combined and drawn to the target window.
+
+There is currently no attempt to handle variable-width fonts. That
+must come later.
TO-DO
=====
-There is so very much to do. At time of writing most of the core
-infrastructure is in place, but it isn't all connected and is not at
-all polished. It is certainly possible to start writing simple
-commands to test out functionality and explore interfaces. As
-functionality is added I expect lots of details to be refine.
-
-Below is a very rough list, which serves to highlight how little
-really works. Some of these should be easy to write. Others will
-requires careful design though and possibly deep changes.
-
-- movement: char, word, line, vertical, paragraph, page, start/end
-- text entry
-- delete
-- notifications of change to marks
-- search
-- number prefix
-- choose file name - with floating pane
-- open file
-- save file
-- file names in status line
+There is still so very much to do. At time of writing a lot of things
+work and I can load and save files with filename completion, and I can
+browse directories and search in text files. This is encouraging but
+it is barely a start.
+
+This a list of just some of the things I want to work on soon. You
+might noticed that the above texts might suggest that some of them are
+done already. In those cases I was being a little ahead of myself above.
+
+- Generic notifications between panes: currently only a document can
+ notify a pane.
+
+- change commands that return a non-integer to do so by calling
+ the call-back command.
+
+- The “complete” popup should be positioned above/below the file name,
+ not over the top of it. And typing should increase/decrease the
+ prefix.
+
+- render-lines should always re-render the line containing point, so
+ the location of 'point' can affect the rendering.
+
+- allow searching in the rendered output as well as in the document
+
+- support case-insensitive search an literal (non-regex) search.
+
+- Create an append-only limited size document for a log of messages
+ and a log of keystrokes.
+
+- use above to allow keyboard macros.
+
+- create a 'mmap' document type so I can edit a block device without
+ reading it all in.
+
+- create a 'reflection' document so I can view the internal data structures.
+
+- Generalize the “event loop” interface so that glib events can be
+ used when gtk is active.
+
+- create clean threading interfaces so that I can have different event
+ loops in different threads and suitable locking so commands can be
+ called from any event loop.
+
+- Support write-file (providing a file name) - currently I only save
+ to the file I loaded from.
+
+- improve format options for status line.
+
- autosave
-- cut/copy
-- paste
-- undo/redo
+
+- cut/copy, paste
+
+- lots of work on pygtk interface
+
+- allow a second (and more) ncurses display to be created.
+
+- determine how best to support variable-sized fonts, both
+ non-constant-width and requested font size changing.
+
+- improve ncurses code for choosing colours.
+
- auto-indent
- auto-wrap
- c-mode parsing
- color highlights
-- line/word count
-- scroll bar
- spell check - async?
Some Ideas
Text mode server
----------------
-I only recently discovered "emacsclient -t". I think I like it. I
-certainly want edlib to have a "server" mode and to be able to perform
+I only recently discovered “emacsclient -t”. I think I like it. I
+certainly want edlib to have a “server” mode and to be able to perform
editing in arbitrary terminal windows where I do other work.
calculator in floating pane
------------
Many years ago I started writing a spreadsheet program in emacs-lisp.
-The document was a 'LaTeX' document with specially marked "tabular"
+The document was a 'LaTeX' document with specially marked “tabular”
sections. Each cell was on a line by itself. It consisted of the
current appearance of the text, and then a comment containing the
formula and formatting rules.
output as needed. This means that `cat bigfile` could move the whole
file into a buffer, which wouldn't be good. If a 'less' command could
give the filename to edlib and let it display, that might be nice.
+
projects / edlib.git / commitdiff