On 14.8.2013, at 17:45, Nick Dokos <ndo...@gmail.com> wrote: > 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.
Hi Nick, I also do not expect negative consequences. Please apply the patch, will you? Thanks! - Carsten > > -- > Nick > >
