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 19:39:58 +0200 Message-ID: <837gbwbcsx.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> <83iovhb0ez.fsf@gnu.org> <87k3fxdpmg.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1385401197 7417 80.91.229.3 (25 Nov 2013 17:39:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Nov 2013 17:39:57 +0000 (UTC) Cc: ttn@gnuvola.org, emacs-devel@gnu.org To: stephen@xemacs.org (Stephen J. Turnbull) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 25 18:40:02 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 1Vl08d-0005Rp-8S for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2013 18:39:59 +0100 Original-Received: from localhost ([::1]:54091 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl08c-0002qq-Tq for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2013 12:39:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl08V-0002qe-TJ for emacs-devel@gnu.org; Mon, 25 Nov 2013 12:39:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vl08R-0007oq-2r for emacs-devel@gnu.org; Mon, 25 Nov 2013 12:39:51 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:36389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl08Q-0007ol-R5 for emacs-devel@gnu.org; Mon, 25 Nov 2013 12:39:47 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MWT00700YAX9C00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 25 Nov 2013 19:39:44 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWT007K8YE78J10@a-mtaout20.012.net.il>; Mon, 25 Nov 2013 19:39:44 +0200 (IST) In-reply-to: <87k3fxdpmg.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.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:165708 Archived-At: > Cc: ttn@gnuvola.org, > emacs-devel@gnu.org > From: stephen@xemacs.org (Stephen J. Turnbull) > Date: Mon, 25 Nov 2013 14:20:07 +0900 > > Eli Zaretskii writes: > > > 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. > > [I'm sorry, the word I wanted was "descent", not "depth". I don't > know if that helps, but it's more typographically precise.] > > Sure, but where does the data for that computation come from? It > comes from the font's metadata for the character (ascent [above > reference point], descent [below reference point], and offset [to next > glyph's reference point]. What can be done per character without > knowing *which* character is to set the descent to some value. Then > the line's descent is the maximum of all descents of characters on the > line, as modified by the text property. OK, but I still don't see what are you arguing. We already have in Emacs text properties that specify pixel-level alignment of a character, text properties that specify prefix generated out of thin air for each line, properties that display text in the margins instead in the text area, etc. etc. They are all considered by the display engine as it lays out the text. I see no reason why the same technology with only minor tweaks couldn't support specifications of indentation, justification, or even automatic paragraph numbering. If what you are saying is that this is hard in the general case because of complications with some scripts, then I bet Emacs doesn't support these scripts well anyway, so either we should add such support or continue living without it. It still doesn't mean we cannot have WYSIWYG WP capabilities that don't blow Office out of the water, but do allow decent word processing in, say, 90% of use cases. > Another way to look at this is "what happens if *two* intervals > completely contained in the same line have *different* line-separation > properties?" They cannot overlap in Emacs. If they are disjoint, then the result will be the maximum spacing specified by any one of them. > The point is that some properties should be specified per-character, > and others should be specified for higher level text units. For the > latter, using a text property that covers a certain interval of > characters that does not correspond to that unit is horrible because > it's going to confuse users. The UI should make that impossible. OK, but I don't see any problem with that. > > 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. > > Really? I've never seen that happen in any of Word, OpenOffice, or > LibreOffice. Happens to me and my colleagues every day. The longer the document and the more styles it uses, the higher the risk of hitting this. > > > 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. > > Of course if you edit *text*, either the content or by applying or > removing a style, there should be no prompt, and I didn't propose that > there be one. Did you notice that? Well, "edit section heading's style" is ambiguous. And if by that you meant edit the style, not the text that uses the style, then the question is still redundant, because it should be clear that I want all the headings using this style to change.