From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs as word processor Date: Tue, 26 Nov 2013 11:35:12 +0900 Message-ID: <87d2lnevq7.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1385433350 10404 80.91.229.3 (26 Nov 2013 02:35:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Nov 2013 02:35:50 +0000 (UTC) Cc: ttn@gnuvola.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 26 03:35:55 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 1Vl8VE-0003f7-IC for ged-emacs-devel@m.gmane.org; Tue, 26 Nov 2013 03:35:52 +0100 Original-Received: from localhost ([::1]:56029 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl8VD-0002uX-Va for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2013 21:35:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl8V3-0002ta-Vw for emacs-devel@gnu.org; Mon, 25 Nov 2013 21:35:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vl8Uw-0008Kk-Cv for emacs-devel@gnu.org; Mon, 25 Nov 2013 21:35:41 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:40592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl8Un-0008H6-VQ; Mon, 25 Nov 2013 21:35:26 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 619E9970A24; Tue, 26 Nov 2013 11:35:12 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 561A01A5193; Tue, 26 Nov 2013 11:35:12 +0900 (JST) In-Reply-To: <837gbwbcsx.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 182d01410b8d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:165734 Archived-At: Eli Zaretskii writes: > 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, That's reasonable. > 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. Of course it *can*. But these all make me gag (one of the famous "technical differences" -- they're implemented as extents in XEmacs, often zero-length extents for paragraph-level things and line-level things like marginal annotations). I don't suppose whether my stomach is doing flip-flops matters to emacs-devel, of course. :-) For example, normally text properties are carried with the text if cut/copied. That sucks for paragraph-level things. If it's a document-level style, there's no need, it will be in effect at the target point, too. If you're moving the text between documents, it's reasonably likely you *don't* want that stuff at the target point. N.B. This is the behavior of Excel that I hate most: it defaults to carrying cell formatting with the contents when pasting -- I almost *never* want that, and there's no way I know of to change the default paste style in any *Office spreadsheet. Of course you can write code that discards those properties, but really, that's not what you want. Some properties should never be copied (and for the exceptions, it's not that burdensome to query and reapply those properties). That should be an attribute of the property itself, not the code that copies or moves text. > If what you are saying is that this is hard in the general case > because of complications with some scripts, No, I'm saying getting this stuff right depends on either the user doing the right thing, or Emacs doing a lot of guessing as to what the user meant. IMO, this is going to make it hard to support WYSIWYG well enough to attract new users. (I guess that is not your reason for taking an interest in this thread, but several people, including RMS repeatedly, have mentioned it.) For example: > > 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. Which is not necessarily what the user wants. When I specify something like that in TeX, I almost always want the *minimum* because it looks better. YMMV, but it proves the point that users want different things. > > Really? I've never seen [the whole document change based on > > changing local indentation etc] 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. OK, I guess I'm just fortunate to have an environment where I don't have to use WYSIWYG crap very often on documents longer than two pages. (I also suspect that most of those documents are composed by people who don't grok styles, so there's not very much to go wrong.) > 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. Maybe that's true of *you*. It's definitely not true for me -- I rarely change pre-defined styles of document components *except* for exceptional cases. The point of "software for the rest of us" (and Emacs, for that matter) is to accomodate as many possible "clear wants" that *differ* from person to person as possible. But software for the rest of us and Emacs have very different philosophies. SFTROU puts the options in your face on the assumption that you're too busy (or otherwise incapacitated ;-) to read a manual. Emacs assumes that you know how to efficiently discover how to invoke behavior you want, and maybe even create it if it doesn't exist already.[1] If you want a certain amount of WYSIWYG in a form that is very compatible with traditional Emacs philosophy, I think that's very do-able, with a reasonable amount of effort (none of which am I going to supply, though, not even to port it to XEmacs -- I really don't think it's worth it, better to teach people to AUCTeX and preview). But if you (FVO of you = "any of the folks who have participated in this thread") want something that will attract new users to the Emacs fold, that is going to be a *ton* of drudgery. On the level of "friends don't let friends drink and drive." Trying to "make Emacs a plausible alternative to *Office for non-Emacs users" is the kind of self-destructive behavior I hope my friends will avoid. :-) Footnotes: [1] Writing code is by no means a *requirement* for using Emacs, and Emacs doesn't assume that just because you're smart enough to do so that you will. It does pay you the respect of assuming you're smart. :-)