Re: Bug: Refile sometimes loses the last line [7.7 (release_7.7.15.gc363)]

[David Maus <dmaus@ictsoc.de>]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

At Thu, 04 Aug 2011 09:35:24 -0500,
Jason Dunsmore wrote:
>
> Hi David,
>
> > I just pushed a simplified version of the solution: No need to count
> > lines, just check if point is at end of buffer.
>
> I just tried out your patch.  The logic in your patch is slightly
> different - it checks if the point is at the end of the last line in the
> buffer, whereas mine checks if the point is anywhere on the last line.
> I don't think it fixes the problem.  Bernt, can you test it?

I does it for me and should do the trick. I tracked down the problem
to `org-copy-subtree' not beeing able to correctly determine the end
of the subtree to copy.

The problem is here:

,----
|     (setq beg (point))
|     (skip-chars-forward " \t\r\n")
|     (save-match-data
|       (save-excursion (outline-end-of-heading)
| 		      (setq folded (outline-invisible-p)))
|       (condition-case nil
| 	  (org-forward-same-level (1- n) t)
| 	(error nil))
|       (org-end-of-subtree t t))
|     (org-back-over-empty-lines)
`----

(org-end-of-subtree t t) moves point to either 1/ the beginning of the
following sibling, 2/ the beginning of the last empty line in buffer
if it is present, or 3/ to the end of the last line if an last empty
line is missing.

3/ is the edge-case in question. 1/ and 2/ work with the assumption
that point is /not/ inside the entry if back-over-empty-lines is
called. Thus

(forward-line -1)
(beginning-of-line 2)

for 1/ and 2/ means: Stay where you are. For 3/ it doesn't. For 3/ it
moves point to the beginning of the last line in buffer, i.e. in front
of the last line of content in the entry.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]