From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: enriched-mode and switching major modes. Date: Mon, 20 Sep 2004 09:24:16 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <87llfn5ihw.fsf@emacswiki.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1095686704 30371 80.91.229.6 (20 Sep 2004 13:25:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Sep 2004 13:25:04 +0000 (UTC) Cc: bob@rattlesnake.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 20 15:24:49 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C9O9x-0001ii-00 for ; Mon, 20 Sep 2004 15:24:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9OFp-0001PG-Mo for ged-emacs-devel@m.gmane.org; Mon, 20 Sep 2004 09:30:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C9OFg-0001Of-A0 for emacs-devel@gnu.org; Mon, 20 Sep 2004 09:30:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C9OFe-0001O2-W8 for emacs-devel@gnu.org; Mon, 20 Sep 2004 09:30:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9OFe-0001Ns-Rx for emacs-devel@gnu.org; Mon, 20 Sep 2004 09:30:42 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C9O9e-00010K-6n for emacs-devel@gnu.org; Mon, 20 Sep 2004 09:24:30 -0400 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 269E6B30280; Mon, 20 Sep 2004 09:24:17 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 895B88CA23; Mon, 20 Sep 2004 09:24:16 -0400 (EDT) Original-To: Oliver Scholz In-Reply-To: (Oliver Scholz's message of "Mon, 20 Sep 2004 13:00:08 +0200") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 5) X-MailScanner-From: monnier@iro.umontreal.ca X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 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 Xref: main.gmane.org gmane.emacs.devel:27325 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27325 > I don't talk about WYSIWYG. I abhor the very concept of it in the > context of word processing. "WYSIWYG" means to say something about > the relationship between the rendering of the document on screen and > on printed paper. My understanding of WYSIWYG is not really that "the printer version is equal to the screen version" (after all, TeX gets that: the xdvi rendering is the same as the printer's). Instead, the underlying idea is that there is no "deep representation", or at least that you can at most manipulate it implicitly. > We can't have that in Emacs. It would mean that if Emacs is started > on, say the linux tty, we would have to print the document in light > gray on black in a font which looks like the linux console font. It > would mean that the printed output would look different when I start > Emacs on a character console, a terminal emulator or on the GUI. No: most WYSIWYG word-processors will happily accept (and print) colors in your document, even when your screen is black&white. I.e. the way it typically works is that there *is* a deep representation but it can only be manipulated implicitly through the superficial representation which is displayed with "the best possible rendering on the current output device". >> the deep representation (which, AFAIC, is not "just the disk format" >> but is the format where I can expresss my *intents*, i.e. where I >> can distinguish between two concepts even if they happen to be >> rendered identically on the currently used output mode) > [...] > Yes, that's a different editing model. I guess I still don't understand the model you're thinking of, which doesn't involve an explicit deep representation and yet isn't WYSIWYG either. Stefan