Re: Mode for Manuscripts?

[Kai Grossjohann]

gebser@speakeasy.net writes:

> 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?

Yep.  That's how I read it, too.

> 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?

Yes, BUFFER would be the buffer you're trying to save.  But please
don't write code depending on BUFFER being equal to (current-buffer).
Just do (set-buffer BUFFER) and then that buffer will be current.

BEGIN and END are two buffer positions, normally the beginning and the
end of the buffer.  But people can use M-x write-region RET which I
guess would also invoke the function.  In that case, BEGIN and END
will specify the beginning and the end of the region to be written.

> And the specified conversion will occur each time the buffer is written 
> to disk?

In principle, yes.  But I don't quite remember what it takes so that
format-alist is used at all.  Also Emacs uses the given REGEXP to
decide whether to use the entry.

I think that in longlines.el I required users to say M-x
format-find-file RET, specifying the right format-alist entry.

> 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?

Hm.  format-find-file is for reading...  C-h f format TAB TAB...  Ah!
format-encode-buffer looks promising, and indeed C-h f tells me that
it should do what you need.

I wonder if there is a method to say "use this format for saving the
buffer, when C-x C-s is used".

> 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?)

Ah.  In allout.el.  Then surely it's not a general facility.  I
thought you had discovered a general Emacs feature that existed since
Emacs 17 or so, and that I somehow missed.  (The variable name somehow
looks weird -- either an old-fashioned feature or a local variable,
but modern "user-visible" variables wouldn't use abbreviations like
this.)

>From a superficial skimming of the given source, it seems that
allout.el uses the variable to signify whether two spaces are used
after an end of sentence period.

> 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.

I guess you can't use that variable at all.

> 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.

I was hoping someone else would pitch in with the missing bits ;-)
Also it's more fun to have the other try little bits, that way I can
avoid the debugging and off-load that task to you ;-)

> = 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.

Having the buffer appear double-spaced would only be useful in
conjunction with the format-alist idea.

> 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.

Okay, so using the format-alist trick would also be fine, right?

> 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.

Okay, let's tackle the format-alist thing.

(defun gebser-doublespace-format-decode-region (b e)
  (save-excursion
    ;; need to convert e into a marker so that it moves
    ;; with buffer changes
    (goto-char e)
    (setq e (point-marker))
    ;; now convert the region
    (goto-char b)
    (while (and (not (eobp)) (< (point) (marker-position e)))
      (forward-line 1)
      (delete-char 1))
    ;; return new end
    (marker-position e)))

(defun gebser-doublespace-format-encode-region (b e buf)
  (save-excursion
    (copy-to-buffer buf b e)
    (set-buffer buf)
    ;; same marker trick as above
    (goto-char e)
    (setq e (point-marker))
    ;; now convert the region
    (goto-char b)
    (while (and (not (eobp)) (< (point) (marker-position e)))
      (end-of-line)
      (newline)
      (forward-char 1))
    ;; return new end
    (marker-position e)))

(add-to-list 'format-alist
             '(doublespace
               "Double spaced text files."
               nil              ; not sure about regexp yet
               gebser-doublespace-format-decode-region
               gebser-doublespace-format-encode-region
               t                ; want to modify the buffer
               nil))

I think you need to do M-x format-find-file RET to read double-spaced
files.  I guess that C-x C-s will do the right thing for saving.

What does the above do?

Hm.

Let me test it...  No, it doesn't work.  It changes the current buffer
on save, instead of changing the file on disk.  :-(

Kai