Re: problem with esc-q on aquamacs
93 views
Skip to first unread message
David Reitter
Mar 19, 2016, 6:46:57 PM3/19/16
to aquamac...@googlegroups.com
Frank,
On Mar 18, 2016, at 7:54 PM, Frank Ritter <frank....@psu.edu> wrote:
> I am editing the newsletter with aquamacs.
>
> Aquamacs 3.0 GNU Emacs 24.3.50.2
> (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
> of 2014-01-19 (Aquamacs-3.0) on watson
>
> M-Q is not filling cleanly.
>
> Going to fundamental mode fixes the problem. (text spc wordWrap) is
> the mode for the .txt file, and it behaves oddly. M-Q comes back
> with 'fill-prefix cancelled'. I'd suggest that this is not what I
> want, and when we have time you might explain why it is correct,
> because I'm willing to believe that it is....
M-q, in Aquamacs, has a context-dependent function that respects the choice the user made for “word-wrap”. This applies when auto-fill-mode is not enabled, but word-wrap is used so that paragraphs fill the full width of the window, and change if the window is made wider (see Options -> Line Wrapping). In that case, we’re actually “un-filling” the paragraph.
Aquamacs automatically chooses what it thinks is the right formatting. When long lines (without explicit line endings) are present in a file, then word-wrapping as opposed to auto-fill-mode is chosen. Going to fundamental-mode will disable word wrap. In your case, you may or may not want to disable word wrapping anyway.
The reason for this is that Aquamacs is made for an era where people use screens of different sizes, including mobile devices, and display windows next to each other with unpredictable widths. Emacs was conceived when terminals where generally 60 or 80 characters wide so that hard-formatting text made sense. Modern text should not be formatted this way, in my opinion, for maximum responsiveness of the resulting documents. This e-mail should be an example (widen the window to test).
The “prefix cancelled” message refers to Emacs trying to be smart about indentations of paragraphs (e.g., starting with a dash for a bullet point). This message is incomprehensible unless the underlying Emacs function `set-fill-prefix’ is called directly. Thus, future versions of Aquamacs will no longer show that message. Thanks for your comment.
--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and support the Aquamacs Project!
On Mar 18, 2016, at 7:54 PM, Frank Ritter <frank....@psu.edu> wrote:
> I am editing the newsletter with aquamacs.
>
> Aquamacs 3.0 GNU Emacs 24.3.50.2
> (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
> of 2014-01-19 (Aquamacs-3.0) on watson
>
> M-Q is not filling cleanly.
>
> Going to fundamental mode fixes the problem. (text spc wordWrap) is
> the mode for the .txt file, and it behaves oddly. M-Q comes back
> with 'fill-prefix cancelled'. I'd suggest that this is not what I
> want, and when we have time you might explain why it is correct,
> because I'm willing to believe that it is....
M-q, in Aquamacs, has a context-dependent function that respects the choice the user made for “word-wrap”. This applies when auto-fill-mode is not enabled, but word-wrap is used so that paragraphs fill the full width of the window, and change if the window is made wider (see Options -> Line Wrapping). In that case, we’re actually “un-filling” the paragraph.
Aquamacs automatically chooses what it thinks is the right formatting. When long lines (without explicit line endings) are present in a file, then word-wrapping as opposed to auto-fill-mode is chosen. Going to fundamental-mode will disable word wrap. In your case, you may or may not want to disable word wrapping anyway.
The reason for this is that Aquamacs is made for an era where people use screens of different sizes, including mobile devices, and display windows next to each other with unpredictable widths. Emacs was conceived when terminals where generally 60 or 80 characters wide so that hard-formatting text made sense. Modern text should not be formatted this way, in my opinion, for maximum responsiveness of the resulting documents. This e-mail should be an example (widen the window to test).
The “prefix cancelled” message refers to Emacs trying to be smart about indentations of paragraphs (e.g., starting with a dash for a bullet point). This message is incomprehensible unless the underlying Emacs function `set-fill-prefix’ is called directly. Thus, future versions of Aquamacs will no longer show that message. Thanks for your comment.
--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and support the Aquamacs Project!
Robert Goldman
Mar 19, 2016, 7:08:19 PM3/19/16
to aquamacs-devel
I *almost* completely agree with you. For textual documents *that are not used with version control*, soft line breaks are more readable.
But as someone who frequently works with LaTeX documents in subversion or git -- nope! The reason is not revision control per se: the reason is that diff and soft line breaks are not a match made in heaven. So if you are working with a revision control system, you will probably be a lot happier using auto-fill-mode.
Best,
r
David Reitter
Mar 20, 2016, 10:09:59 AM3/20/16
to aquamac...@googlegroups.com
Yes, I have encountered that before.
I see that as a weakness of version control systems that were designed to work with code rather than natural-language text. However, there is no reason to not implement a word-wise merge in version control systems, and it would make more sense, too, rather than going line by line. Line endings are arbitrary except at paragraph boundaries or in poems.
I think one solution to this is to come up with a text format that breaks text into finite clauses (a sentence or partial sentence with a finite verb) and represents them line by line in text file. When loading/saving, Emacs would convert. The display of these files outside of Emacs might be ugly, so that is a drawback one might not be prepared to accept.
I find that I rarely use git to collaboratively edit text files, as co-authors can’t be bothered with a multi-step check-in process when tools such as Dropbox and Overleaf do away with commits.
- David
See also:
https://idnotfound.wordpress.com/2009/05/09/word-by-word-diffs-in-git/
http://stackoverflow.com/questions/14625615/word-wise-git-revisions
> --
> You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.
I see that as a weakness of version control systems that were designed to work with code rather than natural-language text. However, there is no reason to not implement a word-wise merge in version control systems, and it would make more sense, too, rather than going line by line. Line endings are arbitrary except at paragraph boundaries or in poems.
I think one solution to this is to come up with a text format that breaks text into finite clauses (a sentence or partial sentence with a finite verb) and represents them line by line in text file. When loading/saving, Emacs would convert. The display of these files outside of Emacs might be ugly, so that is a drawback one might not be prepared to accept.
I find that I rarely use git to collaboratively edit text files, as co-authors can’t be bothered with a multi-step check-in process when tools such as Dropbox and Overleaf do away with commits.
- David
See also:
https://idnotfound.wordpress.com/2009/05/09/word-by-word-diffs-in-git/
http://stackoverflow.com/questions/14625615/word-wise-git-revisions
> You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages