From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs as word processor Date: Fri, 22 Nov 2013 17:04:56 +0200 Message-ID: <83txf4cw9z.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1385132707 24998 80.91.229.3 (22 Nov 2013 15:05:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Nov 2013 15:05:07 +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 16:05:12 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 1VjsIB-0006Tg-Bm for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 16:05:11 +0100 Original-Received: from localhost ([::1]:39348 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjsIA-0005gn-Qg for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 10:05:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjsI1-0005bp-8A for emacs-devel@gnu.org; Fri, 22 Nov 2013 10:05:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjsHt-0003sT-J5 for emacs-devel@gnu.org; Fri, 22 Nov 2013 10:05:01 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:54768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjsHt-0003sE-6d for emacs-devel@gnu.org; Fri, 22 Nov 2013 10:04:53 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MWO00I007754300@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 22 Nov 2013 17:04:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWO00IIY7820A40@a-mtaout20.012.net.il>; Fri, 22 Nov 2013 17:04:51 +0200 (IST) In-reply-to: <878uwhxnqe.fsf@informatimago.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:165562 Archived-At: > From: "Pascal J. Bourguignon" > Date: Fri, 22 Nov 2013 01:51:37 +0100 > > - define a page size + page margins for the document. IMO, this is more important for printing. For display, it's enough to start with the locale's defaults. > - 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. Separate windows could be a solution, but it would be much more cool to do what the word processors do: make the rest of the page un-editable, and dim it to make that apparent, then let you edit only the header/footer part. > - define styles, apply styles to tags. Isn't a "style" just another word for a "face"? > - assign parenthesized tags to text ranges (in a hierarchical structure > similar to SGML). Not sure what for. This is a solution to what problem? > - 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. I think you underestimate the power and feature-richness of the current Emacs display engine. We should try using it first, before we decide that it is inadequate and should be replaced or significantly changed. > 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. I see no need for abandoning graphical text display we use now. None of the leading word processors does, AFAIK. Switching to displaying pictures has many drawbacks; e.g., you cannot easily copy/paste with it, and the display complexities will grow by orders of magnitude, for now good reason. > 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. We have the fringes and the display margins for that, we just need to use them. > 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. The leading word processors have this feature, so we should have that as well. It doesn't have to be another window, though: we could show the meta-data and control codes as part of the text. > 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). It's much better to have the same command do both. We could implement heuristics that would guess the user intent most of the time, with user options to override that as needed. Most users will not need nor want to edit the formal description of the style, be it XML or whatever. They will settle for a Customize way of personalizing the styles.