Re: Mode for Manuscripts?

[Kai Grossjohann]

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