From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Chong Yidong" Newsgroups: gmane.emacs.devel Subject: Re: longlines.el problems... Date: Tue, 12 Jul 2005 13:05:14 -0400 (EDT) Message-ID: <2656.220.255.229.97.1121187914.squirrel@www.stupidchicken.com> References: <85irzgewr0.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1121189137 4033 80.91.229.2 (12 Jul 2005 17:25:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 12 Jul 2005 17:25:37 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 12 19:25:34 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DsOUn-0006yS-Nn for ged-emacs-devel@m.gmane.org; Tue, 12 Jul 2005 19:24:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DsOWQ-0000es-Vy for ged-emacs-devel@m.gmane.org; Tue, 12 Jul 2005 13:26:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DsOTF-000846-C0 for emacs-devel@gnu.org; Tue, 12 Jul 2005 13:23:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DsOTE-00083W-9s for emacs-devel@gnu.org; Tue, 12 Jul 2005 13:23:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DsORg-0007R8-9y for emacs-devel@gnu.org; Tue, 12 Jul 2005 13:21:24 -0400 Original-Received: from [64.21.80.18] (helo=shark.whbdns.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DsOJp-0008GU-KA; Tue, 12 Jul 2005 13:13:17 -0400 Original-Received: from stupidch by shark.whbdns.com with local (Exim 4.50) id 1DsOC2-0004WT-3t; Tue, 12 Jul 2005 13:05:14 -0400 Original-Received: from 220.255.229.97 ([220.255.229.97]) (SquirrelMail authenticated user cyd@stupidchicken.com) by www.stupidchicken.com with HTTP; Tue, 12 Jul 2005 13:05:14 -0400 (EDT) In-Reply-To: <85irzgewr0.fsf@lola.goethe.zz> Original-To: "David Kastrup" User-Agent: SquirrelMail/1.4.4 X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shark.whbdns.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [32675 33085] / [47 12] X-AntiAbuse: Sender Address Domain - stupidchicken.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:40839 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40839 > 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)))