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: Mon, 25 Nov 2013 05:55:16 +0200 Message-ID: <83iovhb0ez.fsf@gnu.org> References: <87vbzqfgd6.fsf@uwakimon.sk.tsukuba.ac.jp> <83vbzkcx20.fsf@gnu.org> <83d2lrczi7.fsf@gnu.org> <8338mmcsd9.fsf@gnu.org> <83txf1blf2.fsf@gnu.org> <87txf133yd.fsf@zigzag.favinet> <83r4a5bj5x.fsf@gnu.org> <87mwktdy6r.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1385351715 26921 80.91.229.3 (25 Nov 2013 03:55:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Nov 2013 03:55:15 +0000 (UTC) Cc: ttn@gnuvola.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 25 04:55:19 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 1VknGZ-0002oh-1V for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2013 04:55:19 +0100 Original-Received: from localhost ([::1]:49562 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VknGY-0001Oo-9J for ged-emacs-devel@m.gmane.org; Sun, 24 Nov 2013 22:55:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VknGR-0001Ka-4r for emacs-devel@gnu.org; Sun, 24 Nov 2013 22:55:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VknGM-0001Cs-4G for emacs-devel@gnu.org; Sun, 24 Nov 2013 22:55:11 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:60545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VknGL-00018t-Se for emacs-devel@gnu.org; Sun, 24 Nov 2013 22:55:06 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MWS00C00VZDWG00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Mon, 25 Nov 2013 05:55:04 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWS00C64W7RT4B0@a-mtaout23.012.net.il>; Mon, 25 Nov 2013 05:55:04 +0200 (IST) In-reply-to: <87mwktdy6r.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:165677 Archived-At: > From: "Stephen J. Turnbull" > Cc: Thien-Thi Nguyen , > emacs-devel@gnu.org > Date: Mon, 25 Nov 2013 11:15:08 +0900 > > > Indentation and justification are no different. > > Ah, but they *are* different, at least potentially. Default line > spacing can be implemented by changing the depth of the character box, > uniformly without respect to the identity of the character, for all > characters covered by that face. (I suspect that's how this works in > Emacs; XEmacs doesn't have the feature AFAIK.) I don't think I understand what you mean by "depth of the character box". Emacs just computes the pixel y-coordinate of the next line differently when this property is used. > Indentation and justification are much more complex: they depend on > the semantics of the text, possibly including the particular > characters. For example, in Japanese typography, punctuation and > certain ligatures are allowed to protrude on the right margin in > fully justified text. And line spacing *also* should have a variant > that applies to larger units of text. Sorry, I don't see the difficulties. Emacs already examines the properties of each character when it displays text, and its word-wrap and truncation/continuation decisions already take issues similar to the above into consideration. > > [Structured styles] is the source of all evil in Office. The > > result is a terrible mess where the user ends up having no control > > on what is going on in her document (except for very short > > documents). No, thanks. > > No, that's not the problem. The problem is that *Office separates > editing of styles from editing of the document, making style editing > the province of experts. And *Office does a rather sucky job on > things like indentation and mark formatting of bullet lists and > enumerations (at least in Japanese documents). No, the problem is that if you make changes in some part of text that modify its typeface or indentation or properties of the numbered list, these changes suddenly affect the entire document. > Concretely, if you edit a section heading's style (eg, changing > Helvetica to Times New Roman), Emacs could issue a query asking > > Do you want to edit just this instance? > Change font family to /Times New Roman/ in section headings at: > [All levels] [This level] [This heading only] [Cancel] > [ ] Review exceptional headings at affected levels Nuisance, if done by default. When I edit a piece of text, I mean to edit only that piece of text. If I want to edit all pieces of text that use some style, I should say-so in advance.