Killing the office suite

What you say definitely makes sense.

My primary way to write is either Markdown or, in creative writing cases where even Markdown is too code-ish for me to stay in a literary mindstate, a simplified pseudo-WYSIWYG like LyX's "WYSIWYM" which is still semantic, but represents things like emphasis visually.

I haven't needed to produce a presentation in the last few years, so I'm not sure what technology I'll prefer, but I suspect I'll be using something like reveal.js next time, both because it gives me that HTML/CSS/JS content/presentation/behaviour separation and because it's easy to take the HTML and do scripted processing/transformation on it.

As for spreadsheet use, I'm not sure whether I line up with your impressions. I have three main uses for LibreOffice Calc:

1. I definitely use it as you suspect: paired with a TSV-to-HTML Python script as an alternative to writing HTML table markup by hand.

(Though I do rely heavily on various keyboard-driven "do what I mean" behaviours like the semantics for copy-pasting from a single row/cell to a range of rows/cells, so reproducing just the GUI on top of an HTML table exporter isn't as simple as it initially appears.)

2. I also use it, coupled with autocomplete and copy/paste, as a way to prepare more or less unstructured data for import into a relational database.

(I can't find a single open-source SQLite-compatible GUI which can be efficiently controlled by the keyboard and understands foreign keys, so it's less painful to just use Calc's autocomplete and copy-paste in concert with a CSV/TSV import script which does validation and deduplication to shove tabular data into normalized relations.)

One of these days, hell will freeze over and I'll find time to write some kind toolbox for rapidly prototyping high-efficiency batch-entry UIs on top of an SQL dialect abstraction layer like the one in SQLAlchemy.

3. While I'm a programmer (and, thus, not "most people"), I do sometimes use LibreOffice Calc's computational ability. When the best UI really IS a grid of cells and the "code" is a directed graph of of functions, nothing compares with a spreadsheet. (Otherwise, I'll probably use IPython Notebook.)

Calc is definitely heavier than necessary for that, though. Another "rainy day" project: Some kind of PyQt application which ties "eval() each cell" behaviour to a tabular widget and uses the Python AST module to figure out which cells depend on which other ones for refresh purposes. (Or possibly in-browser when Skulpt gets far enough along to implement the AST module.)

(And, if I need a linear solver, I'm going to use GLPK's MathProg language or implement something higher-level using its Python bindings. A spreadsheet is, at best, an ugly, awkward way to define a linear program.)

I write in RST because it supports tables and all the fancy stuff - yet is an easy, straightforward pure text format.
Its a lot easier than HTML too (but mainly its a lot faster to write).

There's plenty of RST converters to anything and it seems much more suited than Markdown or pure HTML for many people. It just doesn't get the same press. A lot of people are using it however.

I really should get used to RST and, as a heavy Python programmer, I feel the pressure but, given how much impetus I already have to stick to other forms of markup, I never seem to get around to it.

- My Python docs are done using ePyDoc in ePyText-mode because ePyText is familiar and Sphinx is for writing manuals, not API docs. (A real API documentation tool can be configured to recurse through a package hierarchy, gathering ALL TODOs and printing warnings for code that's been left undocumented.)

(On a related note, I really need to make another attempt at detangling the code Sphinx uses to generate the index for its Javascript-based search system so I can write a Ruby index generator and migrate my blog from WordPress to GitHub Pages without having to use Google Site Search to maintain feature parity.)

- My favourite PIM tool is TiddlyWiki 2.x (and soon TW5 will be my favourite RAD platform for data-organization apps), which has its own markup.

- GitHub Pages and Issue Trackers don't support RST, which reduces the impetus to use the RST support in the README and Wiki.

- The bare RST supported by Pandoc is a rather wimpy dialect and I haven't figured out how to script Sphinx so I can get an asciidoc-like "Use a default template to render a single file without creating a whole new project" script.

- If I want a lightweight markup instead for writing a big book, LyX is WYSIWYM for LaTeX and asciidoc maps 1-to-1 to DocBook XML.

(And asciidoc also has a nice default template which makes it very appealing for quickly banging out a file with O'Reilly-esque markup including admonition icons)

Ugh. Clipboard got confused and pasted the wrong link.

admonition icons

I use MS Office at work, as a matter of corporate standards for "official" documents (in particular, for a few complex spreadsheet templates).

But aside from that, I mostly stick to text formats... plain text, evolving into markdown or asciidoc if I find myself needing a nicely formatted version. Writing stuff in HTML directly... definitely not. The mental cost of working with tags is just too high, especially for tables where you're a minimum of four levels deep before you even start adding content.

Do you know Ethercalc yet?

For quick notes and documentation, Markdown is super easy. There's a project on GitHub for converting it to HTML et al. called MultiMarkdown
Speaking of LyX above: Forget it. Their LaTeX output is too ugly :)