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:24 +0100 Message-ID: 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> <878uwheycs.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1385154415 27452 80.91.229.3 (22 Nov 2013 21:06:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Nov 2013 21:06:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen J. Turnbull Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 22 22:07:00 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 1VjxwJ-0005L5-S6 for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 22:07:00 +0100 Original-Received: from localhost ([::1]:41057 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjxwI-00084V-Mc for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 16:06:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjxw8-00084F-GB for emacs-devel@gnu.org; Fri, 22 Nov 2013 16:06:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vjxw2-0000vG-Kk for emacs-devel@gnu.org; Fri, 22 Nov 2013 16:06:48 -0500 Original-Received: from voyager.informatimago.com ([88.198.62.69]:58477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjxw2-0000ot-7l for emacs-devel@gnu.org; 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 6FCB843C4C4; Fri, 22 Nov 2013 22:06:30 +0100 (CET) In-Reply-To: <878uwheycs.fsf@uwakimon.sk.tsukuba.ac.jp> 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:165578 Archived-At: On 2013/11/22, at 07:37 , Stephen J. Turnbull wrote: > Pascal J. Bourguignon writes: >=20 >> - define a page size + page margins for the document. >=20 > -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. See my answer to Eli, this is on the contrary an essential element of a = WYSIWIG word processor. >> - define header, body and footer areas of the pages. >=20 > +1. But see below for comments on how that would be done. >=20 >> They can be specified with versions for odd and even pages, >=20 > -0.5. Just mirror the format for odd pages if you want the even pages > to be different. That's the point of having a word processor in emacs: you can program = this kind of rules. But I assure you that I have much more books and = documents that don't have symetrical headers or footers. >> and with alternate versions for pages beginning chapters or >> sections. >=20 > -1. Way unnecessary for the first cut. Hey! The first cut should implement MY use case! :-) >> Since headers and footers can be edited with styles too, editing = them >> would have to call up secondary WYSIWIG windows. >=20 > -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. Possibly. >> - define styles, apply styles to tags. >=20 > +1 >=20 >> - assign parenthesized tags to text ranges (in a hierarchical = structure >> similar to SGML). >=20 > ?? Cf. my answer to Eli. >> - 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. >=20 > You're proposing yet another file format that would be useless for > exchange with non-Emacs users? I don't see the point. DocBook DTD are rather de-facto standards, and is based on standard = SGML/XML, DTD, and XSL. I've not proposed to create a new file format, = but to specify what _standard_ file format will be used for our word = processor documents. What may be non-standard, is the way we package = the data and metadata. Microsoft products and LibreOffice use zip = archives of files in standard formats including XML. There's nothing = bad with that. >> - 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 > -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). When you have 227 dpi screens? To print on a 400 dpi printer? I doubt a lot of people would see the difference! >=20 >> Scrolling and zooming would behave differently in those WISIWIG >> windows, since they would contain essentially a graphic >> representation of the page, like when we render PDF files. >=20 > -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. >=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 > -1. Way unnecessary for the first cut. I'm not discussing Agile project management methodology. I'm = considering the specifications of the FINAL product. I'm tring to imagine what could be the objective, to see if it would be = worth the effort. A "first cut" as you're cutting it, doesn't interest me, it's not worth = the effort. That's probably why nobody worked on it for 25 years. >> 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 > 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. >=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 > -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. Already, while editing pure text programs, I find the display in the = minibuffer of the syntactic information very useful. If I was editing a = document with a structure hidden, I would find it even more useful. (setq c-echo-syntactic-information-p t) >> 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

The RET
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, >=20 > I really don't see this. When you're in a "cell" (header, footer, > body, object =3D=3D table, figure), you should be able to edit that = cell > directly, and have it reflected in the stylesheet without special > commands. Why? Why should it be the modification of the global style rather than = just the creation of a new style just for this character? Or this word? = Or this paragraph? etc. Think also about the notion of cascading in cascading style sheets. = What level of the cascade do you want to edit anyways? > 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. >=20 >> 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. >=20 > 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. >=20 >> 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). >=20 > 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 >=20 > position cursor before the words "emphasize this text" > type M-3 M-@ C-c C-f C-e > see "emphasize this text" in italics Richard said word processor, not enriched-text-mode. --=20 __Pascal Bourguignon__ http://www.informatimago.com