2

text-scale-mode uses a buffer-local face-remapping-alist to scale the buffer's text, adding values like (:height 1.2). It stores a "cookie" with the scaling it has applied in another local variable, text-scale-mode-remapping, and uses this to locate and remove previous scalings whenever the height needs to be reset.

Neither face-remapping-alist nor text-scale-mode-remapping are marked as permanent-local, so any event that wipes out buffer-local variables (e.g. changing major-modes) will clear them both. From text-scale-mode's perspective, this is fine: clearing face-remapping-alist causes the height to be reset, so there's no need to preserve text-scale-mode-remapping.

I'm using face-remapping-alist to change the background color of certain buffers, and want this to persist even when buffer-local variables are cleared, so I've marked it as permanent-local. This causes problems for text-scale-mode when local variables are cleared: it's height adjustments survive, but its memory of having applied them is lost when text-scale-mode-remapping is cleared. I can increase/decrease the height, but attempting to reset it to its true default just resets it to the height it had last time local variables were cleared.

I've fixed this by marking text-scale-mode-remapping permanent-local as well. I considered submitting a bug-report for text-scale-mode, but it only makes sense to mark text-scale-mode-remapping permanent local if face-remapping-alist is permanent-local too, and I don't know if that's a desireable default. I prefer it that way, but maybe there are other use-cases where it's not?

  • 1
    One could image a system where both the local and the global variable values were used, along the lines of hooks. – Lindydancer Feb 6 '17 at 9:16
  • @Lindydancer: The issue is not one of global vs buffer-local, but one of buffer-local vs mode-local. But indeed, one could imagine that kill-all-local-variables could be told to keep some of the elements of face-remapping-alist, like we do with permanent-local-hook. – Stefan Feb 7 '17 at 13:04
5

permanent-local is fundamentally a way to distinguish whether the variable's buffer-local value is really specific to this buffer or is specific to the mode currently in use in this buffer.

Sadly, in practice, for many buffer-local variables which are not specific to a particular package, whether the setting belongs to the buffer or to the mode will depend not so much on the variable itself but on the package that uses this variable. IOW it should sometimes be permanent-local and sometimes not.

I suggest you report this as a bug, and take advantage of it to request another way to specify "permanent-localness". One which can be set locally by a package and only affects this package's own use of that variable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.