From: Alan Mackenzie <acm@muc.de>
To: Kaushal Modi <kaushal.modi@gmail.com>
Cc: 23460@debbugs.gnu.org
Subject: bug#23460: 25.1.50; Strange behavior in local variables like start-comment
Date: Thu, 5 May 2016 22:22:11 +0000 [thread overview]
Message-ID: <20160505222211.GE1950@acm.fritz.box> (raw)
In-Reply-To: <CAFyQvY2GQKtPwpj=jgL=eLQNnLP5bOU7Mr_0vWfJAuQWGxu0WA@mail.gmail.com>
Hello, Kaushal.
On Thu, May 05, 2016 at 08:35:04PM +0000, Kaushal Modi wrote:
> It looks like after the recent commit (
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=25f455815bfaa868dc470d445413df9a7a546c46
> ),
> the buffer local variables like comment-start are behaving strangely. They
> commentarily go to a value of nil (or their default value?) and then back
> to the buffer local value in the current buffer.
Yes. I think this is intended, and wasn't changed by my recent patch.
> I discovered this issue as I am using outshine package and in one of the
> functions in there, a check is put to ensure that comment-start is not nil:
> https://github.com/tj64/outshine/blob/73ae2c2ea24001338dbeff5137f09bb5f784f12c/outshine.el#L1105-L1108
I haven't actually looked at that yet. But where, with respect to
setting the major mode, does the outshine function look at
comment-start?
> Surprisingly, my *Messages* buffer started showing the "Cannot calculate
> outcommented outline-regexp without 'comment-start' character defined!"
> message. But I was working in a shell-script-mode buffer and comment-start
> IS defined: "# ". I even verified doing C-h v comment-start that that
> actually was the case.
Were you doing anything involving changing the major mode at the time?
(See below.)
> I then realized that I saw that message each time I reverted the buffer (or
> looked like each time the buffer's major mode hook was called (and that's
> why I suspect commit 25f4558.. to be the problem; please correct if that's
> wrong). I do not see this bug in emacs-25 branch build.
> Here is a minimum working example to test this bug behavior in an emacs -Q
> session.
Thanks for taking the trouble to create this minimal test code. It
makes it so much easier to understand when people do this. :-)
> (progn
> (defun my/print-comment-start-value ()
> (interactive)
> (let ((filler (if (null comment-start)
> "is undefined, it's value is:"
> "=")))
> (message (format "`comment-start' %s `%s'" filler comment-start))))
> (global-set-key (kbd "<f5>") (lambda () (interactive) (revert-buffer
> nil :noconfirm)))
> (global-set-key (kbd "<f6>") #'my/print-comment-start-value)
> (add-hook 'change-major-mode-hook #'my/print-comment-start-value))
> (1) Evaluate the above in emacs -Q
> (2) You would be in *scratch* buffer and that's alright
> (3) Hit F5 couple of times and you should see
> ‘comment-start’ is undefined, it’s value is: ‘nil’
> (4) Now hit F6 (which just prints the value of comment-start variable) and
> you will see
> ‘comment-start’ = ‘;’
> (5) Isn't that strange?!
OK. Have a look at the *Messages* buffer. You will see the messages
come in pairs: (I actually did this in a C Mode buffer.)
`comment-start' = `/* '
`comment-start' is undefined, it's value is: `nil'
But in the echo area, you will only see the second one.
> I have tested this only for comment-start. But I suspect this might affect
> buffer local vars in general?
I think so, too. When you visit a buffer, Emacs calls `normal-mode' to
determine and set the major mode. The first thing `normal-mode' does is
to call `fundamental-mode'. This invokes `change-major-mode-hook',
which outputs the first "comment-start" message. Then
`fundamental-mode' kills all local variables, including `comment-start'.
`normal-mode' then determines the correct major mode, and calls it.
This invokes `change-major-mode-hook' again, which outputs the second
"comment-start" message with the `nil'. The major mode is then fully
set up, including giving a value to `comment-start'.
So, this code seems to be working the way it's intended to. What is
outshine doing that triggers a problem in this area? Is it doing things
with the `change-major-mode-hook' that involve using `comment-start'?
Maybe this is the problem.
> In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
> of 2016-05-05 built on ...
> Repository revision: 67fa7f13d499eb5fc1d697da6c636b20728da22f
> Windowing system distributor 'The X.Org Foundation', version 11.0.60900000
> System Description: Red Hat Enterprise Linux Workstation release 6.6
> (Santiago)
[ .... ]
> Recent messages:
> ‘comment-start’ is undefined, it’s value is: ‘nil’
> ‘comment-start’ = ‘;’
> ‘comment-start’ is undefined, it’s value is: ‘nil’
> ‘comment-start’ = ‘;’
> ‘comment-start’ is undefined, it’s value is: ‘nil’
> ‘comment-start’ = ‘;’ [2 times]
> ‘comment-start’ is undefined, it’s value is: ‘nil’
> ‘comment-start’ = ‘;’ [4 times]
> ‘comment-start’ is undefined, it’s value is: ‘nil’
> Mark set [2 times]
> --
> Kaushal Modi
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2016-05-05 22:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 20:35 bug#23460: 25.1.50; Strange behavior in local variables like start-comment Kaushal Modi
2016-05-05 21:40 ` Kaushal Modi
2016-05-05 22:20 ` Kaushal Modi
2016-05-06 9:37 ` Alan Mackenzie
2016-05-06 14:31 ` Kaushal Modi
2016-05-05 22:22 ` Alan Mackenzie [this message]
2016-05-05 22:35 ` Kaushal Modi
2016-05-05 22:29 ` Michael Heerdegen
2016-05-06 19:25 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160505222211.GE1950@acm.fritz.box \
--to=acm@muc.de \
--cc=23460@debbugs.gnu.org \
--cc=kaushal.modi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).