[PATCH] auto-EOF for bookmarks

[PATCH] auto-EOF for bookmarks

[Daniel Colascione]

[-- Attachment #1.1: Type: text/plain, Size: 337 bytes --]

This patch changes the bookmark feature to automatically jump to the end
of the buffer if a bookmark was set there. It is backwards-compatible.
If the change in default behavior is too drastic, then would it be okay
to add a facility to explicitly set a follow-EOF bookmark?

(Not planning to merge for feature freeze, of course.)

[-- Attachment #1.2: at-eof.patch --]
[-- Type: text/plain, Size: 3323 bytes --]

=== modified file 'lisp/bookmark.el'
--- lisp/bookmark.el	2011-07-05 15:31:22 +0000
+++ lisp/bookmark.el	2011-07-11 02:02:05 +0000
@@ -381,10 +381,18 @@
   (bookmark-prop-get bookmark-name-or-record 'position))
 
 
+(defun bookmark-get-at-eof (bookmark-name-or-record)
+  "Return the at-eof flag of BOOKMARK-NAME-OR-RECORD, or nil if none."
+  (bookmark-prop-get bookmark-name-or-record 'at-eof))
+
+
 (defun bookmark-set-position (bookmark-name-or-record position)
   "Set the position (i.e.: point) of BOOKMARK-NAME-OR-RECORD to POSITION."
   (bookmark-prop-set bookmark-name-or-record 'position position))
 
+(defun bookmark-set-at-eof (bookmark-name-or-record at-eof-flag)
+  "Set the at-eof flag of BOOKMARK-NAME-OR-RECORD to AT-EOF_FLAG."
+  (bookmark-prop-set bookmark-name-or-record 'at-eof at-eof-flag))
 
 (defun bookmark-get-front-context-string (bookmark-name-or-record)
   "Return the front-context-string of BOOKMARK-NAME-OR-RECORD, or nil if none."
@@ -544,6 +552,12 @@
                                    (point)
                                    (- (point) bookmark-search-size))
                                   nil))))
+    ,@(when (save-excursion
+              (save-restriction
+                (widen)
+                (when posn (goto-char posn))
+                (eobp)))
+        `((at-eof . t)))
     (position . ,(or posn (point)))))
 
 \f
@@ -1119,7 +1133,8 @@
 	(buf           (bookmark-prop-get bmk-record 'buffer))
         (forward-str   (bookmark-get-front-context-string bmk-record))
         (behind-str    (bookmark-get-rear-context-string bmk-record))
-        (place         (bookmark-get-position bmk-record)))
+        (place         (bookmark-get-position bmk-record))
+        (at-eof        (bookmark-get-at-eof bmk-record)))
     (set-buffer
      (cond
       ((and file (file-readable-p file) (not (buffer-live-p buf)))
@@ -1128,16 +1143,18 @@
       ((and buf (get-buffer buf)))
       (t ;; If not, raise error.
        (signal 'bookmark-error-no-filename (list 'stringp file)))))
-    (if place (goto-char place))
-    ;; Go searching forward first.  Then, if forward-str exists and
-    ;; was found in the file, we can search backward for behind-str.
-    ;; Rationale is that if text was inserted between the two in the
-    ;; file, it's better to be put before it so you can read it,
-    ;; rather than after and remain perhaps unaware of the changes.
-    (when (and forward-str (search-forward forward-str (point-max) t))
-      (goto-char (match-beginning 0)))
-    (when (and behind-str (search-backward behind-str (point-min) t))
-      (goto-char (match-end 0)))
+    (if at-eof
+        (goto-char (point-max))
+      (if place (goto-char place))
+      ;; Go searching forward first.  Then, if forward-str exists and
+      ;; was found in the file, we can search backward for behind-str.
+      ;; Rationale is that if text was inserted between the two in the
+      ;; file, it's better to be put before it so you can read it,
+      ;; rather than after and remain perhaps unaware of the changes.
+      (when (and forward-str (search-forward forward-str (point-max) t))
+        (goto-char (match-beginning 0)))
+      (when (and behind-str (search-backward behind-str (point-min) t))
+        (goto-char (match-end 0))))
     nil))
 
 ;;;###autoload


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: [PATCH] auto-EOF for bookmarks

[Drew Adams]

> This patch changes the bookmark feature to automatically jump 
> to the end of the buffer if a bookmark was set there. It is
> backwards-compatible.  If the change in default behavior is
> too drastic, then would it be okay to add a facility to
> explicitly set a follow-EOF bookmark?

It's fine to add an optional ability to say "create a bookmark that will always
point to the eob/eof".  As one user, I disagree that creating a bookmark at eob
should automatically or by default create it as an always-go-to-eob-bookmark.

IOW, as an option, I don't have a problem with it, but it shouldn't be what
happens by default when you create a bookmark with point at eob.

I also wonder a bit, "Why?".  How hard is it to hit `M->' after jumping to a
bookmark?  Am I missing something wrt the use case?

Re: [PATCH] auto-EOF for bookmarks

[Karl Fogel]

"Drew Adams" <drew.adams@oracle.com> writes:
>> This patch changes the bookmark feature to automatically jump 
>> to the end of the buffer if a bookmark was set there. It is
>> backwards-compatible.  If the change in default behavior is
>> too drastic, then would it be okay to add a facility to
>> explicitly set a follow-EOF bookmark?
>
>It's fine to add an optional ability to say "create a bookmark that
>will always point to the eob/eof".  As one user, I disagree that
>creating a bookmark at eob should automatically or by default create it
>as an always-go-to-eob-bookmark.
>
>IOW, as an option, I don't have a problem with it, but it shouldn't be
>what happens by default when you create a bookmark with point at eob.
>
>I also wonder a bit, "Why?".  How hard is it to hit `M->' after jumping
>to a bookmark?  Am I missing something wrt the use case?

I think Drew's final question there sums up my feelings too.

I can why always-go-to-EOF would be useful sometimes, but... it's
already so easy to jump to the end of a buffer with `M->' anyway.

The UI machinery needed to distinguish between "I want to set a bookmark
right here, near these words" and "I want to set a bookmark right here,
always at the end of the file" would be cumbersome.  We'd have to find a
way to ask the user each time, or the user would have to know a special
prefix sequence, or a variable, or whatever, to specify it.

IMHO, the cost of this UI machinery would outweigh the limited benefit
of having the feature at all.

Best,
-Karl