Re: Mode for Manuscripts?

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

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

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

Re: Mode for Manuscripts?

[Dan Anderson]

gebser@speakeasy.net writes:

        I don't  suppose you  could just write  like normal and  run a
macro against your manuscript?

-Dan

Re: Mode for Manuscripts?

[gebser]

Sure, I could do that.  But I'd like to write it in the way I described. 

ken


At 01:22 (UTC-0000) on Sun, 30 Nov 2003 Dan Anderson said:

= gebser@speakeasy.net writes:
= 
=         I don't  suppose you  could just write  like normal and  run a
= macro against your manuscript?
= 
= -Dan
= _______________________________________________
= Help-gnu-emacs mailing list
= Help-gnu-emacs@gnu.org
= http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
= 

Re: Mode for Manuscripts?

[Eli Zaretskii]

> From: gebser@speakeasy.net
> Newsgroups: gnu.emacs.help
> Date: Sat, 29 Nov 2003 23:11:10 -0500
> 
> Sure, I could do that.  But I'd like to write it in the way I described. 

Does it take anything beyond binding RET to a function that inserts a
newline and then calls newline-and-indent?

Re: Mode for Manuscripts?

[gebser]

At 09:14 (UTC+0200) on 30 Nov 2003 Eli Zaretskii said:

= > From: gebser@speakeasy.net
= > Newsgroups: gnu.emacs.help
= > Date: Sat, 29 Nov 2003 23:11:10 -0500
= > 
= > ...
= 
= Does it take anything beyond binding RET to a function that inserts a
= newline and then calls newline-and-indent?
= 
= ...

Yes, I think it would.  Here's (most of) the original posting of the
question again (and how the text should look in emacs):

...

     Here are the specifications explicitly stated: Text must be

double-spaced. Owing to the need for margins, text should wrap. There 

should be one space, not two, between sentences. Automatic tabs to 

indicate breaks between paragraphs. I think by this they mean a ^I 

character must begin a paragraph. Use regular double spaces between 

