From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Removing rollback from VC mode - request for comment Date: Sat, 13 Dec 2014 08:59:29 -0500 Message-ID: References: <20141211092138.6D5F6C008E@snark.thyrsus.com> <87y4qcj2mq.fsf@mat.ucm.es> <87mw6sdetf.fsf@fencepost.gnu.org> <87tx10iya1.fsf@mat.ucm.es> <87iohgdarf.fsf@fencepost.gnu.org> <87wq5wa8s7.fsf@mat.ucm.es> <87tx0zsxq5.fsf@mat.ucm.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1418479209 22520 80.91.229.3 (13 Dec 2014 14:00:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Dec 2014 14:00:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 13 15:00:02 2014 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 1XznEm-0003l0-Bw for ged-emacs-devel@m.gmane.org; Sat, 13 Dec 2014 15:00:00 +0100 Original-Received: from localhost ([::1]:33097 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XznEl-0001Wk-Jz for ged-emacs-devel@m.gmane.org; Sat, 13 Dec 2014 08:59:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XznES-0001WM-BM for emacs-devel@gnu.org; Sat, 13 Dec 2014 08:59:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XznEJ-0005ul-5r for emacs-devel@gnu.org; Sat, 13 Dec 2014 08:59:40 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:53645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XznEJ-0005uh-2b for emacs-devel@gnu.org; Sat, 13 Dec 2014 08:59:31 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkPAOwQflTO+ILA/2dsb2JhbABbgweDYFCFCsUdBAICgSQXAQEBAQEBfIQDAQEDASMzKAsLGgIYDgICFBgNiG4JwAaWUyyBK49LFoJfgVMFiwGDYaBNgXiEGSGCdwEBAQ X-IPAS-Result: AmkPAOwQflTO+ILA/2dsb2JhbABbgweDYFCFCsUdBAICgSQXAQEBAQEBfIQDAQEDASMzKAsLGgIYDgICFBgNiG4JwAaWUyyBK49LFoJfgVMFiwGDYaBNgXiEGSGCdwEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="100584568" Original-Received: from 206-248-130-192.dsl.teksavvy.com (HELO pastel.home) ([206.248.130.192]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2014 08:59:30 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id E90611F47; Sat, 13 Dec 2014 08:59:29 -0500 (EST) In-Reply-To: <87tx0zsxq5.fsf@mat.ucm.es> (Uwe Brauer's message of "Sat, 13 Dec 2014 10:30:42 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:179998 Archived-At: > Do you mean \usepackage[utf8]{inputenc} Yes. >> actual accented chars in the file). Are you referring to the replacement >> of "\alpha" with an "=CE=B1" and things like that? > Do you mean (set-input-method "TeX")?=20 No, I mean the thing that visually replaces \alpha with an actual =CE=B1 character (and converts it back when you save). > Last time I looked into that, my impression was this functionality > included less symbols than x-symbols. This should be fixable. > Besides sub and super indices were not supported.[1] Not sure what you mean by that. >> These could be added via prettify-symbols-mode (which, like >> preview-latex relies on redisplay features rather than modifying the >> actual buffer's content). > I am curious to see whether that would have performance issues on big > files No, performance should be unaffected by file-size: only the visible part of the buffer is considered (it's done via jit-lock) and the display is modified by "character composition text-properties", which have good algorithmic properties. Stefan