help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A possible marker bug in emacs 20.4


From: Bingham, Jay
Subject: A possible marker bug in emacs 20.4
Date: Mon, 5 Mar 2001 11:56:29 -0800

I have come across an interesting situation regarding the use of markers.

I am using emacs 20.4

I wrote a little procedure which removes text from a buffer.  I wanted to
enhance it to return point to its original position after it was finished
removing all matches of the string.  Here is the function:

(defun trim-buffer ()
  "Remove trailing whitespace from the lines in a buffer
returning point to its original position when finished.
Returning point to the original position means that it will be between the
same characters
that it was between when the function was invoked, unless one or both of the
characters
were removed, in which case it will be between the characters immediately
before and after
the deleted text.
Whitespace for the purposes of this function is space, tab, and carriage
return characters."
  (interactive)
  (let ((start-loc (make-marker)))
    (setq start-loc (point))
    (goto-char (point-min))
    (while (and (< (point) (point-max))
                      (re-search-forward "[ \t^M]*$" nil t))
      (replace-match "" nil t)
      (and (< (point) (point-max)) (forward-char)))
    (not-modified)
    (goto-char start-loc)))

>From the description of markers in the Elisp reference manual I assumed that
start-loc would be adjusted when replace-match deleted the spaces, tabs, and
carriage return characters from the buffer.  This does not occur inside this
function.  When I create a test buffer, set mark in it, then use
re-search-forward and replace-match from the eval prompt the marker
arithmetic gets done.  Is this a misunderstanding on my part of how/when the
marker arithmetic is done or is this a bug?


-_
J_)
C_)ingham
Compaq Telecommunications
Austin, TX




reply via email to

[Prev in Thread] Current Thread [Next in Thread]