From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: display word wrapping Date: Tue, 08 Jun 2004 10:14:00 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040608095945.966D.JMBARRANQUERO@wke.es> References: <20040608013702.085E.LEKTU@mi.madritel.es> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1086682479 24650 80.91.224.253 (8 Jun 2004 08:14:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Jun 2004 08:14:39 +0000 (UTC) Cc: emacs-devel@gnu.org, "Kim F. Storm" Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jun 08 10:14:28 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BXbka-0002WF-00 for ; Tue, 08 Jun 2004 10:14:28 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BXbkZ-0001df-00 for ; Tue, 08 Jun 2004 10:14:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BXbl9-0000cT-Ka for emacs-devel@quimby.gnus.org; Tue, 08 Jun 2004 04:15:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BXbl6-0000cE-PK for emacs-devel@gnu.org; Tue, 08 Jun 2004 04:15:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BXbl5-0000c0-6r for emacs-devel@gnu.org; Tue, 08 Jun 2004 04:15:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BXbl4-0000bx-Vw for emacs-devel@gnu.org; Tue, 08 Jun 2004 04:14:59 -0400 Original-Received: from [62.22.181.117] (helo=idefix.laley.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BXbk9-0005RZ-D3; Tue, 08 Jun 2004 04:14:01 -0400 Original-Received: from [172.17.221.23] (JMBARRANQUERO [172.17.221.23]) by idefix.laley.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LSNJ6PJY; Tue, 8 Jun 2004 10:13:23 +0200 Original-To: David Kastrup In-Reply-To: X-Mailer: Becky! ver. 2.08.01 [en] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:24701 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24701 On 08 Jun 2004 08:38:00 +0200 David Kastrup wrote: > If an image type is known, I hope that it is present as just its > name, and _not_ as a cons cell (jpeg . t) or so. > > If not, we have a major incompatibility to the previous behavior. It > is bad enough already what happens if somebody decides to cycle > through that variable just to display supported image types. Yes, in my patch, image-types is an alist with (symbol . flag) items, instead of a list of symbols. It was suggested making it so on this thread a few messages ago. I'm not going to make a strong point on this; whatever is decided, I'll implement. However... - Kim *almost* suggested getting rid of image-types altogether, because image-types is an implementation detail. - No single .el, .c or .h file from the distribution uses image-types (other than image.c, and xdisp.c in which it is defined). - A Google search of "image-types" on gnu.emacs.* shows just one or two modules using image-types, in no particularly robust ways. - On delayed-loading environments (which could potentially be all, as delaying loading the libraries seems generally useful), image-types, even if a list as it was till now, can not be trusted to list supported image types, just supported types *already loaded*. - Delayed loading and image-types as it was till now, with the exact same semantics, are basically incompatible. We could make: (defconst image-types '(jpeg tiff gif png postscript xpm pbm xbm)) and use another variable as loaded-flags alist, but it's difficult to know what purpuse would it serve such image-types. On Windows that wouldn't guarantee in any way that you can use png (for example), as libpng*.dll could be missing (that's the whole point of delayed loding). - You can easily fake an old style image-types with: (defvar my-image-types (let (result) (dolist (type '(xbm pbm xpm jpeg tiff gif png postcript) result) (when (image-type-available-p type) (push type result)))) "Old style image-type.") and totally defeat delayed-loading. > Can't we just keep the variable with the original meaning, and store > the lookup cache data somewhere else? We can keep the variable with a somewhat-similar meaning, but no with the original one (unless we discard delayed-loading). Juanma