From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs as word processor Date: Fri, 22 Nov 2013 15:37:07 +0900 Message-ID: <878uwheycs.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5288A59E.7030109@dancol.org> <87vbzqfgd6.fsf@uwakimon.sk.tsukuba.ac.jp> <87mwl04w3k.fsf@zigzag.favinet> <87iovo4caz.fsf@zigzag.favinet> <877gc14vzs.fsf@zigzag.favinet> <878uwhxnqe.fsf@informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1385102244 28896 80.91.229.3 (22 Nov 2013 06:37:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Nov 2013 06:37:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Pascal J. Bourguignon" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 22 07:37:29 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 1VjkMq-0003Vi-SZ for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 07:37:29 +0100 Original-Received: from localhost ([::1]:37102 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjkMq-00047g-7r for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 01:37:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjkMg-00046f-J0 for emacs-devel@gnu.org; Fri, 22 Nov 2013 01:37:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjkMY-00082A-WD for emacs-devel@gnu.org; Fri, 22 Nov 2013 01:37:18 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:50345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjkMY-000811-F2 for emacs-devel@gnu.org; Fri, 22 Nov 2013 01:37:10 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 905E1970A20; Fri, 22 Nov 2013 15:37:07 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 80BEB1A5193; Fri, 22 Nov 2013 15:37:07 +0900 (JST) In-Reply-To: <878uwhxnqe.fsf@informatimago.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 182d01410b8d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:165532 Archived-At: Pascal J. Bourguignon writes: > - define a page size + page margins for the document. -1. That should a function of printing (including previewing final copy). Just text width. The interaction between page sizes and margins is quite complex if you want a good-looking and readable page. > - define header, body and footer areas of the pages. +1. But see below for comments on how that would be done. > They can be specified with versions for odd and even pages, -0.5. Just mirror the format for odd pages if you want the even pages to be different. > and with alternate versions for pages beginning chapters or > sections. -1. Way unnecessary for the first cut. > Since headers and footers can be edited with styles too, editing them > would have to call up secondary WYSIWIG windows. -1. Just edit them in-place, and when leaving that area prompt for whether it's that page only, or change the style for all pages. > - define styles, apply styles to tags. +1 > - 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. You're proposing yet another file format that would be useless for exchange with non-Emacs users? I don't see the point. > - 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. -0.5. All you really need is leading for the interword spaces when presenting fully justified text. I don't think Richard is thinking about photorealistic display (which you can't get anyway, even Word sometimes prints differently from what you see on screen). > 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. -1. No, PDF is static, not editable. If there's reason do movement differently in WYSIWYG editing buffers, probably the option should be available in all editing buffers. But I don't really see this as necessary at first. > 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. -1. Way unnecessary for the first cut. > 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. This is a Microsoft conspiracy to sell classes in Word use, I think. The things that regular people need to do with styles in a simple wordprocessor are relatively few. > 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. -100 (maybe more). Either you want to edit a markup language (a la CSS) "out of band", or make changes GUI-ly. Either way, we don' need no steenkin' metadata windows getting in the way of a bigger picture for the document we actually care about. > 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, I really don't see this. When you're in a "cell" (header, footer, body, object == table, figure), you should be able to edit that cell directly, and have it reflected in the stylesheet without special commands. Yes, there will be special commands because the _content_ of specials is different (instead of a literal numeral, there will be a "page_number" object in headers and footers, for example, and selecting from the available objects -- including the non-portable "sexp" of course!!). So we will require a special insert command, but not much more, I suspect. > 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. Metadata will be applied via text properties and overlays, no? I don't see a real difference between that aspect of the current Emacs buffer/redisplay model, and what you're talking about here. > 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). I suspect all this is quite far from what Richard is thinking about at this point. I understand what he wants (as a first cut) to be something like position cursor before the words "emphasize this text" type M-3 M-@ C-c C-f C-e see "emphasize this text" in italics (Aside to Richard: the key sequence C-c C-f C-e is compatible with AUCTeX, which uses C-c C-f as a common prefix for face-changing commands: emphasize, italic, bold, typewriter, .... Perhaps it would be nice to make the "M-@" implicit -> C-3 C-c C-f C-e.) Next step would be continuous leading for full justification. Probably after that add very simple header and footer capability, with a fixed number of lines per page (possibly using a very simple modeline-like format spec?) [Personally, I prefer to think of each chapter as a long scroll, and editing doesn't care about headers/ footers. YMMV of course, but that point of view suggests that headers, footers, and WYSIWYG pagination in general can come later than the within-page stuff.] The following step would be text that flows around objects (tables, figures). And all the while we think about how to add complex capability without adding complex UI. :-) All above is IMHO YMMV IANAL TINLA etc.... Steve