Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Stefan Monnier]

> +    (add-hook 'beacon-dont-blink-predicates
> +              (lambda () (bound-and-true-p hl-line-mode)))"
>    :type 'hook)
 
> -(add-hook 'beacon-dont-blink-predicates (lambda () (bound-and-true-p hl-line-mode)))
>  (add-hook 'beacon-dont-blink-predicates #'window-minibuffer-p)

This add-hook will interfere with defcustom's handling of the variable
(i.e. Customize will rightly complain that "the variable was modified
outside of Customize").


        Stefan

Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Artur Malabarba]

Then I'm clearly unaware of something here.
There was a discussion here a few months ago where I learned that
hooks should always be defined with nil initial values.
So, if it must be defined empty, and it's wrong to add entries to it
later, then what's the correct way for a package to have a non-empty
hook?

2015-10-18 4:20 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> +    (add-hook 'beacon-dont-blink-predicates
>> +              (lambda () (bound-and-true-p hl-line-mode)))"
>>    :type 'hook)
>
>> -(add-hook 'beacon-dont-blink-predicates (lambda () (bound-and-true-p hl-line-mode)))
>>  (add-hook 'beacon-dont-blink-predicates #'window-minibuffer-p)
>
> This add-hook will interfere with defcustom's handling of the variable
> (i.e. Customize will rightly complain that "the variable was modified
> outside of Customize").
>
>
>         Stefan

Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Stefan Monnier]

> Then I'm clearly unaware of something here.
> There was a discussion here a few months ago where I learned that
> hooks should always be defined with nil initial values.
> So, if it must be defined empty, and it's wrong to add entries to it
> later, then what's the correct way for a package to have a non-empty
> hook?

A custom var shouldn't be modified programmatically.

But hook should usually be modified via `add-hook'
(i.e. programmatically).

Ergo, hooks are better defined with defvar than with defcustom.

Otherwise, define 2 hooks: a defvar one, modified via add-hook, and
a defcustom one, only modified via Custom.


        Stefan

Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Marcin Borkowski]

On 2015-10-19, at 02:56, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> A custom var shouldn't be modified programmatically.

Out of curiosity: why?  I setq all my defcustoms, since I don't use Customize.

>         Stefan

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Stefan Monnier]

>> A custom var shouldn't be modified programmatically.
> Out of curiosity: why?

Because Custom then can't change those chunks of code in order to get
the desired value.

E.g. there's a (setq foo 4) somewhere and the user uses Custom to set
`foo' to 3.  How is customize-save going to make sure that next time
Emacs starts, `foo' will be set to 3 rather than 4?

> I setq all my defcustoms, since I don't use Customize.

As a user you're free not to (setq foo 4) in your ~/.emacs, of course,
and since you don't use Custom, Custom won't have to try and set `foo',
so everything's fine.  And if you do try and set `foo' via Custom, then
Custom will rightfully complain and you'll just get what you deserve.

But as a package author, such a decision is very different: using (setq
foo 4) or add-hook in your package means that all your users will have
problems if they try to set this var via Custom.


        Stefan

Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Kaushal Modi]

I was looking for more info on defcustom vs setq and I was surprised
to find subjective text written in first person (like a personal blog)
in the GNU Emacs manual. I have yet to check if the same is in the
Info manual too.

https://www.gnu.org/software/emacs/manual/html_node/eintr/defcustom.html

"The custom-set-variables function works somewhat differently than a
setq. While I have never learned the differences, I modify the
custom-set-variables expressions in my .emacs file by hand: I make the
changes in what appears to me to be a reasonable manner and have not
had any problems."

"Over time, I have set a considerable number of faces. Some of the
time, I re-set them using customize; other times, I simply edit the
custom-set-faces expression in my.emacs file itself."

"I myself use customize for hardly anything. Mostly, I write
expressions myself."

Who is that "I"? I think all that personal opinion text should be
removed. Correct?

--
Kaushal Modi


On Mon, Oct 19, 2015 at 9:31 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> A custom var shouldn't be modified programmatically.
>> Out of curiosity: why?
>
> Because Custom then can't change those chunks of code in order to get
> the desired value.
>
> E.g. there's a (setq foo 4) somewhere and the user uses Custom to set
> `foo' to 3.  How is customize-save going to make sure that next time
> Emacs starts, `foo' will be set to 3 rather than 4?
>
>> I setq all my defcustoms, since I don't use Customize.
>
> As a user you're free not to (setq foo 4) in your ~/.emacs, of course,
> and since you don't use Custom, Custom won't have to try and set `foo',
> so everything's fine.  And if you do try and set `foo' via Custom, then
> Custom will rightfully complain and you'll just get what you deserve.
>
> But as a package author, such a decision is very different: using (setq
> foo 4) or add-hook in your package means that all your users will have
> problems if they try to set this var via Custom.
>
>
>         Stefan
>

RE: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Drew Adams]

