From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.bugs Subject: bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch Date: Wed, 01 May 2013 18:26:25 +0200 Organization: Linux Private Site Message-ID: <87ip32oedq.fsf@Rainer.invalid> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1367425662 26081 80.91.229.3 (1 May 2013 16:27:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 May 2013 16:27:42 +0000 (UTC) To: 14325@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 01 18:27:40 2013 Return-path: Envelope-to: geb-bug-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 1UXZsa-0004j3-Br for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 May 2013 18:27:40 +0200 Original-Received: from localhost ([::1]:42753 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXZsZ-0003vY-Vq for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 May 2013 12:27:39 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXZsW-0003vN-Iw for bug-gnu-emacs@gnu.org; Wed, 01 May 2013 12:27:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXZsV-0005xW-6c for bug-gnu-emacs@gnu.org; Wed, 01 May 2013 12:27:36 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXZsT-0005x9-2k; Wed, 01 May 2013 12:27:33 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UXZsw-0000oI-89; Wed, 01 May 2013 12:28:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <878v3z29r2.fsf@Rainer.invalid> Resent-From: Achim Gratz Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 01 May 2013 16:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14325 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.13674256403005 (code B ref -1); Wed, 01 May 2013 16:28:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 1 May 2013 16:27:20 +0000 Original-Received: from localhost ([127.0.0.1]:54103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UXZsF-0000mP-It for submit@debbugs.gnu.org; Wed, 01 May 2013 12:27:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35271) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UXZsB-0000mB-EF for submit@debbugs.gnu.org; Wed, 01 May 2013 12:27:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXZrg-0005k0-DZ for submit@debbugs.gnu.org; Wed, 01 May 2013 12:26:45 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:51659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXZrg-0005jw-Av for submit@debbugs.gnu.org; Wed, 01 May 2013 12:26:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXZre-0003Vz-Oy for bug-gnu-emacs@gnu.org; Wed, 01 May 2013 12:26:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXZrd-0005jU-9Y for bug-gnu-emacs@gnu.org; Wed, 01 May 2013 12:26:42 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:46452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXZrd-0005jI-2X for bug-gnu-emacs@gnu.org; Wed, 01 May 2013 12:26:41 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UXZra-0003ma-GF for bug-gnu-emacs@gnu.org; Wed, 01 May 2013 18:26:38 +0200 Original-Received: from pd9eb25d4.dip0.t-ipconnect.de ([217.235.37.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 May 2013 18:26:38 +0200 Original-Received: from Stromeko by pd9eb25d4.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 May 2013 18:26:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd9eb25d4.dip0.t-ipconnect.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:/5FxTfkhmFlkbm/xK1G4ZP/k09M= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:73870 Archived-At: Alan Mackenzie writes: > Yes, the c-after-font-lock-init call will initialise everything properly, > though it's more a workaround than a solution. So what would be the solution, then? > Font Lock Mode is a minor mode, and part of its initialisation is calling > font-lock-mode-hook. (font-lock-mode-hook is here c-after-font-lock-init.) > If you run font-lock-fontify-buffer (etc.) without fully initialising Font > Lock Mode, you're liable to run into bugs. If that were all there were > to it, I'd have nothing more to say, but sadly it's not so simple. Well, Org requires font-lock, it switches font-lock off and on when it changes font-lock settings and it uses it for fontification with whatever major mode the content wants to have. If there is a code-path that enters cc-mode in uninitialized state, then shouldn't cc-mode check for nil instead of crashing Emacs by blindly assuming it can funcall the contents of that variable? > Font Lock Mode is, by default disabled in batch mode. If you enable it, > this also enables jit-lock-mode (which is surely wrong), which prevents > any fontification actually taking place, since the buffer is never > displayed on the screen to trigger the fontification. Since Org can use the results of the fontification, some of it must happen anyway? Besides, even if I stop jit-lock-mode from being used (by adding it to font-lock-inhibit-thing-lock), cc-mode still throws an error. > I think the following sequence of commands would fontify the buffer > properly in batch mode: > (c-mode) > (setq font-lock-support-mode nil) ; disable jit-lock-mode > (font-lock-mode 1) I've tried to put these (without switching to c-mode since selecting the mode is done elsewhere) into various places and still get the same error from cc-mode. > However, you'll probably prefer to carry on with using Font Lock Mode > uninitialised. ;-) I think Glenn's patch achieves this painlessly. I'd prefer if fontlock-fontify-* would work in batch mode without workarounds. I'll have no problem sticking (when noninteractive ...) into the intialization or Org itself if that's the ticket. I still don't have a clue where that should be done. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds