From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.help Subject: Re: Handling large files with Emacs Date: Wed, 24 Oct 2012 14:52:07 +0530 Message-ID: <876260cji8.fsf@gmail.com> References: <87k3uhf0gc.fsf@panzer.v.cablecom.net> <87a9vdeyrf.fsf@panzer.v.cablecom.net> <83objsc47x.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1351070443 22080 80.91.229.3 (24 Oct 2012 09:20:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2012 09:20:43 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Tom Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Oct 24 11:20:49 2012 Return-path: Envelope-to: geh-help-gnu-emacs@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 1TQx8r-00056T-8d for geh-help-gnu-emacs@m.gmane.org; Wed, 24 Oct 2012 11:20:49 +0200 Original-Received: from localhost ([::1]:49318 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQx8j-0001Zh-Kd for geh-help-gnu-emacs@m.gmane.org; Wed, 24 Oct 2012 05:20:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQx8W-0001Z2-Im for help-gnu-emacs@gnu.org; Wed, 24 Oct 2012 05:20:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TQx8M-0005yJ-Tg for help-gnu-emacs@gnu.org; Wed, 24 Oct 2012 05:20:28 -0400 Original-Received: from mail-pa0-f41.google.com ([209.85.220.41]:33839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQx8M-0005y9-ND for help-gnu-emacs@gnu.org; Wed, 24 Oct 2012 05:20:18 -0400 Original-Received: by mail-pa0-f41.google.com with SMTP id fa10so253152pad.0 for ; Wed, 24 Oct 2012 02:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=7N/iCIpylGTFr6Le+oxSnk8uscUzHjwOhEUC1akKuVc=; b=H5eBygXp2KQgaM3GIPJKbL8uh2F0a0/IRLBY8zWO9CcKU4dNRiQzCy19Gk0T+BT8GU CrPb6sACC4aEtLaK+omGdjwJ4kWE7RhGHWHL2x9dltwuTa/07yHTHDaQw3F02a91NVXJ GAyXX5gQNOxf4KumuaPMjU9hODM4b+xODdBgEnJ7IHXJ9e341PJ4vtPAaegfc22rmlQ9 WNeSrjYaKWYcGyoKbqlY22ung7JEOA1mnxZJ81EVqIX04wASSMS4aPg3bMVoLS28oxJI JvQhlJKK5bK49xGGRXja+aBv1oz/AOh3duv8uMCKroTfYxuE4iGKWjzl6HwkROh/+r96 ukdQ== Original-Received: by 10.66.75.165 with SMTP id d5mr42484345paw.39.1351070417957; Wed, 24 Oct 2012 02:20:17 -0700 (PDT) Original-Received: from debian-6.05 ([101.63.187.189]) by mx.google.com with ESMTPS id gl9sm9173818pbc.51.2012.10.24.02.20.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 02:20:16 -0700 (PDT) In-Reply-To: (Tom's message of "Wed, 24 Oct 2012 07:52:58 +0000 (UTC)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.220.41 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:87389 Archived-At: Tom writes: > Eli Zaretskii gnu.org> writes: > >> >> That's ridiculously small. I routinely edit files approaching 500MB >> without any problems, and that's on a 32-bit machine, whereas yours is >> a 64-bit one. So something is seriously wrong with your system, or >> maybe with the Emacs binary (but I can hardly believe it). >> >> > > I think it's because syntax highlight or something. When I try opening > SQL dumps (say, 200MB) then Emacs grinds to a halt for a minute or > so, and moving in the file is very slow even after that. Have you experimented with `font-lock-maximum-size' together with `font-lock-support-mode'? ,----[ C-h v font-lock-maximum-size RET ] | font-lock-maximum-size is a variable defined in `font-lock.el'. | Its value is 256000 | | This variable is obsolete since 24.1. | | Documentation: | Maximum buffer size for unsupported buffer fontification. | When `font-lock-support-mode' is nil, only buffers smaller than | this are fontified. This variable has no effect if a Font Lock | support mode (usually `jit-lock-mode') is enabled. | | If nil, means size is irrelevant. | If a list, each element should be a cons pair of the form (MAJOR-MODE . SIZE), | where MAJOR-MODE is a symbol or t (meaning the default). For example: | ((c-mode . 256000) (c++-mode . 256000) (rmail-mode . 1048576)) | means that the maximum size is 250K for buffers in C or C++ modes, one megabyte | for buffers in Rmail mode, and size is irrelevant otherwise. | | You can customize this variable. | | [back] `---- > > If I don't use an .sql extension, so that the file is not opened > in SQL mode then it's much better. So opening big files in fundamental > mode works well, but if it has its own mode with syntax highlighting > then it's pretty much unusable. > > I think Fab has a similar problem, because he opens the big file > in Bibtex mode which also does it's own stuff, parsing the buffer > with regexps for syntax highlighting, or something like this. > > > --