(Many answers and comments to this question ask for some more context as to the purpose and needs of the said “word processing”. Which is kind of an essential question, of course. What the original asker actually wants to do with the tool largely determines what kind of software they should be looking for.)
Principles
As of this writing, I did not immediately find comments from the original asker clarifying their intent and needs concerning “word processing”.
Still, my recommendation to anyone looking for a general “word-processing” tool — or rather, a document creation toolset — is based on two principles:
Look for an editor that will produce documents in a standard, widely-accepted, structured markup format which several tools can process (so not tied to a single vendor), and which is expressive enough to mark up complex prose or (technical) documents. There are basically five such formats:
- DocBook (Used for many O’Reilly books)
- DITA (maybe better-suited for larger, collaboratively written projects which share bits and pieces but not so much for individual, self-contained documents?)
- XHTML5 (maybe lacks the number of finer-graded semantic and structural elements present in DocBook that are useful for actually describing a complex book-like title, but you can’t get much more universal than (X)HTML in terms of support)
- reStructuredText (rst, as used for Python documentation, among other projects)
- LaTeX (more of a print layout markup format than a pure structured document format but still structured and abstract enough to suffice for this purpose (and venerable enough to deserve a mention))
Pay attention to features in the markup language which facilitate the markup of different semantic span segments, and block elements such as chapters, sections, admonitions, quotations, excerpts of terminal output (for technical documents), author and document metadata, complex tables, pixel-based and vector images, etc.
Conversely, keep clear of “easy” document markup formats which are ill-defined both in terms of expressiveness and standardization, such as the ever-present Markdown. (The initial easiness and ad hoc-ness comes with a price which you start paying later on when you want to do anything more complex.)
Try to find a document editor which allows access to the raw markup, but does not force you to work in the raw markup mode — a so-called WYSIWYM (What You See Is What You Mean) editor.
The basic principle behind a WYSIWYM, structured document editor is that it resembles a “consumer” word processor in that editing is a breeze — you can edit the document directly in a styled preview mode — but still lets you keep tabs on what is exactly happening in the markup and structure of the document and ensures that the produced markup will never be invalid or contain superfluous auto-generated markup — much less any messy ad-hoc styling, which is a common and almost unavoidable occurrence in the “consumer” word processors even if you do not want any such styling.
This is typically achieved in a WYSIWYM, structured document editor by it only ever producing document structure that correctly validates against a given document markup schema. In other words, the editor is “strictly validating” and, at any point, simply does not let you insert markup elements in the document structure that would go against the document markup schema but keeps them out of reach from you — grayed out or filtered out in the lists and menu or toolbar options where you might otherwise choose them.
That said, a WYSIWYM structured document editor usually does not require you to work with the raw markup elements as such (or that much) but will present at least the most common ones — such as the different section/heading elements, basic paragraphs, or different types of lists or spans of emphasis — as easily-accessible toolbar buttons and keyboard shortcuts.
I would advise keeping clear of the purported “WYSIWYM” editors which show you a styled document preview in one pane but only allow editing the content in another which shows you the raw markup. This kind of a “lazy man’s” implementation is somewhat counterproductive and not how a true WYSIWYM editor works. While it is important to have access to the raw markup as well, it is much easier to edit and maintain the document if you can type text directly in a styled view which does not let you produce invalid structure, which shows you a rendition of the document with some rudimentary styling, and which does not force you to think the document in terms of raw markup all the time.
Recommendation
Given the above principles, my personal favorite for structured document creation and editing is currently a WYSIWYM editor called XMLmind XML Editor (pictured above), which is “is a strictly validating, near WYSIWYG, XML editor” supporting DocBook, DITA, and XHTML markup, and “Free to use by individuals, open source projects and non-profit organizations.” I use it in the DocBook mode, specifically.
This preference for DocBook is because I find DocBook expressive enough in its semantic markup for most literary works, well-suited for self-contained documents, and a good “manuscript” or “source code” format from which conversions can be made to lesser distribution formats.
The preference for the XMLmind XML Editor is because it does not get in your way and lets you type in content “directly” while viewing it with a nice preview stylesheet, and also keeps the document structure in check (in adherence to the DocBook document schema) — so I do not have to do any manual validation, ever, or worry about the structure or markup itself being incorrect.
To fully appreciate the editor, you need to teach yourself about the Ctrl + arrow keys, Ctrl + I, Ctrl + R, Ctrl + T, Ctrl + E and other shortcuts for dealing with basic element selection and nested elements, and you need to teach yourself a bit about the DocBook format itself (what elements are available, how they are supposed to be used, and what kind of attributes they take). But once you have passed those hurdles, it otherwise feels much like a “saner Word” where things are always in order and nothing will ever happen behind your back.
It is important to learn the keyboard shortcuts for everything, though, down to choosing DocBook elements from the offered, context-sensitive list by typing in a part of their name, as it makes you much more productive than clicking the menus and dialogs with a mouse.
Benefits of structured document markup
I like the fact that in structured document markup, structure and semantics is everything, and the final styling (via style sheets) is something that you only worry about later, once you have produced the content. This is how it should be, especially in the modern world where there can be many ways to consume the content, and many different content styling requirements and distribution formats.
Working with structured, semantic markup lets you focus purely on the content and the task at hand instead of getting lost with adjusting minor styling details “in-place” — often with disastrous results, and a need to do constant readjustments when you change something in the content later on, as is common in “consumer” word processors. Unfortunately, the “consumer” word processors have, so far, only had feeble attempts to implement any structure to their workflows and seem to mix structure with unwanted inline styling all the time.
Further considerations
To go from a DocBook “manuscript” to a distribution format, such as PDF or EPUB, you need a document processing toolchain of some sort which will filter the document through a stylesheet and produce a transformed copy in the distribution format while generating a table of contents and other such structures. The aforementioned XMLmind XML Editor includes some such conversion tools (e.g. a conversion from DocBook to HTML format) but you could also use external toolsets, and tweak their conversion parameters and stylesheets to your liking.
If you find the LaTeX route better-suited for your purposes, you will probably want to look at a WYSIWYM editor for LaTeX called LyX.
For reStructuredText, there’s the Sphinx document processor, which probably warrants a honorable mention, but no compatible free WYSIWYM editor (that I know of)... so you’re pretty much restricted to a standard programmer’s text editor when editing the content. And while reStructuredText does many things better and in a more standardized way than Markdown (except for the heading markup, which is very weird and icky in rst), it is still an overgrown README format trying hard to be something like XML without tags, which is a somewhat doomed battle. Beyond very basic formatting, you need to introduce some kind of “tags” and markup with complex syntactical rules anyway and editing your “simple text file with complex rules” will pretty quickly get just as involved as when using actual XML markup to hold the document structure — only with a less explicit syntax and less standardized tools to deal with it.
