4

A while ago, skimming through emacs-orgmode mailing list, I read this message by Stefan Monnier:

I'm on a crusade to eradicate the `intangible' property, which happens to rub me the wrong way because it's implemented at too-low a level (it affects every point movement) which incurs a significant performance penalty (even when not used) and affects a lot of code which then needs to be fixed by binding inhibit-point-motion-hooks (which I'm considering defaulting to t).

Got me wondering about this inhibit-point-motion-hooks variable. In what particular cases is it used?

Assuming Stefan's statement about "defaulting it to t" isn't motivated by weariness, does it make a difference to change its value globally? What about performance-wise?

Dan
  • 32,584
  • 6
  • 98
  • 168
undostres
  • 1,793
  • 12
  • 15
  • 3
    Did you consult the [manual](http://www.gnu.org/software/emacs/manual/html_node/elisp/Special-Properties.html)? If so, please clarify what is unclear to you about it. See the description of properties `point-entered` and `point-left` in the same node of the manual. `inhibit-point-motion-hooks` lets you prevent the associated hooks from running. – Drew Apr 27 '15 at 05:11
  • @Drew Yes, I read the manual and the docstring but still Stefan's comment is unclear to me. It is a broad question though, will try to narrow it down. – undostres Apr 27 '15 at 11:07
  • 1
    The problem with the current implementation is that whenever the point is moved (which really should be about updating an integer and ensure that it's within `(point-min)` and `(point-max)`), Emacs now has to check if the underlying text has some magic text properties and, if so, ensure that the point is updated. This 1) is inefficient and 2) would confuse a *lot* of code that don't expect someone else to move the point. Fixing this can be done by either wrapping all those pieces of code with `(let ((inhibit-point-motion-hooks t)) ...)` or by killing the feature. – Lindydancer Apr 28 '15 at 06:30
  • 1
    Also, if I remember correctly, he was open to implementing something similar that would move the point at the end of a user-level command. This could be implemented in the command loop, and thus would be much more efficient and not affect the large body of code that already exists. – Lindydancer Apr 28 '15 at 06:33

1 Answers1

2

BTW, with respect to performance, yes it can make a measurable difference in some circumstances (because this variable controls the lookup of the point-entered, point-left, and intangible text-properties, which is done every time point is changes, i.e. for every call to goto-char or any other function which moves point, and such movements can happen thousands of times in a single command).

Actually, my recent activity around this subject was triggered by a complaint about a performance problem which can be significantly reduced by setting inhibit-point-motion-hooks to t.

Stefan
  • 26,154
  • 3
  • 46
  • 84
  • Thank you. I was wondering if it was safe to globally set this variable to t. – undostres May 03 '15 at 15:32
  • I think it is safe in the sense that you shouldn't lose any data, but it may/will affect a few packages in minor ways (mostly by letting you move into areas which are normally made "intangible"). – Stefan May 03 '15 at 23:48