bug#26623: 24.5; bad variable name: `inside-post-command-hook'

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Drew Adams]

This variable's name should not end in `-hook', because that means,
by convention, that this is a hook variable, which it is not.

This is a Boolean-valued, internal variable whose value indicates only
whether execution is currently inside the post-command-hook.

It should have a name that indicates (1) that it is Boolean and
perhaps (2) that it is internal.

In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Eli Zaretskii]

> Date: Sun, 23 Apr 2017 10:00:52 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> This variable's name should not end in `-hook', because that means,
> by convention, that this is a hook variable, which it is not.

No, it's the other way around: a hook variable should have its name
end in "-hook", but not every symbol whose name ends in "-hook" is a
hook variable.

I think the name of this variable speaks very clearly for its purpose,
and see no reason for such formalism in this case.

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No, it's the other way around: a hook variable should have its name
  > end in "-hook", but not every symbol whose name ends in "-hook" is a
  > hook variable.

I think it is a good idea to avoid making more variables that are not
hooks but have names which suggest they were hooks.  Let's aim to have
-hook mean it's a hook.


Perhaps `inside-post-command-hook-call' is a good name for this
variable.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: drew.adams@oracle.com, 26623@debbugs.gnu.org
> Date: Wed, 26 Apr 2017 13:18:51 -0400
> 
> I think it is a good idea to avoid making more variables that are not
> hooks but have names which suggest they were hooks.  Let's aim to have
> -hook mean it's a hook.

I agree, and I wrote that much.  But having a single variable ending
in a "-hook" that is an exception from that rule is hardly a
catastrophe.

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   But having a single variable ending
  > in a "-hook" that is an exception from that rule is hardly a
  > catastrophe.

It's not a catastrophe, but it's a flaw -- and easy to fix.
So let's fix it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[npostavs]

tags 26623 = fixed
close 26623 26.1
quit

Richard Stallman <rms@gnu.org> writes:
>
> Perhaps `inside-post-command-hook-call' is a good name for this
> variable.
[...]
> It's not a catastrophe, but it's a flaw -- and easy to fix.
> So let's fix it.

Done [1: abd098200b].

[1: abd098200b]: 2017-05-20 19:13:57 -0400
  Don't end non-hook variable with "-hook" (Bug#26623)
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=abd098200bfba2577dfff800f27d5474f13cc1f3

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Drew Adams]

> > This variable's name should not end in `-hook', because that means,
> > by convention, that this is a hook variable, which it is not.
> 
> No, it's the other way around: a hook variable should have its name
> end in "-hook", but not every symbol whose name ends in "-hook" is a
> hook variable.

Clearly nothing _prevents_ a non-hook-variable symbol from having
such a perverted name as to suggest that it is a hook variable.

But that is not what the convention is for.  I don't think you
can show documentation to support such a use.

This is a perversion, which works against users.  Think `apropos'
or think completion (assuming substring or regexp matching, both
of which are possible now even with vanilla Emacs), to look for
or discover hook variables.

This particular non-hook variable works against users for this
and similar use cases - it simply gives the wrong message,
claiming loud and clear that it is a hook variable.  And to
what end?  What possible reason could we have for keeping such
a misleading name here?

> I think the name of this variable speaks very clearly for its purpose,
> and see no reason for such formalism in this case.

No, it does not speak clearly for its purpose.  Its purpose is
to be a Boolean flag for whether execution is currently inside
that hook.

Simply end the name with `-p' or `?' or some other suffix that
suggests that this is a Boolean variable.  And more importantly
does not suggest that it is a hook variable, which it is not.

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Eli Zaretskii]

> Date: Wed, 26 Apr 2017 06:39:18 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 26623@debbugs.gnu.org
> 
> This is a perversion, which works against users.

It can only work in a few exceptional cases, I agree.  And I think
this is one such case.  If this were wide-spread, then yes, we should
have done something about it.

> > I think the name of this variable speaks very clearly for its purpose,
> > and see no reason for such formalism in this case.
> 
> No, it does not speak clearly for its purpose.

We disagree, that's all.

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Drew Adams]

> > > I think the name of this variable speaks very clearly for its purpose,
> >
> > No, it does not speak clearly for its purpose.

Reasons given elided, not addressed.

> We disagree, that's all.

No reasons given.

Ever use an `apropos' command on variables whose names end in
`-hook'?  Do you expect to see only hook variables for that?

Ever use regexp-matching completion with `C-h v' for `-hook$'?
Do you expect to see only hook variables for that?

Is there an actual reason why you will not add a suffix (or
make another suitable name change) to indicate clearly that
this is not a hook variable?

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Eli Zaretskii]

> Date: Wed, 26 Apr 2017 10:19:33 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 26623@debbugs.gnu.org
> 
> > > > I think the name of this variable speaks very clearly for its purpose,
> > >
> > > No, it does not speak clearly for its purpose.
> 
> Reasons given elided, not addressed.

There's no need for reasons to disagree about clarity of something.

> > We disagree, that's all.
> 
> No reasons given.

Reasons were given, but were elided and ignored.

And btw, where's that variable defined?  I cannot find its definition,
and C-h commands cannot find anything whose name is
inside-post-command-hook or similar.

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[npostavs]

tags 26623 unreproducible moreinfo
quit

Eli Zaretskii <eliz@gnu.org> writes:

> And btw, where's that variable defined?  I cannot find its definition,
> and C-h commands cannot find anything whose name is
> inside-post-command-hook or similar.

Yeah, there's seems to have been quite a bit of discussion over a
variable that apparently doesn't actually exist.

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Glenn Morris]

follow-inside-post-command-hook

bug#26623: 24.5; bad variable name: `inside-post-command-hook'

[Glenn Morris]

PS simply make the initial report a patch next time, please.
Think of the users! (And the developers.)