Re: Mode for Manuscripts?

[gebser]

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