From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Improvements to `(emacs)File Variables' Date: Sun, 14 Nov 2004 18:55:58 -0500 Message-ID: <20041114235558.GA18975@fencepost> References: <878y942l8h.fsf-monnier+emacs@gnu.org> <20041114232600.GA12968@fencepost> <87r7mw0zik.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1100476899 31273 80.91.229.6 (15 Nov 2004 00:01:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 Nov 2004 00:01:39 +0000 (UTC) Cc: emacs-devel@gnu.org, Simon Krahnke , Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 15 01:01:32 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 1CTUJI-0007GG-00 for ; Mon, 15 Nov 2004 01:01:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CTURx-0002Vx-Rb for ged-emacs-devel@m.gmane.org; Sun, 14 Nov 2004 19:10:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CTUNV-0000s3-VH for emacs-devel@gnu.org; Sun, 14 Nov 2004 19:05:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CTUNU-0000qZ-L5 for emacs-devel@gnu.org; Sun, 14 Nov 2004 19:05:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CTUNU-0000qK-Cl for emacs-devel@gnu.org; Sun, 14 Nov 2004 19:05:52 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CTUEn-0003Pu-J2 for emacs-devel@gnu.org; Sun, 14 Nov 2004 18:56:53 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.34) id 1CTUDu-0005PT-22; Sun, 14 Nov 2004 18:55:58 -0500 Original-To: Stefan Monnier Content-Disposition: inline In-Reply-To: <87r7mw0zik.fsf-monnier+emacs@gnu.org> User-Agent: Mutt/1.3.28i Blat: Foop 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29848 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29848 On Sun, Nov 14, 2004 at 06:46:59PM -0500, Stefan Monnier wrote: > > I think we should make the whole _concept_ of "unibyte" deprecated... > > At the user-level, yes that was pretty much my understanding as well, which > is why the unibyte:t marker should be considered obsolete. > > At the elisp level, unibyte strings and buffers are still very handy > to manipulate undecoded data (such as when talking to an NNTP server). > I don't see any reason why this should ever be deprecated. I think the lisp/C level are a complete mess also, but it's probably too painful and too much work to fix it. -Miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.'