Bug#507354: emacs21-common: fill-paragraph stops working
On Mon, Mar 16, 2009 at 02:16:49PM +0100, Sven Joachim wrote: Doing this anyway has the advantage that you can distinguish between sentence ends and abbreviations, which would otherwise be impossible. This is important for the various commands that operate on sentences. Taking into account that this is documented in the GNU Coding Standards and Emacs is the standard editor of the GNU project, I don't expect the default behavior to be changed any time soon, if ever. Can you provide an example where it would be important? Having a hard time understanding the use case, but I'm probably just being thick. Thanks, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507354: emacs21-common: fill-paragraph stops working
On 2009-03-14 18:17 +0100, Noah Slater wrote: On Tue, Feb 03, 2009 at 09:50:46PM +0100, Sven Joachim wrote: Does fill-region still work in these situations? It might be possible that some broken package sets fill-paragraph-function to an unsuitable value (see the docstring for fill-paragraph-function). Nope, fill-region still exhibits the same behaviour. Here is a block of text that will reproduce this strange behaviour: aa aaa aa aa a aa a a aa b. aaa aa aa aa aa a aaa, a aaa aa aaa aaa aaa a aaa a aa aaa aaa . aaa a aaa. If you do fill-paragraph on that text, the word b is not moved to the first line like it should be. This is actually correct, because if it were moved to the first line it would change the semantics of the text: the sentence would end with the b., while it does not in the original. That's because by default a dot only ends a sentence if followed by a newline or _two_ spaces, see the user option sentence-end-double-space: , | sentence-end-double-space is a variable defined in `paragraphs.el'. | Its value is t | | This variable is safe as a file local variable if its value | satisfies the predicate `booleanp'. | | Documentation: | Non-nil means a single space does not end a sentence. | This is relevant for filling. See also `sentence-end-without-period' | and `colon-double-space'. ` If you set sentence-end-double-space to nil, then the b. is moved to the first line, since the sentence ends after it in the original text. If you remove the line break before this word so that you have a long line, you will get: aa aaa aa aa a aa a a aa b. aaa aa aa aa aa a aaa, a aaa aa aaa aaa aaa a aaa a aa aaa aaa . aaa a aaa. If you do fill-paragraph on this block of text, it will return it to the original example, which is in error. Yet, and this is most peculiar, if you add the line break after the word b, and then do fill paragraph, it will correctly leave it alone. Yes, because by adding the line break you are telling Emacs that the sentence ends here. Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507354: emacs21-common: fill-paragraph stops working
On Mon, Mar 16, 2009 at 09:18:00AM +0100, Sven Joachim wrote: This is actually correct, because if it were moved to the first line it would change the semantics of the text: the sentence would end with the b., while it does not in the original. That's because by default a dot only ends a sentence if followed by a newline or _two_ spaces, see the user option sentence-end-double-space: This is extremely counter-intuitive, but thanks for the explanation. Using two spaces for sentence termination was originally a workaround for mechanical typewriters, because they could not properly adjust the spacing between words and punctuation. I do not think that GNU Emacs should be promoting the useless continuation of this outdated practice. Moreover, it seems to me like GNU Emacs is in error with its application of this rule. The double space after a terminating full stop was to fake the spacing that would normally have been present before the start of the next sentence. There is no reason why this would have been required when the full stop sits at the end of a line. Why GNU Emacs would enforce that a full stop be followed by two spaces at the end of a line is totally beyond me. If you set sentence-end-double-space to nil, then the b. is moved to the first line, since the sentence ends after it in the original text. Thanks, this worked. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507354: emacs21-common: fill-paragraph stops working
On 2009-03-16 13:19 +0100, Noah Slater wrote: On Mon, Mar 16, 2009 at 09:18:00AM +0100, Sven Joachim wrote: This is actually correct, because if it were moved to the first line it would change the semantics of the text: the sentence would end with the b., while it does not in the original. That's because by default a dot only ends a sentence if followed by a newline or _two_ spaces, see the user option sentence-end-double-space: This is extremely counter-intuitive, but thanks for the explanation. Using two spaces for sentence termination was originally a workaround for mechanical typewriters, because they could not properly adjust the spacing between words and punctuation. I do not think that GNU Emacs should be promoting the useless continuation of this outdated practice. Doing this anyway has the advantage that you can distinguish between sentence ends and abbreviations, which would otherwise be impossible. This is important for the various commands that operate on sentences. Taking into account that this is documented in the GNU Coding Standards and Emacs is the standard editor of the GNU project, I don't expect the default behavior to be changed any time soon, if ever. Moreover, it seems to me like GNU Emacs is in error with its application of this rule. The double space after a terminating full stop was to fake the spacing that would normally have been present before the start of the next sentence. There is no reason why this would have been required when the full stop sits at the end of a line. Why GNU Emacs would enforce that a full stop be followed by two spaces at the end of a line is totally beyond me. It does not do that, where did you get that impression? If you insert a newline after a period, Emacs will treat that period as a sentence end. If you set sentence-end-double-space to nil, then the b. is moved to the first line, since the sentence ends after it in the original text. Thanks, this worked. Only remember to use two spaces at the end of sentences if you ever contribute to GNU. :-) Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507354: emacs21-common: fill-paragraph stops working
On Tue, Feb 03, 2009 at 09:50:46PM +0100, Sven Joachim wrote: Does fill-region still work in these situations? It might be possible that some broken package sets fill-paragraph-function to an unsuitable value (see the docstring for fill-paragraph-function). Nope, fill-region still exhibits the same behaviour. Here is a block of text that will reproduce this strange behaviour: aa aaa aa aa a aa a a aa b. aaa aa aa aa aa a aaa, a aaa aa aaa aaa aaa a aaa a aa aaa aaa . aaa a aaa. If you do fill-paragraph on that text, the word b is not moved to the first line like it should be. If you remove the line break before this word so that you have a long line, you will get: aa aaa aa aa a aa a a aa b. aaa aa aa aa aa a aaa, a aaa aa aaa aaa aaa a aaa a aa aaa aaa . aaa a aaa. If you do fill-paragraph on this block of text, it will return it to the original example, which is in error. Yet, and this is most peculiar, if you add the line break after the word b, and then do fill paragraph, it will correctly leave it alone. aa aaa aa aa a aa a a aa b. aaa aa aa aa aa a aaa, a aaa aa aaa aaa aaa a aaa a aa aaa aaa . aaa a aaa. Each of these examples uses: (custom-set-variables '(fill-column 80)) Thanks, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507354: emacs21-common: fill-paragraph stops working
On 2009-02-02 15:08 +0100, Noah Slater wrote: I installed emacs22-common and the problem persists. Any clue about how to debug this? It happens quite frequently, so any advice or instructions you have should be easy to run. Does fill-region still work in these situations? It might be possible that some broken package sets fill-paragraph-function to an unsuitable value (see the docstring for fill-paragraph-function). Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507354: emacs21-common: fill-paragraph stops working
I installed emacs22-common and the problem persists. Any clue about how to debug this? It happens quite frequently, so any advice or instructions you have should be easy to run. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507354: emacs21-common: fill-paragraph stops working randomly
Package: emacs21-common Version: 21.4a+1-5.6 Severity: normal Occasionally when editing a file, `fill-paragraph' will stop working on a certain section of the document. That is, a section which would be reformatted if I copied and pasted it into another emacs buffer will refuse to change when running this command. I do not how to reproduce as it only happens seemingly random. The paragraph that fill.el is refusing to operate on at the moment is: We need to consider the serialisation on its own merit and I would like to understand what JSON would buy us over a very simple textual serialisation as I proposed in my first email, like: If there is something I can run, some debug command, I am happy to run it the next time this happens to me. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23.1-bytemark-uml Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages emacs21-common depends on: ii dpkg 1.14.22Debian package management system ii emacsen-common1.4.17 Common facilities for all emacsen emacs21-common recommends no packages. Versions of packages emacs21-common suggests: pn emacs21-common-non-dfsg none (no description available) pn emacs21-elnone (no description available) -- no debconf information -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507354: emacs21-common: fill-paragraph stops working randomly
On 2008-11-30 13:58 +0100, Noah Slater wrote: Package: emacs21-common Version: 21.4a+1-5.6 Severity: normal Occasionally when editing a file, `fill-paragraph' will stop working on a certain section of the document. That is, a section which would be reformatted if I copied and pasted it into another emacs buffer will refuse to change when running this command. I do not how to reproduce as it only happens seemingly random. The paragraph that fill.el is refusing to operate on at the moment is: We need to consider the serialisation on its own merit and I would like to understand what JSON would buy us over a very simple textual serialisation as I proposed in my first email, like: If there is something I can run, some debug command, I am happy to run it the next time this happens to me. Since you are using testing, the best thing to do is try to reproduce it with the emacs22 packages. Emacs 21 is obsolete, non-security bugs will most likely not be fixed any more. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507354: emacs21-common: fill-paragraph stops working randomly
Thanks, I will install and test. If it reoccures, I will report back. On Sun, Nov 30, 2008 at 09:46:35PM +0100, Sven Joachim wrote: On 2008-11-30 13:58 +0100, Noah Slater wrote: Package: emacs21-common Version: 21.4a+1-5.6 Severity: normal Occasionally when editing a file, `fill-paragraph' will stop working on a certain section of the document. That is, a section which would be reformatted if I copied and pasted it into another emacs buffer will refuse to change when running this command. I do not how to reproduce as it only happens seemingly random. The paragraph that fill.el is refusing to operate on at the moment is: We need to consider the serialisation on its own merit and I would like to understand what JSON would buy us over a very simple textual serialisation as I proposed in my first email, like: If there is something I can run, some debug command, I am happy to run it the next time this happens to me. Since you are using testing, the best thing to do is try to reproduce it with the emacs22 packages. Emacs 21 is obsolete, non-security bugs will most likely not be fixed any more. Sven -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
