* longlines.el fix?
@ 2005-11-23 16:16 David Kastrup
2005-11-23 17:03 ` Chong Yidong
0 siblings, 1 reply; 4+ messages in thread
From: David Kastrup @ 2005-11-23 16:16 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: longlines.el fix?
2005-11-23 16:16 longlines.el fix? David Kastrup
@ 2005-11-23 17:03 ` Chong Yidong
2005-11-25 11:11 ` David Kastrup
0 siblings, 1 reply; 4+ messages in thread
From: Chong Yidong @ 2005-11-23 17:03 UTC (permalink / raw)
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: longlines.el fix?
2005-11-23 17:03 ` Chong Yidong
@ 2005-11-25 11:11 ` David Kastrup
2005-11-25 16:36 ` Chong Yidong
0 siblings, 1 reply; 4+ messages in thread
From: David Kastrup @ 2005-11-25 11:11 UTC (permalink / raw)
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: longlines.el fix?
2005-11-25 11:11 ` David Kastrup
@ 2005-11-25 16:36 ` Chong Yidong
0 siblings, 0 replies; 4+ messages in thread
From: Chong Yidong @ 2005-11-25 16:36 UTC (permalink / raw)
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-11-25 16:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-23 16:16 longlines.el fix? David Kastrup
2005-11-23 17:03 ` Chong Yidong
2005-11-25 11:11 ` David Kastrup
2005-11-25 16:36 ` Chong Yidong
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).