From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.help Subject: Re: Mode for Manuscripts? Date: Thu, 18 Dec 2003 18:24:23 +0000 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <87brq6q90o.fsf@emptyhost.emptydomain.de> References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071772342 4504 80.91.224.253 (18 Dec 2003 18:32:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2003 18:32:22 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 18 19:32:16 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AX2wZ-00028d-00 for ; Thu, 18 Dec 2003 19:32:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AX3ra-0007vy-6Z for geh-help-gnu-emacs@m.gmane.org; Thu, 18 Dec 2003 14:31:10 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!213-203-244-156.kunde.vdserver.DE!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 117 Original-NNTP-Posting-Host: 213-203-244-156.kunde.vdserver.de (213.203.244.156) Original-X-Trace: news.uni-berlin.de 1071771879 7508690 213.203.244.156 ([73968] 10430) User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) Cancel-Lock: sha1:USHTb8PXZs4gO05Oo4Oi2hoZX0Q= Original-Xref: shelby.stanford.edu gnu.emacs.help:119490 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:15429 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:15429 gebser@speakeasy.net writes: > At 20:44 (UTC-0000) on Wed, 17 Dec 2003 Kai Grossjohann said: > > = gebser@speakeasy.net writes: > = > = > Sure.... > = > = Maybe you could play with format-alist to frob the file contents on > = the way from file to Emacs and back. That way, you wouldn't see the > = double newlines, but they'd be in the file. > > I think you're saying that the formatting of the text would change > between disk and buffer. This is an acceptable hack and seems to be the > most promising (most easily implementable) way to go about this. > Because I'd use paragraph-indent-mode after the file's first ~30 words, > format-alist shouldn't have a difficult time understanding what the file > is supposed to be. Yes, I'm afraid that this hack is the best we can do. > = In order to see double newlines, I would if it might work to use > = something similar to font-lock to place overlays on every newline with > = a before-string or after-string property containing one or two > = newlines. I never tried, so I don't know if it works. > > I've used font-lock, but never poked around in the code for it. Doing > that for this sort of file format would get pretty tricky-- at least for > an elisp neophyte like myself. But it sounds-- on the face of it-- like > it would address the issue at the level of coding where it should be > addressed-- at least insofar as emacs can address it. Yes, indeed. Hm. Maybe the dbl-space idea is more workable. > = Hm. I guess it would be really difficult to change Emacs in such a > = way that M-q and friends and auto-fill do what you want for > = double-spaced files. > > I've done enough C to say that writing the code to do the work of > fill-region in double-line-spacing wouldn't be too hard at all. > Unfortunately, the C code for such a function would be worthless for > emacs (yes?). Getting the double-line-spaced text to snake down and up > the page as editing added and deleted text would involve essentially the > same code, but invoked after every text-insertion and -deletion. Still > not a huge mountain to climb-- but still useless to emacs if done in C > (or so I'm guessing). Hm, let's see now. I wonder how filling really works. Ah. It seems that filling first removes all newlines, then adds new newlines. So I guess that calling fill-region-as-paragraph on a double-spaced region will properly fill it. Let's see now... Yeah, it works! So now you just need to tell filling to insert two newlines instead of one. Filling uses the function fill-newline to insert a newline. That function does a lot of stuff. Inserting a newline character is only a small part of it. But you could write a function that does like fill-newline does except that it inserts two newlines. Then you tell filling to use your function: (defun gebser-fill-newline () ...like fill-newline but with two newlines...) Now we need to tell filling to use this function instead of the normal fill-newline: (defun gebser-fill-region-as-paragraph (beg end) (interactive "r") (require 'cl) (flet ((fill-newline () (gebser-fill-newline))) (fill-region-as-paragraph (beg end)))) Now mark a region that corresponds to a paragraph (with double spaces in the middle). Now invoke filling with M-x gebser-fill-region-as-paragraph RET. Does it work up to here? I haven't tested it. > = Hm. Isn't there a way to tweak the distance between baselines in > = Emacs? That would enable people to have the look of double-space > = without actually having two consecutive newlines in the buffer. Then > = format-alist could add the newlines to the files. > > Poking around in the code, I found a variable for this, called > dbl-space, But this is a non-solution. That's not true. It's not a *complete* solution, I admit. But it could be part of a complete solution. So I don't see it as so bad. > Simply having the text look like it's double-line-spaced would be of > no use. Once completed, the manuscript file would either be printed > and snail-mailed or directly emailed to an editor (the human kind). > This ultimate destination is where the formatting actually matters. > And in either case, the line spacing would be lost in the > transition. My impression was that you prefer to see double spacing on screen, and also that the files are double spaced. So my idea was this: Use format-alist to double the newlines on the way from the buffer to the file, and also use dbl-space to make the single newlines in the buffer look like double newlines. This way, the files have the right contents, and the buffer looks right. That seemed to be what you wanted. Only the internal buffer representation isn't what you want -- but who cares... > Thanks much for your reply and suggestions. I hope that, despite the > difficulties, it's still possible to make something come of all this. Difficulties? Don't be so negative. Problems are fascinating things; let them inspire you ;-) But I guess you're not looking for the intellectual challenge in this; you're just trying to get a job done. I understand that this produces a different point of view. Kai