From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hendrik Boom Newsgroups: gmane.emacs.devel Subject: Re: Emacs as word processor Date: Mon, 2 Dec 2013 19:30:03 +0000 (UTC) Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1386013219 13302 80.91.229.3 (2 Dec 2013 19:40:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Dec 2013 19:40:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 02 20:40:24 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VnZM0-0005Th-7e for ged-emacs-devel@m.gmane.org; Mon, 02 Dec 2013 20:40:24 +0100 Original-Received: from localhost ([::1]:38559 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnZLz-0007RD-Qs for ged-emacs-devel@m.gmane.org; Mon, 02 Dec 2013 14:40:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnZLq-0007Ok-4p for emacs-devel@gnu.org; Mon, 02 Dec 2013 14:40:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnZLi-0001Mj-Py for emacs-devel@gnu.org; Mon, 02 Dec 2013 14:40:14 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:43422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnZLi-0001KF-KA for emacs-devel@gnu.org; Mon, 02 Dec 2013 14:40:06 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VnZLg-0005Cm-N5 for emacs-devel@gnu.org; Mon, 02 Dec 2013 20:40:04 +0100 Original-Received: from topoi.pooq.com ([69.165.131.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Dec 2013 20:40:04 +0100 Original-Received: from hendrik by topoi.pooq.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Dec 2013 20:40:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 85 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: topoi.pooq.com User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:166018 Archived-At: On Sun, 17 Nov 2013 02:28:51 -0500, Richard Stallman wrote: > 25 years ago I hoped we would extend Emacs to do WYSIWG word processing. > That is why we added text properties and variable width fonts. > However, more features are still needed to achieve this. > > Could people please start working on the features that are needed? There is one reason that I use emacs for my writing. The file structure is very compatible with modern distributed revision management systems. (I use monotone). When I edit stuff, only the bit I'm editing changes. The rest stays the same. I've introduced minimal mark-up, so that I can specify italics and such when I need them. And I wrote a program to convert the (almost) plain- text to .fodt so I can feed it into LibreOffice for a nice printout. Maybe I should just have used asciidoc or markdown. But when I started on this stuff I didn't know about those tools, and maybe the didn't exist yet. The main spec for this program is that it doesn't choke on *any* input, and does something reasonable with it whether it is nicely marked up or not. I avoid large-scale bracketing structure as much as I can, because the merge tools used with revision control are terrible at preserving brackets. I OpenOffice would place lots of line breaks in consistent places so that revision management would merge properly, .fodt's bracket structure would *still* be a problem, because LibreOffice chokes on bracket mismatch. So in my markup, I assign operator priorities to separators -- like paragraphs, sections, and so forth. The code is a mess, because I didn't realize this at first. Everything will need to be rewritten a few times before my program does what I want and is really well-structured. But hey, this is experimental (textual) UI programming, and you don't know what you want until you have it and it isn't it. I wouldn't mind in the slightest if I were to be editing WYSIWYG and the word-processor were to save my data in an internal format that's amenable to revision management and automatic merging. Especially if it avoids layout-specification overkill the way most word processors do. I'm really interested in a document compiler where I specify structural matters and the word processor shows me how it might look on a page. But the page layout shouldn't be definitive. If I map it onto a different page size, it should reflow, adjust. In fact, it might as well adapt itself to a scrolling resizable GUI window the way well-written HTML does. What's needed for this? A layout manager that constantly recalculates what should be in the screen as the text it's laying out changes. And an editor-interface to that layout manager that does the usual editor commands as applied to the non-laid-out source code. Well, actually, we should accept that a document is a data structure. A data structure that's traditionally represented mapped onto a long string of characters, or as ink in paper in a particular style of arrangement. It's a data structure just as much as a Lisp program is a data structure, traditionally represented either with pointers in RAM or as text with lots and lots of parentheses. The underlying data structure is what we want to edit. It needs to have a representation that's amenable to revision control. Possibly every object in the data structure gets a persistent name (maybe a random 64-bit number) and the objects (paragraphs, sentences, chapters, etc) refer to each other by these names and the set of objects is written out in order, sorted by name. With lots of newlines. That should merge properly. Anybody up for this? The data structure could be reusable in completely different kinds of applications, not just word processing. It could be manipulated with different views, ones "showing codes" as WordPerfect used to so, ones that WYSIWYG, whatever. I don't know if any of this is like what emacs does internally. I don't know if anyone has built a mergeable object store like this. -- hendrik