From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Emacs as word processor Date: Tue, 26 Nov 2013 12:36:49 -0800 (PST) Message-ID: <66915940-b5f3-47f2-9678-cb2311694e62@default> 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> <837gbwbcsx.fsf@gnu.org> <87d2lnevq7.fsf@uwakimon.sk.tsukuba.ac.jp> <0380eaf9-3d4b-4131-8fa9-444f1794ec96@default> <87k3fvrlew.fsf@informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1385498234 28942 80.91.229.3 (26 Nov 2013 20:37:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Nov 2013 20:37:14 +0000 (UTC) To: "Pascal J. Bourguignon" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 26 21:37:18 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 1VlPNl-0005LP-0q for ged-emacs-devel@m.gmane.org; Tue, 26 Nov 2013 21:37:17 +0100 Original-Received: from localhost ([::1]:60936 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlPNk-0007ny-Gm for ged-emacs-devel@m.gmane.org; Tue, 26 Nov 2013 15:37:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlPNZ-0007ns-Qa for emacs-devel@gnu.org; Tue, 26 Nov 2013 15:37:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlPNQ-0004xb-V4 for emacs-devel@gnu.org; Tue, 26 Nov 2013 15:37:05 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:39706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlPNQ-0004xX-O6 for emacs-devel@gnu.org; Tue, 26 Nov 2013 15:36:56 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAQKarH1003428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Nov 2013 20:36:54 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAQKanp8003123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Nov 2013 20:36:51 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAQKannL005569; Tue, 26 Nov 2013 20:36:49 GMT In-Reply-To: <87k3fvrlew.fsf@informatimago.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:165787 Archived-At: > Isn't it exactly just what we would want to avoid? No. As long as you have the possibility of properties (call them what you like) being attached to individual characters irrespective of any possible underlying structure, you want to make it easy to transfer and copy sets of such properties. Even in a structured application, the _possibility_ should be there. This is the case, for example, in Framemaker. You can use it for both structured applications and for unstructured ones. Even for use with a structured application, nothing _prevents_ you from applying ad hoc formatting in Framemaker. But of course users of such apps themselves avoid doing that. Neither I, nor any of my colleagues, for example, have _ever_ used ad hoc formatting with Framemaker for the documents we write, which are all structured (XML). There's an overriding, simple reason for that. Tools that create different kinds of output (HTML, help, PDF, for different devices etc.) work with the underlying structure (in a word, the XML data). They ignore any ad hoc formatting. So it does you no good to fiddle with bold or italic here and there, instead of, say, wrapping an element in a predefined Emphasis element that has a Role attribute set to value CodeInlineBold (or whatever). IOW, enforcement where and when appropriate, and according to strictly defined schemas. But nothing prevents you from ad hoc formatting, for those cases where there is no structured app. > Wouldn't we want to promote structured editing with style sheets, so > that instead of pasting faces, you'd rather change the structure of the > document, indicating , or
> and letting the word processor perform the style cascade and text > rendering? Yes, for a structured application. That is typically enforced by an XML Schema schema or a DTD or other validation tools, or at a minimum by good practice. Even then, the same UI principle applies. In Framemaker I can copy an XML element's attribute values and then paste them onto other elements. Depending on user preferences (strict or lax), doing that to the wrong kind of element (one that does not have the same attributes) will either be prevented or allowed. This is a useful and common UI tool. Whether you are copying a color (a la eyedropper) or other text attributes, the same idea applies. Kind of strange, IMO, that Emacs itself has not had such a simple UI tool. And yes, I do propose it as a start, for those of you who are thinking of moving Emacs toward being able to do more WYSIWYG editing. Copy faces, fonts, background color, whatever from here. Paste over there. Piece of cake - quick, useful. And that includes pasting the absence of certain properties, in order to remove them from the paste target. Emacs, above all editors and environments, should not hardcode any black-&-white behavior in this regard. It should, on the one hand, give users the tools to both (a) control editing rigorously, in a structured way, and (b) on the other hand, allow users to fly by the seat of their pants. This should be a no brainer for Emacs. Emacs was *the* counter model, back in the 80s & 90s when some were promoting locked-in, strict "structured editors" (often in Lisp, BTW, and often implemented using Emacs). The Emacs approach was to let you do pretty much anything, but to also provide feedback and validation wrt the desired structure. And if you wanted strict prevention, Emacs offered you that too. Guess which model "won". Au choix. User control. This is the Emacs way. Anything less is limiting.