EM4me

Benefits and ways of working

How you can work with EM4me

Not how something works, but what it is good for: the steps from a single document to a working space of your own, and what the scope of the Markdown language gives the writer.

One document, the way you need it right now

Reading, writing and checking are different activities and need different presentations of the same text. Instead of forcing a compromise, six views are ready and one keystroke switches between them. Switching costs nothing and never changes the file.

  • Rendered for reading, source for precise work on the syntax.
  • Split shows source and result side by side, for constructs with pitfalls.
  • Live formats as you type and shows the Markdown characters only in the current line.
  • Mind map turns the heading outline into a tree.
  • Canvas shows a surface with cards and connections that lives inside the document itself.

Many documents side by side

A train of thought rarely lives in a single file. That is why several documents are open at once, in tabs that can be arranged. All of this is your decision, not the program's: panels move between the left and the right side, and widths and heights stay as you set them.

  • Tabs for any number of open documents, with multiple selection and a chosen position.
  • Tab groups bundle related documents by colour.
  • Two columns in the same window for source and target, draft and template, chapter and note.
  • Sidebar panels on the left or the right, with order, width and height freely set.

More than one window, more than one context

Anyone working on several things at once will not get far with a single window. Several windows belong to one application, the shared working context, and several of those can run at the same time. Two undertakings never get in each other's way, even though both use the same app.

  • Windows in any number, with tabs moving between them.
  • Applications as independent working contexts with their own windows.
  • Session restore brings applications, windows and tabs back.

Order through boundaries, order through memory

Two different kinds of order are available. An area binds an application to a folder and turns it into a boundary, so one project never frays into another by accident. A workspace, by contrast, remembers a state and keeps it current without a save step: open it weeks later and you are sitting exactly where you left off.

  • Area means a folder boundary: what lies outside does not come in — with exactly one exception, and you set it.
  • Workspace means a stored working state, named and marked with a colour.
  • Both together give a named working state with a fixed folder boundary.
  • Linked areas are that exception: a prefix you enter, one direction, a link that carries across. A door, not an open boundary.

A network instead of a filing cabinet

Knowledge rarely grows in folders. It grows in connections: one note points to a second, a third picks up both, and after a year your material carries more context than any folder structure could represent. That context is kept and can be read from two sides — as a surface showing what connects to what, and as a tree showing what hangs below an entry point, and at what depth.

  • Links in both directions: what this document names, and who names this document.
  • The network shows the surroundings of a document, the tree from a chosen root the order below it.
  • In the tree every file appears exactly once, on its shortest path to the root; a click opens it.
  • What nothing links to does not stay hidden: area statistics name those files.

When sequence is no longer enough

Some thoughts have no sequence: laying alternatives side by side or sketching a workflow needs surface instead of lines. A canvas is such a surface inside an ordinary Markdown file — cards with their own text, freely arranged and joined by labelled lines. Unlike the graph view it works nothing out, it holds on to what you have laid down.

  • Cards with their own text, freely placed and adjustable in size.
  • Connections with direction, colour and label, an arrow at both ends included.
  • Your arrangement stays yours: the surface works out no positions.
  • The surface sits as plain text in the Markdown file and is readable without EM4me too.

Files become a book

A longer work consists of many files, and their order otherwise sits in the file name or the folder position. A book writes its structure down explicitly: the chapters remain ordinary Markdown files, but their order is fixed, and reading navigation pages through the whole work across chapter boundaries.

  • Declared reading order instead of alphabetical sorting by file name.
  • Chapters stay files, readable on their own and usable elsewhere.
  • Reading navigation pages through continuously, the contents reorder by drag or keyboard.
  • Bookshelves group several books.

When a document outgrows a single file

A document sometimes grows beyond what can be edited smoothly. Instead of imposing a limit on you, the application splits such a document into several files when saving and puts it back together when opening. You notice nothing of it: one continuous text, one undo history, one search hit. Cuts are made only at headings so that no construct is torn apart, and every part file remains an ordinary Markdown file, readable without the application.

  • Size stops being a limit — even very large documents stay workable.
  • Invisible in your workflow: one tab, one text, one search result.
  • Cuts are made at headings, never in the middle of a table, list or code block.
  • Reversible: a menu command turns the parts back into a single file.

The application adapts — and comes along

