Re: [NEWBIE] Questions

[Kai Großjohann]

Robert Pollard <rpollard@apple.com> writes:

> On Saturday, April 12, 2003, at 02:26 PM, Kai Großjohann wrote:
>
>> Robert Pollard <rpollard@apple.com> writes:
>>
>> The two spaces after the "1." come from the fact that Emacs thinks
>> it's a sentence-end period and hence it makes two spaces.  Emacs
>> always assumes two spaces after a sentence, when you do M-q.
>
> Are there variables that allow you to indicate what pattern an end of
> sentence should follow?  It seems this pattern isn't specific enough.
> If I indicate that a sentence usually isn't started with a number and
> a period on a new line then that should be enough to get it to do this
> only when it is a valid sentence, correct?

No, there is only something that matches an end of sentence.  See the
variables sentence-end, sentence-end-double-space, and
sentence-end-without-period.

With some care, you might be able to craft a regular expression that
matches period followed by two spaces only if something other than
digits precede the perdiod.  Hm.

Maybe you could set sentence-end to something like this:
"^.*[^0-9].*\\.  +"

The idea is to anchor it at beginning of line, then make sure that a
non-digit follows somewhere, and then the period, followed by two
spaces.

Not sure if that kind of plan will work.

>>> I much prefer a carriage return to indicate the end of the
>>> paragraph.  As it stands, you have to have a blank line between
>>> paragraphs to indicate the end of the paragraph.
>>
>> I don't understand this.  Emacs almost never uses carriage return
>> (^M) in a buffer.  And even inside a paragraph, every line ends with
>> a newline.
>>
>> There is longlines.el which can remove "superfluous" newlines
>> (within paragraphs) when writing the file and it re-adds them when
>> reading the file.
>
> Using "carriage return" was word processor speak.  I actually didn't
> know what Emacs uses for end of line/paragraph when you hit the return
> key.  Since looking at paragraph-start and paragraph-separate I come
> to the conclusion that it is looking for a line feed "\f" for
> paragraph-separate and a carriage return and line feed "\n\f" for
> paragraph-start.  Is this correct?  If not what does \n and \f mean?

For paragraph-separate, I see this in the source code: "[ \t\f]*$"
It means zero or more whitespace chars, then end of line.
Ie, a line that is empty or blank.

A whitespace char is space ( ), or tab (\t), or form-feed (\f).

Carriage return is \r.

paragraph-start has this default value: "\f\\|[ \t]*$"
It means a formfeed character, or an empty line, or a line consisting
of horizontal whitespace (space and tab) only.

The formfeed character does not have to be at the end of the line.

>>> It appears there may be some kind of continuation pattern being used
>>> for each variable.  I do understand basic regular expressions but I
>>> don't fully understand these patterns.
>>
>> Continuation pattern?
>
> The info docs said something about changing both variables if you
> change one.  I assumed this meant that both variable definitions
> together consisted of what makes up the end of a paragraph?  Is this
> not correct?

No, the relationship is not that simple.  paragraph-separate matches
lines that are between two paragraphs.

But sometimes, there is no line that is *between* two paragraphs,
because line number 9 is the last line of a paragraph and line number
10 is the first line of the next paragraph.  (There is no line number
nine-and-three-quarters in this world :-)

Therefore, paragraph-start should match everything that
paragraph-separate matches, plus those lines that start a paragraph
even though there might be no line between two paragraphs.

Does this make sense?

(I'm sure you can play all kinds of funny games by choosing strange
values for these variables.  I don't know what happens when the sets
of lines matched by the variables are disjoint, for instance.)
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)