From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kai.grossjohann@gmx.net (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.help Subject: Re: [NEWBIE] Questions Date: Mon, 14 Apr 2003 20:47:21 +0200 Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <84u1d0x6fa.fsf@lucy.is.informatik.uni-duisburg.de> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1050346343 32511 80.91.224.249 (14 Apr 2003 18:52:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 14 Apr 2003 18:52:23 +0000 (UTC) Cc: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Mon Apr 14 20:52:19 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 195934-0008M2-00 for ; Mon, 14 Apr 2003 20:51:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19592k-0007fa-00 for gnu-help-gnu-emacs@m.gmane.org; Mon, 14 Apr 2003 14:51:02 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 195921-0007R2-00 for help-gnu-emacs@gnu.org; Mon, 14 Apr 2003 14:50:17 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19591m-0007Mw-00 for help-gnu-emacs@gnu.org; Mon, 14 Apr 2003 14:50:04 -0400 Original-Received: from mailout02.sul.t-online.com ([194.25.134.17]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19591V-00075M-00 for help-gnu-emacs@gnu.org; Mon, 14 Apr 2003 14:49:45 -0400 Original-Received: from fwd09.sul.t-online.de by mailout02.sul.t-online.com with smtp id 19591P-00051C-05; Mon, 14 Apr 2003 20:49:39 +0200 Original-Received: from lucy (520080024987-0001@[217.81.246.91]) by fmrl09.sul.t-online.com with esmtp id 19591G-2HfUCOC; Mon, 14 Apr 2003 20:49:30 +0200 Original-Received: by lucy (Postfix, from userid 1003) id EA17F2891A; Mon, 14 Apr 2003 20:47:21 +0200 (CEST) Original-To: Robert Pollard In-Reply-To: (Robert Pollard's message of "Mon, 14 Apr 2003 11:19:27 -0700") User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) X-Sender: 520080024987-0001@t-dialin.net X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:8469 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:8469 Robert Pollard writes: > On Saturday, April 12, 2003, at 02:26 PM, Kai Gro=DFjohann wrote: > >> Robert Pollard 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.) --=20 file-error; Data: (Opening input file no such file or directory ~/.signatur= e)