From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.devel Subject: Re: Emacs as word processor Date: Fri, 22 Nov 2013 01:51:37 +0100 Organization: Informatimago Message-ID: <878uwhxnqe.fsf@informatimago.com> References: <5288A59E.7030109@dancol.org> <87vbzqfgd6.fsf@uwakimon.sk.tsukuba.ac.jp> <87mwl04w3k.fsf@zigzag.favinet> <87iovo4caz.fsf@zigzag.favinet> <877gc14vzs.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385081574 28159 80.91.229.3 (22 Nov 2013 00:52:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Nov 2013 00:52:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 22 01:52:59 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 1VjezS-00043l-Cn for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 01:52:58 +0100 Original-Received: from localhost ([::1]:36021 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjezR-0005nl-8n for ged-emacs-devel@m.gmane.org; Thu, 21 Nov 2013 19:52:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjezI-0005nY-To for emacs-devel@gnu.org; Thu, 21 Nov 2013 19:52:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjezD-0006ke-NM for emacs-devel@gnu.org; Thu, 21 Nov 2013 19:52:48 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:38780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjezD-0006ka-CC for emacs-devel@gnu.org; Thu, 21 Nov 2013 19:52:43 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VjezC-0003xl-7U for emacs-devel@gnu.org; Fri, 22 Nov 2013 01:52:42 +0100 Original-Received: from 90.24.199.117 ([90.24.199.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Nov 2013 01:52:42 +0100 Original-Received: from pjb by 90.24.199.117 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Nov 2013 01:52:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 167 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 90.24.199.117 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:ZmQ1MzhlNjYwZWRiMDFmYmU1MjM3OWMyNzNiNjRlOTNmNjFkZDZmMA== 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:165516 Archived-At: Richard Stallman writes: > I mean a simple way to put some text in a different font, such as a > 14-point bold font for a title, and have it (1) display on the screen > in that font and (2) have that markup saved in the file. > > Emacs can already display a piece of text in that font, but it lacks a > convenient user-level feature to do this whole job. So, let's start some specifications for an emacs wordprocessing-mode. - define a page size + page margins for the document. - define header, body and footer areas of the pages. They can be specified with versions for odd and even pages, and with alternate versions for pages beginning chapters or sections. They can also contain dynamic parts (eg. foot notes from text laid out on a page may be inserted in the footer of the page). Since headers and footers can be edited with styles too, editing them would have to call up secondary WYSIWIG windows. - define styles, apply styles to tags. - assign parenthesized tags to text ranges (in a hierarchical structure similar to SGML). - define a file format. I'd propose SGML with a DTD usable by docbook for the data, extended with as metadata a description of the document layout (page size, styles, etc). Perhaps DocBook XSL (style sheets) could be used for the metadata. - then for the WYSIWIG aspect, we'd need to implement a rendering engine. We have the basis with font faces, but more work is needed to give a WISIWIG representation of the page, and its computed layout. Scrolling and zooming would behave differently in those WISIWIG windows, since they're would contain essentially a graphic representation of the page, like when we render PDF files. Page margins, paragraph margins (set in the paragraph style), and other elements could have graphical controllers overlaid for GUI interaction, as well as being editable with normal keyboard commands, like the scroll-bar, menu-bar and tool-bar options. One problem is that there are parts that have a lot of editable metadata, but which are not represented at all in a WYSIWIG document. That's the reason why people have so much a hard time to use and apply styles with word processors: they presence and definition is hidden, since they're not "printed out", only their effect is visible. A solution in emacs could be to use a second window, a metadata window (a little like a minibuffer, but probably bigger), that would appear automatically when editing a WYSIWIG window, so that when moving the cursor on a cell in the WYSIWIG window, style and other metadata can be displayed in the metadata window, and editing commands can then be given that modify the metadata and are reflected WYSIWIGLY in the WYSIWYG window. In terms of user interface this kind of word processor also has this problem: you have to have a duplicate set of commands for the metadata than for the data. When you edit plain text, or plain text with markup (either "implicit" thru formating like in reStructured Text or markdown, or tagged text in the SGML family), you use the same command set to edit both the data and the metadata. Even to edit both at the same time! M-x replace-string RET

The RET
And the RET But in the case if a WYSIWIG word processor, as long as we don't provide a plain text data+metadata buffer to be edited in emacs as plain text, we need to define two sets of commands, since basically we have in the WYSIWIG window only the data (which can edited with usual emacs text editing commands), and in the metadata window, only the metadata of the current cell (or the current path of metadata nodes from the root of the document down to the current cell, in the document structural hierarchy). +------------------------------------------------------------+ | Chapter 1. Example | | Section 1.1. Subtitle | | Sentence 1 of paragraph 1. [S]entence 2 of | paragraph 1. +--U:**- Document.ewp ----(word)------------------------------+ | | |

| | +--U:**- Document.ewp/style.estyle ----(word-style)-----------+ With [S] representing the cursor on the letter S. I don't see how usual emacs commands can be used to edit such a style sheet path in the metadata window, since it's kind of a transveral view. Of course, when giving a command to change eg. the font of a region, we could have text to edit with the regular emacs commands, either in the minibuffer or in a box in the metadata window, but a M-x replace-string RET would not be too useful on such a view. Also, notice that a lot of interesting commands can be implemented, that don't have a nice representation of the data they would work on. For example, we could want a command that would replace the style of all paragraph from "standard" to "personalized". M-x replace-paragraph-style RET standard RET personalized RET This would reflect on the WYSIWIG window as an updated layout and presentation. And if we happen to have the cursor on a paragraph that had the "standard" style, that would update the metadata window to now show that the current paragraph style is now "personalized". Buf if that wasn't the case, we would have no feed back, or just a little feed back in the WYSIWIG window, but often style changes are not drastic therefore little noticeable. And this is the fundamental problem with word processors and WYSIWIG editors. Since data and metadata is separated, a text editor becomes useless to work on them. So the bet here is that adding a new set of commands to edit the metadata could be done in a way that's sufficiently practical and usable to make editing WYSIWIG document a little more agreable than editing plain tagged text (SGML, reStructuredText, LaTeX, etc). And that the work needed to implement it will be offset by the sure win that with such a set of commands, we will be able to further write other commands in emacs lisp to manipulate emacs word processing document. But then consider also that if the document is a structured tree, it can be represented as a sexp (and only a validator would be needed to put back such a document sexp modified by some user command), and similarly, the style sheet can be represented as a sexp, so fundalementaly, no additionnal function or commands are used to write emacs lisp code to manipulate them. We can still provide some utility to ease navigation and modification of those trees while keeping their validity as document and metadata trees. A little like we could just take (buffer-substring) and modify it in lisp before putting it back into the buffer, or we could use (forward-word), (delete-region s e), etc, to edit the buffer directly. Only now we don't have just words and informal paragraph, but we have a true document structure to support the styles, and we have a metadata buffer with commands to edit the style sheet. (map-styles (lambda (style) (incf (style-fontsize style))) document) (add-style "newstyle" '(:fontsize (pt 10) :left-margin (cm 3))) (replace-style 'paragraph "oldstyle" "newstyle") Finally, let's note that a system like docbook can deal with different kinds of document structures thru the DTD, and that the XSL are designed to process specific kinds of DTD, so the structure of the style sheets and the structure of the documents are not hard coded, but can be parameterized with the equivalent of the DTD. I'd move to support docbook file formats, XML, XSL and DTD as external format for the emacs word processing mode, as long as we convert them internally as sexps so we may process them in a lispy way. -- __Pascal Bourguignon__ http://www.informatimago.com/