`comment-start' is nil

`comment-start' is nil

[lee]

Hi,

I´m using desktop-mode to restore the previous session when starting
emacs.  For some buffers that are restored this way, I´m using a mode
I´m working on.  This mode employs a function to search for a regex in
particular buffers.  The regex involves `comment-start'.

Unfortunately, at the time the function is running during start-up, the
value of `comment-start' is nil.


    (let ((end-marker (concat "^" comment-start lsl-hi-lock-patterns-end-marker)))
        (message "comment-start with %s is %s"
	   (buffer-name)
	   comment-start) ...)


gives me messages like "comment-start with test-plane.fontify is nil".
Calling the same function later works fine because `comment-start' isn´t
nil anymore.

Is it supposed to be like this, or is it a bug that `comment-start' is
nil?


I could work around it by setting `comment-start' to "# ", or by
omitting it, when it´s nil, but if it´s a bug, it should rather be
fixed ...


-- 
Knowledge is volatile and fluid.  Software is power.

Re: `comment-start' is nil

[Juanma Barranquero]

On Wed, Mar 12, 2014 at 10:37 PM, lee <lee@yun.yagibdah.de> wrote:

> I´m using desktop-mode to restore the previous session when starting
> emacs.  For some buffers that are restored this way, I´m using a mode
> I´m working on.  This mode employs a function to search for a regex in
> particular buffers.  The regex involves `comment-start'.
>
> Unfortunately, at the time the function is running during start-up, the
> value of `comment-start' is nil.
>
>
>     (let ((end-marker (concat "^" comment-start lsl-hi-lock-patterns-end-marker)))
>         (message "comment-start with %s is %s"
>            (buffer-name)
>            comment-start) ...)
>
>
> gives me messages like "comment-start with test-plane.fontify is nil".
> Calling the same function later works fine because `comment-start' isn´t
> nil anymore.

We'll need more information. It is a major mode or a minor mode? If a
minor, which major mode are these buffers? How it is your function run
during the startup? How does the function get the buffer to run into?
Etc, etc.

    J

Re: `comment-start' is nil

[lee]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, Mar 12, 2014 at 10:37 PM, lee <lee@yun.yagibdah.de> wrote:
>
>> I´m using desktop-mode to restore the previous session when starting
>> emacs.  For some buffers that are restored this way, I´m using a mode
>> I´m working on.  This mode employs a function to search for a regex in
>> particular buffers.  The regex involves `comment-start'.
>>
>> Unfortunately, at the time the function is running during start-up, the
>> value of `comment-start' is nil.
>>
>>
>>     (let ((end-marker (concat "^" comment-start lsl-hi-lock-patterns-end-marker)))
>>         (message "comment-start with %s is %s"
>>            (buffer-name)
>>            comment-start) ...)
>>
>>
>> gives me messages like "comment-start with test-plane.fontify is nil".
>> Calling the same function later works fine because `comment-start' isn´t
>> nil anymore.
>
> We'll need more information. It is a major mode or a minor mode?

(define-derived-mode lsl-mode c++-mode "LSL" ...

I`m not sure if it`s major or minor.  The docstring says it`s major, but
I didn`t write that part of it.

> If a minor, which major mode are these buffers?

Hm, I think it`s a major mode; "LSL" shows up first in the mode line.

> How it is your function run during the startup?

Please see https://github.com/Ratany/lsl-repo/tree/master/emacs --- I
just pushed the latest version, it`s work in progress.

`lsl-mode-apply-hi-lock-patterns' (in lsl-mode.el) is called when the
mode is enabled.  It uses the variable lsl-hi-lock-patterns-file to
figure out from which file to read highlighting patterns.

lsl-hi-lock-patterns-file should be set from the '-*-' line in the
buffer.  By the time the mode is enabled during startup, this variable
is not set.

I have a work-around in place so my code reads the variable from the
'-*-' when it`s not set.

> How does the function get the buffer to run into?

  (unless (assoc-default "\\.lsl$" auto-mode-alist)
    (add-to-list 'auto-mode-alist '("\\.lsl$" . lsl-mode))))

... in `lsl-mode-auto-enable'.

