Matt Lundin <m...@imapmail.org> writes:
> Nick Dokos <ndo...@gmail.com> writes:
>
>>
>> I haven't been able to work on the problem, but assuming that your
>> diagnosis above is correct, perhaps the thing to do is to bind
>> buffeer-invisibility-spec to nil inside org-move-to-column:
>>
>> (defun org-move-to-column (column &optional force buffer)
>> (let ((buffer-invisibility-spec nil))
>> (if (featurep 'xemacs)
>> (org-xemacs-without-invisibility (move-to-column column force
>> buffer))
>> (move-to-column column force))))
>>
>> What do you think?
>
> That solves the problem beautifully. Would it have any negative
> side-effects for other org functions, especially those that invoke
> org-move-to-column in normal org buffers?
>
I hope not, but I don't know for sure. OTOH, we can try it and, if there
are complaints, we can revert it and apply a more localized version of
the same fix: just wrap the relevant *call* of org-move-to-column in a
(let ((buffer-invisibility-spec nil))
(org-move-to-column ....))
But (without any solid evidence) it seems to me that having the behavior
of move-to-column change with the buffer-invisibility-spec setting is a
bug: how can anybody expect reproducible behavior from it if you don't
know where point is going to end up? So I would be surprised if the fix
does have negative side effects on anything: on the contrary, it might
resolve some mysteries. OTOH, putting the let in the compat function
would be a workaround for org, but the real fix should probably be in
move-to-column itself. Perhaps a question to emacs devel is warranted.
--
Nick