paragraphs (as you see here at the beginning and end of paragraphs. Use

only one space, not two spaces, between sentences.

     So does such a mode already exist for emacs? Of course I'd want C-n

and C-p to move the cursor to a text line and not to a blank line in

between text lines. I know that "pr -d" will do the double-spacing for

me after I write up the whole thing, but it would be nicer for emacs to

do the double-spacing for me as I go along. The M-a and M-e keys should

get me to the beginning and end of sentences and M-q should reformat 

stuff I screw up by editing.

     Finally, it would be best to have a separate (minor?) mode for this

sort of format-- this, so I wouldn't have to set and unset a lot of 

variables every time I go in and out of editing in this mode.

...

I found paragraph-indent-text-mode, copied it into .emacs, and modified 
it so:

(defun paragraph-indent-text-mode ()
  "Major mode for editing text, with leading spaces starting a 
paragraph.
In this mode, you do not need blank lines between paragraphs
when the first line of the following paragraph starts with whitespace.
Special commands:
\\{text-mode-map}
Turning on Paragraph-Indent Text mode runs the normal hooks
`text-mode-hook' and `paragraph-indent-text-mode-hook'."
  (interactive)
  (kill-all-local-variables)
  (use-local-map text-mode-map)
  (setq mode-name "Parindent")
  (setq major-mode 'paragraph-indent-text-mode)
  (setq local-abbrev-table text-mode-abbrev-table)
  (setq sentence-end "[.?!][]\"')]*\\($\\|\t\\| \\)[ \t\n]*")
  (setq sentence-end-double-space' nil)
  (setq paragraph-start "\t.+$")
  (setq paragraph-separate "\n\n\t")
  (set-syntax-table text-mode-syntax-table)
  (run-hooks 'text-mode-hook 'paragraph-indent-text-mode-hook))

However, M-a and M-e will go to locations which aren't really the 
begin/end of sentences, where the word following punctuation isn't 
capitalized such as "foo, etc.) bar" where "bar" isn't the begin of a 
new sentence.  Can't we specify that the begin of a sentence should be 
an uppercase character?  How?  (Regexps baffle me sometimes.)

Also my defs for paragraph-start and paragraph-separate don't work;  
ESC-{ and ESC-} move the cursor to the begin and end of the file
respectively.  I'm guessing this is the reason that M-q turns a lot of
(tab-indented) paragraphs into one, big paragraph.  The Info on these
variables demands too much of my pre-mavenistic understanding.

To reply to Eli's question specifically, given that I'm looking for 
double-line spacing ("blank" lines in between text lines), I don't think 
it would be enough to remap RET to RET RET TAB because this would insert 
blank lines only between paragraphs, not between every line of text.  
Can emacs even do double-line spacing at all?


Anyone know how to get at this mode?


tia,
ken

Re: Mode for Manuscripts?

[gebser]

In hopes that a better understanding of this might move things forward a 
little, I've posted a bit more on manuscript-mode to 
<http://www.emacswiki.org/cgi-bin/wiki/WiKen>.


At 12:15 (UTC-0500) on Sun, 30 Nov 2003 gebser@speakeasy.net said:

= At 09:14 (UTC+0200) on 30 Nov 2003 Eli Zaretskii said:
= 
= = > From: gebser@speakeasy.net
= = > Newsgroups: gnu.emacs.help
= = > Date: Sat, 29 Nov 2003 23:11:10 -0500
= = > 
= = > ...
= = 
= = Does it take anything beyond binding RET to a function that inserts a
= = newline and then calls newline-and-indent?
= = 
= = ...
= 
= Yes, I think it would.  Here's (most of) the original posting of the
= question again (and how the text should look in emacs):
= 
= ...
= 
=      Here are the specifications explicitly stated: Text must be
= 
= double-spaced. Owing to the need for margins, text should wrap. There 
= 
= should be one space, not two, between sentences. Automatic tabs to 
= 
= indicate breaks between paragraphs. I think by this they mean a ^I 
= 
= character must begin a paragraph. Use regular double spaces between 
= 
= paragraphs (as you see here at the beginning and end of paragraphs. Use
= 
= only one space, not two spaces, between sentences.
= 
=      So does such a mode already exist for emacs? Of course I'd want C-n
= 
= and C-p to move the cursor to a text line and not to a blank line in
= 
= between text lines. I know that "pr -d" will do the double-spacing for
= 
= me after I write up the whole thing, but it would be nicer for emacs to
= 
= do the double-spacing for me as I go along. The M-a and M-e keys should
= 
= get me to the beginning and end of sentences and M-q should reformat 
= 
= stuff I screw up by editing.
= 
=      Finally, it would be best to have a separate (minor?) mode for this
= 
= sort of format-- this, so I wouldn't have to set and unset a lot of 
= 
= variables every time I go in and out of editing in this mode.
= 
= ...
= 
= I found paragraph-indent-text-mode, copied it into .emacs, and modified 
= it so:
= 
= (defun paragraph-indent-text-mode ()
=   "Major mode for editing text, with leading spaces starting a 
= paragraph.
= In this mode, you do not need blank lines between paragraphs
= when the first line of the following paragraph starts with whitespace.
= Special commands:
= \\{text-mode-map}
= Turning on Paragraph-Indent Text mode runs the normal hooks
= `text-mode-hook' and `paragraph-indent-text-mode-hook'."
=   (interactive)
=   (kill-all-local-variables)
=   (use-local-map text-mode-map)
=   (setq mode-name "Parindent")
=   (setq major-mode 'paragraph-indent-text-mode)
=   (setq local-abbrev-table text-mode-abbrev-table)
=   (setq sentence-end "[.?!][]\"')]*\\($\\|\t\\| \\)[ \t\n]*")
=   (setq sentence-end-double-space' nil)
=   (setq paragraph-start "\t.+$")
=   (setq paragraph-separate "\n\n\t")
=   (set-syntax-table text-mode-syntax-table)
=   (run-hooks 'text-mode-hook 'paragraph-indent-text-mode-hook))
= 
= However, M-a and M-e will go to locations which aren't really the 
= begin/end of sentences, where the word following punctuation isn't 
= capitalized such as "foo, etc.) bar" where "bar" isn't the begin of a 
= new sentence.  Can't we specify that the begin of a sentence should be 
= an uppercase character?  How?  (Regexps baffle me sometimes.)
= 
= Also my defs for paragraph-start and paragraph-separate don't work;  
= ESC-{ and ESC-} move the cursor to the begin and end of the file
= respectively.  I'm guessing this is the reason that M-q turns a lot of
= (tab-indented) paragraphs into one, big paragraph.  The Info on these
= variables demands too much of my pre-mavenistic understanding.
= 
= To reply to Eli's question specifically, given that I'm looking for 
= double-line spacing ("blank" lines in between text lines), I don't think 
= it would be enough to remap RET to RET RET TAB because this would insert 
= blank lines only between paragraphs, not between every line of text.  
= Can emacs even do double-line spacing at all?
= 
= 
= Anyone know how to get at this mode?
= 
= 
= tia,
= ken
= 
= 
= 
= 
= _______________________________________________
= Help-gnu-emacs mailing list
= Help-gnu-emacs@gnu.org
= http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
= 

Re: Mode for Manuscripts?

[giacomo boffi]

Eli Zaretskii <eliz@elta.co.il> writes:

>> From: gebser@speakeasy.net
>> Newsgroups: gnu.emacs.help
>> Date: Sat, 29 Nov 2003 23:11:10 -0500
>> 
>> Sure, I could do that.  But I'd like to write it in the way I described. 
>
> Does it take anything beyond binding RET to a function that inserts a
> newline and then calls newline-and-indent?

  if you like auto-fill'ing, probably yes

-- 
TORPEDOED BY AIRCRAFT 29W 32S. SINKING. U-690.

Re: Mode for Manuscripts?

[Kai Grossjohann]

gebser@speakeasy.net writes:

> Sure, I could do that.  But I'd like to write it in the way I described. 

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.

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.

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.

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.

Kai

Re: Mode for Manuscripts?

[gebser]

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.


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


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


Kai,

Thanks much for your reply and suggestions.  I hope that, despite the
difficulties, it's still possible to make something come of all this.



Regards,
ken

Re: Mode for Manuscripts?

[Stefan Monnier]

>      Yeah, it's a funny way to format text, but it's the format required 
> for manuscript submissions to publishers. Since emacs is such a great 
> editor, perhaps the best on the planet, I'm sure there is a mode already
> constructed for this sort of format you see here in the body of this
> email.

I think it's worth it to follow the lead of LaTeX and other systems that
try to distinguish between the content and the presentation.

I.e. edit the text in whatever format you like (if you like double-spacing
on screen, you can tell Emacs to place more pixels between lines) and then
use something like `pr -d' to "compile" your text into what the
publisher wants.  The conversion between the two formats can be done
when loading/saving the file or at any other time.

If you really want to edit the ascii-double-space version of the document
directly, then I'm afraid you'll have to work harder.


        Stefan

Re: Mode for Manuscripts?

[Rob Thorpe]

I sometimes use Emacs for similar purposes.  What would be useful to
me is a mode where:

* Tabs that just tab rather than whitespacing to the next word on the
line above, which hardly ever makes sense (of course I can do this by
binding tab to M-i)

* Once tab has been used at the start of a line it would be nice if
auto-fill-mode didn't begin at the new indent.  This makes sense for
programming languages but no sense for text.

Personally I deal with things like line spacing later when printing
anything out.

gebser@speakeasy.net wrote in message news:<mailman.794.1070142961.399.help-gnu-emacs@gnu.org>...
> Yeah, it's a funny way to format text, but it's the format required 
> 
> for manuscript submissions to publishers. Since emacs is such a great 
> 
> editor, perhaps the best on the planet, I'm sure there is a mode already
> 
> constructed for this sort of format you see here in the body of this
> 
> email.
> 
>      Here are the specifications explicitly stated: Text must be
> 
> double-spaced. Owing to the need for margins, text should wrap. There 
> 
> should be one space, not two, between sentences. Automatic tabs to 
> 
> indicate breaks between paragraphs. I think by this they mean a ^I 
> 
> character must begin a paragraph. Use regular double spaces between 
> 
> paragraphs (as you see at the beginning of the current paragraph. Use
> 
> only one space, not two spaces, between sentences.
> 
>      So does such a mode already exist for emacs? Of course I'd want C-n
> 
> and C-p to move the cursor to a text line and not to a blank line in
> 
> between text lines. I know that "pr -d" will do the double-spacing for
> 
> me after I write up the whole thing, but it would be nicer for emacs to
> 
> do the double-spacing for me as I go along. The M-a and M-e keys should
> 
> get me to the beginning and end of sentences and M-q should reformat 
> 
> stuff I screw up by editing.
> 
>      Finally, it would be best to have a separate (minor?) mode for this
> 
> sort of format-- this so I would have to set and unset a lot of 
> 
> variables every time I go in and out of editing in this mode.
> 
>      Any help or tips would be very much appreciated.
> 
> 
> 
> ken

Re: Mode for Manuscripts?

[Stefan Monnier]

> * Tabs that just tab rather than whitespacing to the next word on the
> line above, which hardly ever makes sense (of course I can do this by
> binding tab to M-i)

> * Once tab has been used at the start of a line it would be nice if
> auto-fill-mode didn't begin at the new indent.  This makes sense for
> programming languages but no sense for text.

Ever tried M-x paragraph-indent-text-mode ?


        Stefan

Re: Mode for Manuscripts?

[Rob Thorpe]

Stefan Monnier <monnier@iro.umontreal.ca> wrote in message news:<jwvy8ttkeai.fsf-monnier+gnu.emacs.help@vor.iro.umontreal.ca>...
> > * Tabs that just tab rather than whitespacing to the next word on the
> > line above, which hardly ever makes sense (of course I can do this by
> > binding tab to M-i)
>  
> > * Once tab has been used at the start of a line it would be nice if
> > auto-fill-mode didn't begin at the new indent.  This makes sense for
> > programming languages but no sense for text.
> 
> Ever tried M-x paragraph-indent-text-mode ?

Thanks a lot, that's useful.

Is there a way either of these modes can be mixed with outline-mode? 
I normally write points then turn them into paragraphs.

Mode for Manuscripts?

[gebser]

     Yeah, it's a funny way to format text, but it's the format required 

for manuscript submissions to publishers. Since emacs is such a great 

editor, perhaps the best on the planet, I'm sure there is a mode already

constructed for this sort of format you see here in the body of this

email.

     Here are the specifications explicitly stated: Text must be

double-spaced. Owing to the need for margins, text should wrap. There 

should be one space, not two, between sentences. Automatic tabs to 

indicate breaks between paragraphs. I think by this they mean a ^I 

character must begin a paragraph. Use regular double spaces between 

paragraphs (as you see at the beginning of the current paragraph. Use

only one space, not two spaces, between sentences.

     So does such a mode already exist for emacs? Of course I'd want C-n

and C-p to move the cursor to a text line and not to a blank line in

between text lines. I know that "pr -d" will do the double-spacing for

me after I write up the whole thing, but it would be nicer for emacs to

do the double-spacing for me as I go along. The M-a and M-e keys should

get me to the beginning and end of sentences and M-q should reformat 

stuff I screw up by editing.

     Finally, it would be best to have a separate (minor?) mode for this

sort of format-- this so I would have to set and unset a lot of 

variables every time I go in and out of editing in this mode.

     Any help or tips would be very much appreciated.



ken

Re: Mode for Manuscripts?

[Peter S Galbraith]

gebser@speakeasy.net wrote:

>      Yeah, it's a funny way to format text, but it's the format required 
> 
> for manuscript submissions to publishers.

Really?  I use LaTeX for manuscript submissions to publishers.

-- 
Peter S. Galbraith <p.galbraith@globetrotter.net>
GPG key 1024/D2A913A1 - 97CE 866F F579 96EE  6E68 8170 35FF 799E
6623'rd GNU/Linux user at the Counter - http://counter.li.org/

Re: Mode for Manuscripts?

[gebser]

I suppose LaTeX is good if that's what the publishers ask for.  I'm 
afraid that wouldn't do for the people I work with.

Still looking for the emacs solution,
ken


At 20:33 (UTC-0500) on Sat, 29 Nov 2003 Peter S Galbraith said:

= gebser@speakeasy.net wrote:
= 
= >      Yeah, it's a funny way to format text, but it's the format required 
= > 
= > for manuscript submissions to publishers.
= 
= Really?  I use LaTeX for manuscript submissions to publishers.
= 
=