From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.help Subject: Re: Hook doesn't run as expected, if buffer mode is set from major-mode Date: Sun, 10 Jan 2016 05:29:32 +0100 Message-ID: <87oacuys43.fsf@web.de> References: <87h9in4zee.fsf@linux-qg7d.fritz.box> <8760z34mhj.fsf@linux-qg7d.fritz.box> <87io32qu2u.fsf@point.pointsman.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1452400204 31002 80.91.229.3 (10 Jan 2016 04:30:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 04:30:04 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Jan 10 05:29:55 2016 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 1aI7db-0005YW-IM for geh-help-gnu-emacs@m.gmane.org; Sun, 10 Jan 2016 05:29:55 +0100 Original-Received: from localhost ([::1]:45211 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aI7da-0000Rw-MS for geh-help-gnu-emacs@m.gmane.org; Sat, 09 Jan 2016 23:29:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aI7dQ-0000Ro-IH for help-gnu-emacs@gnu.org; Sat, 09 Jan 2016 23:29:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aI7dN-0001IC-BV for help-gnu-emacs@gnu.org; Sat, 09 Jan 2016 23:29:44 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:39106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aI7dN-0001I6-4D for help-gnu-emacs@gnu.org; Sat, 09 Jan 2016 23:29:41 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aI7dK-0005M6-Iz for help-gnu-emacs@gnu.org; Sun, 10 Jan 2016 05:29:38 +0100 Original-Received: from dslb-094-217-126-232.094.217.pools.vodafone-ip.de ([94.217.126.232]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jan 2016 05:29:38 +0100 Original-Received: from michael_heerdegen by dslb-094-217-126-232.094.217.pools.vodafone-ip.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jan 2016 05:29:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 73 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dslb-094-217-126-232.094.217.pools.vodafone-ip.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:I9iUgxA96omErzCubBwOrGezpmw= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:108683 Archived-At: Rolf Ade writes: > >> But this documentation doesn't tell the truth. > > > > Or we all misunderstand it. In both cases, a bug report could be > > appropriate. > > Unfortunately I feel a bit uncomfortable to express myself in English; > I'm afraid I can't make my point clear enough. I think I already perfectly understood (with "we all misunderstand it" I meant the docs, not what you said - but I guess the doc is just outdated). > At the moment, I see two different, although related topics: > > 1) The (for my eyes) much more important fact is, that you may have two > files with identical content and which only differ in file name > suffix. Depending on your default major mode, your auto-mode-alist and > the mode hooks of your default major mode it is possible, that you open > the one of that file and then the other - and the two buffers have the > same major mode but are in a different state. > > Or, to put it in other words: The effect (or the result or whatever the > appropriate word would be) of the mode hooks of your default major mode > depends not only on the elisp code of that hooks and the content of the > buffer, but - at least for me a bit surpising or unexpected - also on > the question if a new opened buffer get its major mode by a match in > auto-mode-alist or by default major mode. > > 2) The other, somewhat minor topic is the documentation of > `major-mode'. It suggests (although somewhat vague) that a new buffer > switches to the default mode (and run the mode hooks) in such an eary > state, that the contents aren't already read into the buffer (and > therefor, the hook code can't work on the content or have the content to > look at). This seems not to be true (at least not completely), from what > I see. Some mystery things happen, so that, at the end, it looks like it > would be so, as the documentation say, but it isn't true. Yes. Though for 1), we only have a one special case, so it can be coincidental that some weird bug in C breaks 1). > Are this two different bug reports? I think so. They can be merged later, if they appear to be related. But you can add a note like "also see related #nnnnn" or so. > And, out of curiosity, why are the things, as they seem to be? Why isn't > the process of opening a file just (schematic): > > - Buffer is created > > - Bile content is read into the buffer > > - The major mode of the new buffer is searched by looking at > auto-mode-alist, interpreter-mode-alist and magic-mode-alist (and what > not else). > > - If a major mode is found, in the step above, the buffers local > variable major-mode is set to this and the mode hooks do run. > > - If no applicable mode was found, above, the mode of the new buffer is > the default mode and the hooks if that mode run. I think that's the case now, more or less. As I said, I didn't find an explanation for the behavior you get in the Lisp sources. There could be a problem on a lower level, and what you see was never intended. Regards, Michael.