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 22:06:23 +0100 Message-ID: <416D7143-AE4A-45FF-A3A3-AA208D268D97@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> <878uwhxnqe.fsf@informatimago.com> <83txf4cw9z.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1385154436 27746 80.91.229.3 (22 Nov 2013 21:07:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Nov 2013 21:07:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 22 22:07:21 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 1Vjxwf-0005ca-BO for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 22:07:21 +0100 Original-Received: from localhost ([::1]:41061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjxwe-0008TI-MS for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 16:07:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjxwI-00086L-Tb for emacs-devel@gnu.org; Fri, 22 Nov 2013 16:07:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjxwD-0000zB-0F for emacs-devel@gnu.org; Fri, 22 Nov 2013 16:06:58 -0500 Original-Received: from voyager.informatimago.com ([88.198.62.69]:58476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjxw2-0000on-7z; Fri, 22 Nov 2013 16:06:42 -0500 Original-Received: from galatea.home (unknown [90.24.199.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by voyager.informatimago.com (Postfix) with ESMTPSA id 71BF043C175; Fri, 22 Nov 2013 22:06:29 +0100 (CET) In-Reply-To: <83txf4cw9z.fsf@gnu.org> X-Mailer: Apple Mail (2.1283) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 88.198.62.69 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:165579 Archived-At: On 2013/11/22, at 16:04 , Eli Zaretskii wrote: >> From: "Pascal J. Bourguignon" >> Date: Fri, 22 Nov 2013 01:51:37 +0100 >>=20 >> - define a page size + page margins for the document. >=20 > IMO, this is more important for printing. For display, it's enough to > start with the locale's defaults. My point is that WYSIWIG doesn't mean anything when you don't consider = an "external" medium. Paper, PDF file, web page. Paper and PDF files are mostly the same, rendering on a web page is = different (the pagination differs). Page size is important to a document, because unfortunately, automatic = layout cannot take decisions like reordering paragraphs or figures, and = editing paragraphs so that they fit on a page. And again, THIS is the only reason why WYSIWIG as some value. If you want to consider webpages, I'd say that nowadays you would still = have to consider the size of the area where the document is to be = rendered, since web designers tend to enforce fixed frames, instead of = letting the browser flow the text to the random window size. This is a = fact of life. So you may also have to set at least a page width to edit = WYSIWIGLY a web page. >> - 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). >>=20 >> Since headers and footers can be edited with styles too, editing = them >> would have to call up secondary WYSIWIG windows. >=20 > 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. Possibly. This is a user interface question that can be solved later. = What I wanted to point out, is that headers and footers, like styles, = are a-priori independent of the page or even the document they appear = in. >> - define styles, apply styles to tags. >=20 > Isn't a "style" just another word for a "face"? For a character, perhaps. For higher level nodes, a style may be more = complex, up to procedural styles, were you call up a lisp function to = "font-lock" and justify the node (paragraph, chapter, etc). For = paragraphs you would have margins and indentations and perhaps drop cap = styles, etc. >> - assign parenthesized tags to text ranges (in a hierarchical = structure >> similar to SGML). >=20 > Not sure what for. This is a solution to what problem? What I mean here is some kind of structured editing. To split a paragraph in two, we can admit the usual RET key. To split a section in two, we can admit the usual insertion of a section = title. But already here, most probably the user will enter a new paragraph = containing the section title, and then select it and apply a header = "style". Well, it's not style, it's the specification of a section = header tag to this text, and by inference, the spitting of the current = section in two. Those two examples have conventional "width of the ass of the horse" = user interfaces, for conventional pre-defined tags:
= <para>. But with the introduction of XSL and DTD, the user can be allowed to = edit documents with a structure not pre-wired, with tags having now = pre-defined conventional user interface. =20 Therefore we need a standard way to edit the document tree. In case of sexps, we use paredit. What do we use to edit a tree that is = invisible, but thru its typographied and laid yout leaves? >> - 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. >=20 > 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. Perhaps. It's true that with truncate-lines mode, we'd get a a = homothetic space, but can we adjust the height of the lines, can we = adjust margins (to subpixel sizes). We'd have to disable removing = truncate-lines mode, and we'd have to ensure that changing the line = count or line height doesn't change the page height. I've not read the source, perhaps it's already implemented, but I've = never seen in the behavior of emacs display engine indications that it's = able to change characters in a page without shifting everything beyond = them. >> 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. >=20 > I see no need for abandoning graphical text display we use now. WYSIWIG. What we have now is not. > 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. Any WYSIWIG word processor displays a picture on the screen, and let you = edit the underlying text data structure. Even emacs does just that, = only it has a more direct correspondance between character cells on = screens and character slots in the buffer. For example, in scrolling a word processor let you scroll pixel by = pixel, while emacs let you only scroll line by line, even in the splash = window. Just take a good look at any WYSIWIG word processor window, and count = the character pixels vs. the graphic pixels. There's a lot of graphics = on them: rulers, margins,=20 >> 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. >=20 > We have the fringes and the display margins for that, we just need to > use them. WYSIWIG. I wouldn't mind a text editor that would let us edit enriched text.=20 But strangely, I doubt that would attract new users. >> 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. >>=20 >> 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. >=20 > 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. Well, not part of the text, that would defeat the WYSIWIG aspect, but = they may be represented graphically, overlaid on or around the text. = There may be tip tool boxes, and stuff. Now, some web editors provide three views of the document: - WYSIWIG web page, rendered just like in a browser, but editable as in = any word processor. - tagged document, where the web page is still rendered like in a = browser, but each element is adorned with a graphic tag that can be = manipulated (selected, edited, moved around, etc). - plain text editor of the HTML. I would say that this solution works well enough, you can switch easily = from one view to another depending on the kind of editing action you = want to perform at the moment, and you have full access to all the = levels. But in a way, it represents the failure of the WYSIWIG word processor, = since as soon as you have something more complex than MacWrite, = basically, you have to revert to a structured editor, or to a plain text = editor. For us programmers it would be a good and nice solution. But users can't deal with the structured view and much less with the = "code" of the HTML text view. So I think we should try to find a solution to let plain users perform = structural editing of their documents and style sheets easily, in a = WYSIWIG editor. But indeed perhaps there's no other solution than to = present alternative, lower level and non WYSIWIG views. >> 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. >>=20 >> 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! =20 >>=20 >> M-x replace-string RET <p>The RET <br>And the RET >>=20 >> 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). >=20 > 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. Yes, or use predefined style sheets and document structures. --=20 __Pascal Bourguignon__ http://www.informatimago.com