> I was looking for more info on defcustom vs setq and I was surprised
> to find subjective text written in first person (like a personal blog)
> in the GNU Emacs manual. I have yet to check if the same is in the
> Info manual too.
> 
> https://www.gnu.org/software/emacs/manual/html_node/eintr/defcustom.html
> 
> "The custom-set-variables function works somewhat differently than a
> setq. While I have never learned the differences, I modify the
> custom-set-variables expressions in my .emacs file by hand: I make the
> changes in what appears to me to be a reasonable manner and have not
> had any problems."
> 
> "Over time, I have set a considerable number of faces. Some of the
> time, I re-set them using customize; other times, I simply edit the
> custom-set-faces expression in my.emacs file itself."
> 
> "I myself use customize for hardly anything. Mostly, I write
> expressions myself."
> 
> Who is that "I"? I think all that personal opinion text should be
> removed. Correct?

See bug #21695:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21695#8

It might have been OK to say "I have never learned the
differences"  when that was first written, but by now the
manual should understand the differences, and even point
them out.  Especially in that section, which is about
`defcustom'.  The node says:

 "Although you can use 'defvar' or 'setq' for variables that
 users set, the 'defcustom' macro is designed for the job."

Part of its design for that job is handling `:type', `:set'
`:initialize', etc., precisely what makes options different
from ordinary variables and thus `custom-set-variables'
different from `setq'.

Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 19 Oct 2015 10:00:50 -0400
> Cc: Artur Malabarba <bruce.connor.am@gmail.com>,
> 	emacs-devel <emacs-devel@gnu.org>
> 
> "Over time, I have set a considerable number of faces. Some of the
> time, I re-set them using customize; other times, I simply edit the
> custom-set-faces expression in my.emacs file itself."
> 
> "I myself use customize for hardly anything. Mostly, I write
> expressions myself."
> 
> Who is that "I"?

The original author of that manual, Robert J. Chassell.  This text was
there since before the Introduction was added to the Emacs repository.

> I think all that personal opinion text should be removed. Correct?

I'm not sure.  The whole manual is written in that style, so doing
that would mean completely changing its spirit.  Do we really want
that?  What exactly is wrong with that style, in an introductory text
that is meant to take the reader by the hand and lead him/her through
the magic of Emacs Lisp?

Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Kaushal Modi]

> What exactly is wrong with that style, in an introductory text
that is meant to take the reader by the hand and lead him/her through
the magic of Emacs Lisp?

Nothing is wrong with the style. I was mainly pointing out that the
self-opinion style of text contradicted with what is recommended.
- It is recommended that the user does not manually edit the Customize
generated code blocks but a text I quoted says that the author did
that it was fine.
- Also the author does not use Customize most of the times whereas for
a new user it is recommended to do so.


--
Kaushal Modi


On Mon, Oct 19, 2015 at 10:40 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Kaushal Modi <kaushal.modi@gmail.com>
>> Date: Mon, 19 Oct 2015 10:00:50 -0400
>> Cc: Artur Malabarba <bruce.connor.am@gmail.com>,
>>       emacs-devel <emacs-devel@gnu.org>
>>
>> "Over time, I have set a considerable number of faces. Some of the
>> time, I re-set them using customize; other times, I simply edit the
>> custom-set-faces expression in my.emacs file itself."
>>
>> "I myself use customize for hardly anything. Mostly, I write
>> expressions myself."
>>
>> Who is that "I"?
>
> The original author of that manual, Robert J. Chassell.  This text was
> there since before the Introduction was added to the Emacs repository.
>
>> I think all that personal opinion text should be removed. Correct?
>
> I'm not sure.  The whole manual is written in that style, so doing
> that would mean completely changing its spirit.  Do we really want
> that?  What exactly is wrong with that style, in an introductory text
> that is meant to take the reader by the hand and lead him/her through
> the magic of Emacs Lisp?

Re: [elpa] master 9173a44 1/2: [Fix #12] Don't autodisable beacon on hl-line-mode

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 19 Oct 2015 11:28:46 -0400
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
> 	Artur Malabarba <bruce.connor.am@gmail.com>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> Nothing is wrong with the style. I was mainly pointing out that the
> self-opinion style of text contradicted with what is recommended.

Sorry, my misunderstanding.

> - It is recommended that the user does not manually edit the Customize
> generated code blocks but a text I quoted says that the author did
> that it was fine.
> - Also the author does not use Customize most of the times whereas for
> a new user it is recommended to do so.

Indeed, that manual is in dire need of updates.  Feel free to bring it
up to speed with the current development and latest use
recommendations.

Thanks in advance.