From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: Emacs as word processor Date: Mon, 25 Nov 2013 10:06:22 +0700 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1385348785 4899 80.91.229.3 (25 Nov 2013 03:06:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Nov 2013 03:06:25 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 25 04:06:30 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 1VkmVJ-00046S-3c for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2013 04:06:29 +0100 Original-Received: from localhost ([::1]:49372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkmVI-000182-BI for ged-emacs-devel@m.gmane.org; Sun, 24 Nov 2013 22:06:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkmVE-00017s-EQ for emacs-devel@gnu.org; Sun, 24 Nov 2013 22:06:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VkmVD-0004Zv-ER for emacs-devel@gnu.org; Sun, 24 Nov 2013 22:06:24 -0500 Original-Received: from mail-qe0-x22c.google.com ([2607:f8b0:400d:c02::22c]:40155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkmVD-0004Zr-Ak for emacs-devel@gnu.org; Sun, 24 Nov 2013 22:06:23 -0500 Original-Received: by mail-qe0-f44.google.com with SMTP id nd7so2667222qeb.17 for ; Sun, 24 Nov 2013 19:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=wmSoul0thwJM5SEIyr30nWmRAbPBszR5BnE5yC80tUY=; b=ZV85patUSpF63AoFZvVCMroPOHM3cpuZN3cRbKaLce6RJG8rq99W7F2lRkBmPn3kcB 8L4M0UGxtjOSdgc6zePflpaJb9PDT/C1LF5vvSOKlXAQ1e9MCWooKAifCykixSeP1RYY 9Qb5c8hJCwbbFJEu0ElR8Hcbq491mTA982gm54WRxt95d3+BqF+hD/QpQTXvoxCduGyF nahYsBVW9GaHzlQ0P8FUBrJAPCFuZZvzyTaPut9adyg5GUFfAV3GepBEu3JpFm/EQ2VX /JtsfAXMYOMCeqHQA8YQ1QMMODMo+xSC44cfQxVnd8sn/B5xNvzyhfmgxWzbqfvHEEsq jG/Q== X-Received: by 10.49.97.6 with SMTP id dw6mr41675266qeb.47.1385348782769; Sun, 24 Nov 2013 19:06:22 -0800 (PST) Original-Received: by 10.96.179.36 with HTTP; Sun, 24 Nov 2013 19:06:22 -0800 (PST) In-Reply-To: <87txf133yd.fsf@zigzag.favinet> X-Google-Sender-Auth: zyeN74HL0UJCOaXtTK6wuhCe5zM X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c02::22c 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:165674 Archived-At: On Mon, Nov 25, 2013 at 4:06 AM, Thien-Thi Nguyen wrote: > If "faces" (the concept) were to include these extra-character features, > then their composition would be greatly complicated. Too, application > (i'm imagining the case of yanking text w/ a =E2=80=98face=E2=80=99 text-= property that > controls, say, pre-paragraph line-spacing into the middle of other text, > which has conflicting specs, or a context where "paragraph" does not > even have meaning). In *Office, styles are subdivided into =E2=80=9Ccharacter styles=E2=80=9D a= nd =E2=80=9Cparagraph styles=E2=80=9D (and, more recently, =E2=80=9Clist style= s=E2=80=9D and =E2=80=9Ctable styles=E2=80=9D). Text that is cut or copied out of the middle of a paragra= ph does not carry paragraph styles with it. Thus, pasted into a paragraph with different spacing, it assumes the spacing of the target paragraph (as spacing is a paragraph style feature). On the other hand, a whole paragraph, when cut, carries all its paragraph styles, and all its content carries its character styles. Additionally, if text is not explicitly formatted with character styles or character-level direct formatting, it behaves as plain text when cut, assuming the character styles of the paste target. Also, text can be explicitly marked as e.g. italic but otherwise have no font-related formatting. Thus, it will inherit other properties from the context: if pasted into a body paragraph whose base font is black normal straight Times New Roman 10pt, it becomes black normal italic Times New Roman 10pt; but pasted into a heading whose base font is blue bold straight Arial 16pt, becomes blue bold italic Arial 16pt. This is in fact very similar to Emacs=E2=80=99 face composition mechanism where many faces may be applied simultaneously, with some properties of some faces being undefined. Now, problems arise when characters *do* have explicit character-level formatting that is visually indistinguishable from the base paragraph font. Such text *will* carry the font with it when copied and pasted, giving the user the feeling of unpredictability and not being in control. Another frequent problem with WYSIWYG formatted text editors is pasting text copied from a different application, such as a web browser or a different word processor. It is then common to retain as much formatting as is available in the source document, which is rarely what the user expects.