Anyone who works with a program for long enough shapes it: colours, keyboard shortcuts, buttons, templates and bookmarks grow with the way you work, and at some point the language the interface speaks belongs to that too. Until now that work was tied to one computer and to the languages that ship with the application. Both are open: your setup can be written into a readable file and read back in elsewhere, and anyone who needs a sixth language translates the interface themselves. On top of that comes the view of the whole — one page that shows all your workspaces, areas, books and bookshelves side by side, including the ones that are not attached right now.

  • Your setup as a file: export it, take it along, read it back in elsewhere — in full or in part, with a preview before anything is applied.
  • A sixth language: your own. Translate a template, load it in, pick it in the status bar; whatever is missing from it appears in English.
  • Every container in one place: entered by hand rather than collected automatically, with figures and the moment they were taken.
  • Nothing happens behind your back: no drive is scanned, and no import writes anything before you confirm.

Tables that hold more than a line

This is where the question of ways of working ends and the question of what a file can express begins. The Markdown standard needs no explanation; what matters is what goes beyond it, and that starts with the table. A standard table is line-based and only takes short text. A Perspective Table takes whole blocks into a cell and becomes a structuring tool for real content.

  • Block cells with lists, paragraphs, code and images instead of single-line fields.
  • Nesting, spans and alignment for demanding layouts.
  • Sorting and status highlighting right in the rendered table.
  • Readable elsewhere too: in other Markdown programs the block stays a clean code block.

Tables that calculate

For numbers rather than text there is the second kind of table. The Perspective Datatable is a typed data table: every column has a value type, aggregate rows calculate live, computed columns evaluate an expression per row, and editing happens right in the rendered grid. That carries expenses, time tracking or inventory lists without turning into a database file.

  • Fixed value types per column, so numbers stay numbers and dates stay dates.
  • Aggregates that calculate live, and computed columns per row.
  • Editing in the grid, without switching to the source text.
  • Calculating in running text too: inline calculations use the same expression language.
  • Plain text stays plain text: the data sits unchanged in the Markdown file.

Document kinds that build on each other

Property profiles describe the fields of a document kind once, centrally for an area: with type, permitted values and default. The property editors suggest the fields and offer the value ranges as pick lists. Profiles inherit from each other: a base profile states what applies to all documents, and a kind such as article or meeting only adds its own share, excludes inherited fields where needed or overrides them. Which profile applies need not be written in the document: a tag or its folder is enough, and a symbol on the document shows which one it turned out to be. The permitted values of a field may likewise come from your own material instead of the definition.

  • Describe fields once instead of anew in every document: suggestions, pick lists and types come from the profile.
  • Inheritance with exclusion and overriding: shared fields in the parent profile, own fields in the document kind.
  • Soft hints instead of locks: deviations are named, nothing is blocked.
  • Assignment without an entry in the document: a tag or the folder decides which profile applies.
  • Value lists that keep themselves current: the permitted values come either from a note or from a query over your material.
  • Fields that carry a structure: A meeting with three participants needs one field instead of three parallel lists for name, role and company — in the metadata block it stays ordinary, readable YAML.

Lists that keep themselves current

Anyone keeping many files otherwise maintains overviews by hand, and they go stale the day they are written. A Perspective Query instead describes what is wanted, and the result appears right there in the document: a clickable list or table across the collection, filtered by properties, tags and file fields. When the collection changes, the output changes.

  • Topic pages that list their related files themselves.
  • Filters across frontmatter properties, tags and file fields.
  • Block and task level, not just whole files.
  • Every hit clickable, leading straight to its target.

When a query is not enough: scripts

Some evaluations cannot be phrased as a condition, such as a recursive tree along the links or an overview that calculates as it goes. Script blocks cover that: a block runs a small program, reads the same collection as the query, and outputs lists, tables or finished text into the document.

  • Free evaluations over the same data as the query.
  • Recursive structures and computed overviews that cannot be expressed declaratively.
  • Explicit trust model and runtime limits instead of silent execution.

And the rest of the language

Beyond the four large constructs, the language brings more than fifty extensions. None of it is compulsory: every one has its own switch, and whatever is turned off disappears from menus, commands and display instead of getting in the way.

  • Text extensions for callouts, footnotes, highlighting and abbreviations.
  • Presentation with formulas, diagrams and highlighted code; on a portable export a diagram travels along as a finished image.
  • Anchors, embeds and tags for references within the text.
  • The working day with tasks, reminders, events, templates and journals.
  • Individually switchable and open to your own extensions through a documented interface.

All of this is covered in detail in the manual: go to the manual