unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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).





  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).