longlines.el fix?

longlines.el fix?

[David Kastrup]

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


I just noticed that a suggestion of mine for preserving markers when
inserting has made it into longlines.el.

In my private copy, I also have the following fix in.  Since I rarely
use longlines.el, it has seen only cursory testing.  Does anybody see
a particular problem with it?  If not, maybe we should check it in so
that it gets some testing.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1755 bytes --]

Index: longlines.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/longlines.el,v
retrieving revision 1.20
diff -u -r1.20 longlines.el
--- longlines.el	20 Nov 2005 05:17:27 -0000	1.20
+++ longlines.el	23 Nov 2005 16:08:37 -0000
@@ -245,19 +245,24 @@
 	     (forward-char 1)
              nil)
     (if (longlines-merge-lines-p)
-        (progn (end-of-line)
-               (delete-char 1)
-     ;; After certain commands (e.g. kill-line), there may be two
-     ;; successive soft newlines in the buffer.  In this case, we
-     ;; replace these two newlines by a single space.  Unfortunately,
-     ;; this breaks the conservation of (spaces + newlines), so we
-     ;; have to fiddle with longlines-wrap-point.
-               (if (or (bolp) (eolp))
-                   (if (> longlines-wrap-point (point))
-                       (setq longlines-wrap-point
-                             (1- longlines-wrap-point)))
-                 (insert-char ?  1))
-               nil)
+        (let ((bolp (progn (end-of-line) (bolp))))
+	  (forward-char 1)
+	  ;; After certain commands (e.g. kill-line), there may be two
+	  ;; successive soft newlines in the buffer.  In this case, we
+	  ;; replace these two newlines by a single space.  Unfortunately,
+	  ;; this breaks the conservation of (spaces + newlines), so we
+	  ;; have to fiddle with longlines-wrap-point.
+	  (if (or bolp (eolp))
+	      (progn
+		(delete-char -1)
+		(if (> longlines-wrap-point (point))
+		    (setq longlines-wrap-point
+			  (1- longlines-wrap-point))))
+	    (insert-before-markers-and-inherit " ")
+	    (backward-char 1)
+	    (delete-char -1)
+	    (forward-char 1))
+	  nil)
       (forward-line 1)
       t)))
 

[-- Attachment #3: Type: text/plain, Size: 52 bytes --]



-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: longlines.el fix?

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> I just noticed that a suggestion of mine for preserving markers when
> inserting has made it into longlines.el.
>
> In my private copy, I also have the following fix in.  Since I rarely
> use longlines.el, it has seen only cursory testing.  Does anybody see
> a particular problem with it?  If not, maybe we should check it in so
> that it gets some testing.

Looks OK to me.  Please check it in.

Re: longlines.el fix?

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I just noticed that a suggestion of mine for preserving markers when
>> inserting has made it into longlines.el.
>>
>> In my private copy, I also have the following fix in.  Since I rarely
>> use longlines.el, it has seen only cursory testing.  Does anybody see
>> a particular problem with it?  If not, maybe we should check it in so
>> that it gets some testing.
>
> Looks OK to me.  Please check it in.

I checked in a slightly modified version of the patch that more
obviously "does the same thing" after testing it somewhat.

I am not sure that "the same thing" is correct however: the
description of the `end-of-line' function sounds like field boundaries
could cause problems.  I just have no clue about the ramifications of
"fields" and whether they can occur in longlines buffers.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: longlines.el fix?

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> I checked in a slightly modified version of the patch that more
> obviously "does the same thing" after testing it somewhat.
>
> I am not sure that "the same thing" is correct however: the
> description of the `end-of-line' function sounds like field boundaries
> could cause problems.  I just have no clue about the ramifications of
> "fields" and whether they can occur in longlines buffers.

Thanks.