From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: gebser@speakeasy.net Newsgroups: gmane.emacs.help Subject: Re: Mode for Manuscripts? Date: Mon, 22 Dec 2003 08:36:14 -0500 (EST) Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <87brq6q90o.fsf@emptyhost.emptydomain.de> Reply-To: gebser@speakeasy.net NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1072100419 25054 80.91.224.253 (22 Dec 2003 13:40:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 22 Dec 2003 13:40:19 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Dec 22 14:40:12 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 1AYQI7-0003TW-00 for ; Mon, 22 Dec 2003 14:40:11 +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 1AYRCb-0007et-8b for geh-help-gnu-emacs@m.gmane.org; Mon, 22 Dec 2003 09:38:33 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AYRCL-0007ek-IE for help-gnu-emacs@gnu.org; Mon, 22 Dec 2003 09:38:17 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AYRBp-0007cF-BI for help-gnu-emacs@gnu.org; Mon, 22 Dec 2003 09:38:16 -0500 Original-Received: from [216.254.0.205] (helo=mail5.speakeasy.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AYRBo-0007cC-TP for help-gnu-emacs@gnu.org; Mon, 22 Dec 2003 09:37:44 -0500 Original-Received: (qmail 5019 invoked from network); 22 Dec 2003 13:36:15 -0000 Original-Received: from dsl093-011-017.cle1.dsl.speakeasy.net (HELO heidegger.mousecar.net) ([66.93.11.17]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Dec 2003 13:36:15 -0000 Original-To: help-gnu-emacs@gnu.org In-Reply-To: <87brq6q90o.fsf@emptyhost.emptydomain.de> 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:15503 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:15503 At 18:24 (UTC-0000) on Thu, 18 Dec 2003 Kai Grossjohann said: = 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. Reading the documentation for format-alist, I can see a lot of possibilities. Just to make sure that I'm reading it correctly, the output of the TO-FN argument is what is written to disk, yes? If so, the BUFFER argument to TO-FN would, in this case, be the current buffer, also true? And where do the values for BEGIN and END come from? And the specified conversion will occur each time the buffer is written to disk? Finally, I can understand how, when visiting an encoded file, the buffer will be a converted version of the diskfile. But when a user (like myself) receives a double-spaced file (say, from another person) and reads this unencoded file into a buffer, how does the user tell emacs to use format-alist when writing the buffer to disk? = = > = 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. Reading the code that contains dbl-space, it seems that it is a local variable, one whose scope is limited to outline-open-topic function (in allout.el). (The concepts of "scope" and "local variables" are applicable to elisp, correct?) Incorporating it into a different formatting mode would be helpful, but we'd still need to amend fill and cursor movement functions to be useful and sensible in double-line-spaced text. None of this would be unfeasible, at least not at first look. = = > = 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. Thanks for looking into this. Being quite the novice at lisp, it'll take me some time to write these little snippets of code. But your tips should prove to be quite helpful. = = > = 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: = ... Well, yes and no. Just for my own purposes, having the buffer simply appear that it is double-line-spaced (when it really isn't) would not be desirable. Though true double-spacing would be most preferred, failing that, I could deal with single-spaced text and do other processing outside of emacs to make the text usable. Least preferred would be to have the text appear to be double-spaced when it really isn't. But if workable rewrites can be performed for fill-region, forward-line, sentence-end, other cursor/point movement commands, format-alist, and perhaps a few other functions and variables, then we should have the beginnings of a nice package, maybe even something which will attract others to emacs. Thanks again for lending your experience. ken