Desktop-mode seems to play into this in that it apparently remembers the
modes of a buffer and re-enables them when restoring the buffers.


-- 
Knowledge is volatile and fluid.  Software is power.

Re: `comment-start' is nil

[Thorsten Jolitz]

lee <lee@yun.yagibdah.de> writes:

> Hi,
>
> I´m using desktop-mode to restore the previous session when starting
> emacs.  For some buffers that are restored this way, I´m using a mode
> I´m working on.  This mode employs a function to search for a regex in
> particular buffers.  The regex involves `comment-start'.
>
> Unfortunately, at the time the function is running during start-up, the
> value of `comment-start' is nil.
>
>
>     (let ((end-marker (concat "^" comment-start lsl-hi-lock-patterns-end-marker)))
>         (message "comment-start with %s is %s"
> 	   (buffer-name)
> 	   comment-start) ...)
>
>
> gives me messages like "comment-start with test-plane.fontify is nil".
> Calling the same function later works fine because `comment-start' isn´t
> nil anymore.
>
> Is it supposed to be like this, or is it a bug that `comment-start' is
> nil?
>
>
> I could work around it by setting `comment-start' to "# ", or by
> omitting it, when it´s nil, but if it´s a bug, it should rather be
> fixed ...

maybe call

,-----------------------------------------------------------------------
| comment-normalize-vars is a compiled Lisp function in `newcomment.el'.
| 
| (comment-normalize-vars &optional NOERROR)
| 
| Check and set up variables needed by other commenting functions.
| All the `comment-*' commands call this function to set up various
| variables, like `comment-start', to ensure that the commenting
| functions work correctly.  Lisp callers of any other `comment-*'
| function should first call this function explicitly.
`-----------------------------------------------------------------------

before using comment-start?

-- 
cheers,
Thorsten

Re: `comment-start' is nil

[Michael Heerdegen]

lee <lee@yun.yagibdah.de> writes:

>  This mode employs a function to search for a regex in particular
> buffers.  The regex involves `comment-start'.

If you want to rely on `comment-start', AFAIK you must wait until the
major mode of the buffer has been initialized, because `comment-start'
is set by the major mode.

Michael.

Re: `comment-start' is nil

[lee]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> lee <lee@yun.yagibdah.de> writes:
>
>>  This mode employs a function to search for a regex in particular
>> buffers.  The regex involves `comment-start'.
>
> If you want to rely on `comment-start', AFAIK you must wait until the
> major mode of the buffer has been initialized, because `comment-start'
> is set by the major mode.

Is is advisable to call `comment-normalize-vars' before using
`comment-start' as Thorsten suggests?  Maybe it`s not a good idea not to
wait until the major mode is up?

But then:


,----
| comment-start is a variable defined in `newcomment.el'.
| Its value is "> "
| Local in buffer *unsent wide reply to Michael Heerdegen on help-gnu-emacs@gnu.org*; global value is "# "
| 
|   This variable is safe as a file local variable if its value
|   satisfies the predicate `string-or-null-p'.
| 
| Documentation:
| String to insert to start a new comment, or nil if no comment syntax.
`----


Perhaps a major mode is supposed to set this variable (before trying to
use it)?

So far, I am assuming '# ' when it`s nil.  I`m now noticing that this
might not be the right thing to do because nil is used to indicate that
there is no comment syntax.

So what does one do?  Set it when it`s a major mode and otherwise rely
on that it is not nil --- or nil when there is no comment syntax ---
before it`s being used?

Arbitrary files seem to use the global default, though.  Under what
circumstances is there no comment syntax?


-- 
Knowledge is volatile and fluid.  Software is power.

Re: `comment-start' is nil

[Stefan]

> Is is advisable to call `comment-normalize-vars' before using
> `comment-start' as Thorsten suggests?

No: comment-normalize-vars uses comment-start to set other vars, not the
other way around.


        Stefan