[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: longlines.el problems...
From: |
Chong Yidong |
Subject: |
Re: longlines.el problems... |
Date: |
Tue, 12 Jul 2005 13:05:14 -0400 (EDT) |
User-agent: |
SquirrelMail/1.4.4 |
> I just tried out longlines-mode with AUCTeX/preview-latex. Cough,
> cough. One problem that it has is that it does not preserve markers
> around spaces/newlines.
>
> Here is how to do this in one case (unless I am mistaken):
> But it looks like quite a number of other passages might need similar
> fixes.
There is only one place where spaces and newlines are converted into one
another; that is the function longlines-wrap-line. So you missed only one
spot. The following patch follows through on your suggested changes. It
is correct as far as longlines is concerned; could you check if it does
the right thing for AUCTeX/preview-latex?
I didn't test longlines with AUCTeX/preview-latex, because I don't have
those installed. So chances are there'll be incompatibilities :-/
> Another thing worth mentioning is that in the presence of images, font
> locking with different font sizes, proportional fonts and similar, the
> wrapped column should certainly be the visual column instead of
> anything else. This means, for example, that it is completely useless
> to insert a newline in the middle of an image: it only makes sense to
> replace such spaces that have a different visual column.
> Unfortunately, current-column does not take images into account.
Sure, it would be nice, but (from what I remember) it's a pretty
complicated problem. So longlines simply uses the value of fill-column.
This is simple, plays nicely with fill-paragraph, and works just fine 99%
of the time.
If your fancy fonts make the fill-paragraph column fall short of the
screen width, it's generally not too ugly; things only start getting weird
if your fancy fonts make the fill-paragraph column extend past the screen
width. But it'll be weird whether or not longlines is active.
*** emacs/lisp/longlines.el~ Wed Jul 13 00:05:40 2005
--- emacs/lisp/longlines.el Wed Jul 13 00:48:19 2005
***************
*** 207,229 ****
If wrapping is performed, point remains on the line. If the line does
not need to be wrapped, move point to the next line and return t."
(if (longlines-set-breakpoint)
! (progn (backward-char 1)
! (delete-char 1)
! (insert-char ?\n 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)
(forward-line 1)
t)))
--- 207,234 ----
If wrapping is performed, point remains on the line. If the line does
not need to be wrapped, move point to the next line and return t."
(if (longlines-set-breakpoint)
! (progn (insert-before-markers "\n")
! (backward-char 1)
! (delete-char -1)
! (forward-char 1)
nil)
(if (longlines-merge-lines-p)
(progn (end-of-line)
! (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 (eq (char-after) ?\n)
! (progn (if (> longlines-wrap-point (point))
! (setq longlines-wrap-point
! (1- longlines-wrap-point)))
! (delete-char -1))
! (insert-before-markers " ")
! (backward-char 1)
! (delete-char -1)
! (forward-char 1))
nil)
(forward-line 1)
t)))