Re: upgrade nonsensifies fill-paragraph

Re: upgrade nonsensifies fill-paragraph

[B. T. Raven]

Die Tue Dec 25 2012 12:15:10 GMT-0600 (Central Standard Time) ken
<gebser@mousecar.com> scripsit:

> For quite a while I've been using the highest upgrade of emacs available
> to RH/Centos 5.8, i.e., 21.4.  But because I wanted to start using
> webdav functionality in emacs, I scrapped that and downloaded and
> compiled version 22.1.1.  With this upgrade came problems (some of which
> I've encountered and had to fix in previous upgrades).  One of these is
> what "fill-paragraph" does.
> 
> I'll have a nicely formatted html unordered list, something like this:
> 
> <ul>
>   <li>This is a longer line of text for a single list
>   item.  We're going to use it to test to see how
>   well
>   word-wrapping works with this new version of emacs (22.1.1).  It's
>   always a real pain to reformat list items so that they look nice.
>  </li>
>  <li>Another line of text is no problem just typing it in without
>   editing anything which affects where the line-breaks are located.
>   Everything is happy so far.
>  </li>
>  <li>Now a third line.  After typing in this, I'll move the point up to
>   the first list item and try to reformat it with <kbd>M-q</kbd>.
>  </li>
> </ul>
> 
> Fairy readable, but I want to improve the first list item's formatting,
> so I put the point between the first "<li>" and its matching "</li>" and
> to M-q.  I get this:
> 
> <ul> <li>This is a longer line of text for a single list item.  We're
>   going to use it to test to see how well word-wrapping works with this
>   new version of emacs (22.1.1).  It's always a real pain to reformat
>   list items so that they look nice.  </li> <li>Another line of text is
>   no problem just typing it in without editing anything which affects
>   where the line-breaks are located.  Everything is happy so far.  </li>
>   <li>Now a third line.  After typing in this, I'll move the point up to
>   the first list item and try to reformat it with <kbd>M-q</kbd>.  </li>
>   </ul>
> 
> which is of course *much worse*.  And not how the previous version
> behaved (with exactly the same ~/.emacs).
> 
> The problem, I believe, has to do with emacs' definition of what
> signifies the end of a paragraph.  But I couldn't find any such
> definition.  Any help?

Things like this are found with C-h v parag TAB
Look at paragraph-start and paragraph-separate.
 <\/.+> is a regexp that is the pattern for tags like </li> vel sim.
Maybe that could be added to one or both of those variables in html-mode
or html-helper-mode but I don't know what repercussions that might have.

Ed

> 
> 
> 
> 
> 

Re: upgrade nonsensifies fill-paragraph

[ken]

On 12/28/2012 06:42 PM B. T. Raven wrote:
> Die Tue Dec 25 2012 12:15:10 GMT-0600 (Central Standard Time) ken
> <gebser@mousecar.com>  scripsit:
>
>> For quite a while I've been using the highest upgrade of emacs available
>> to RH/Centos 5.8, i.e., 21.4.  But because I wanted to start using
>> webdav functionality in emacs, I scrapped that and downloaded and
>> compiled version 22.1.1.  With this upgrade came problems (some of which
>> I've encountered and had to fix in previous upgrades).  One of these is
>> what "fill-paragraph" does.
>>
>> I'll have a nicely formatted html unordered list, something like this:
>>
>> <ul>
>>    <li>This is a longer line of text for a single list
>>    item.  We're going to use it to test to see how
>>    well
>>    word-wrapping works with this new version of emacs (22.1.1).  It's
>>    always a real pain to reformat list items so that they look nice.
>>   </li>
>>   <li>Another line of text is no problem just typing it in without
>>    editing anything which affects where the line-breaks are located.
>>    Everything is happy so far.
>>   </li>
>>   <li>Now a third line.  After typing in this, I'll move the point up to
>>    the first list item and try to reformat it with<kbd>M-q</kbd>.
>>   </li>
>> </ul>
>>
>> Fairy readable, but I want to improve the first list item's formatting,
>> so I put the point between the first "<li>" and its matching"</li>" and
>> to M-q.  I get this:
>>
>> <ul>  <li>This is a longer line of text for a single list item.  We're
>>    going to use it to test to see how well word-wrapping works with this
>>    new version of emacs (22.1.1).  It's always a real pain to reformat
>>    list items so that they look nice.</li>  <li>Another line of text is
>>    no problem just typing it in without editing anything which affects
>>    where the line-breaks are located.  Everything is happy so far.</li>
>>    <li>Now a third line.  After typing in this, I'll move the point up to
>>    the first list item and try to reformat it with<kbd>M-q</kbd>.</li>
>>    </ul>
>>
>> which is of course *much worse*.  And not how the previous version
>> behaved (with exactly the same ~/.emacs).
>>
>> The problem, I believe, has to do with emacs' definition of what
>> signifies the end of a paragraph.  But I couldn't find any such
>> definition.  Any help?
>
> Things like this are found with C-h v parag TAB
> Look at paragraph-start and paragraph-separate.
>   <\/.+>  is a regexp that is the pattern for tags like</li>  vel sim.
> Maybe that could be added to one or both of those variables in html-mode
> or html-helper-mode but I don't know what repercussions that might have.
>
> Ed

Thanks much, Ed.  That help search worked.  Yeah, I remember now that 
years ago I had to play around with paragraph-separate for days because 
it affected paragraph-start, so I had to fiddle with that too.  There 
might have been a third variable I had to re-define as well.  It was a 
long time ago.

I don't understand, though, why all that worked fine in my previous 
version but after the upgrade and with the same ~/.emacs it's broke. 
:^\  Weird.

Re: upgrade nonsensifies fill-paragraph

[Jason Rumney]

On Wednesday, 26 December 2012 02:15:10 UTC+8, ken  wrote:

> The problem, I believe, has to do with emacs' definition of what 
> signifies the end of a paragraph.  But I couldn't find any such 
> definition.  Any help?

What is the major mode for the buffer? Is it the same as in Emacs 21.4 previously, or different?

Re: upgrade nonsensifies fill-paragraph

[ken]

On 12/31/2012 02:07 AM Jason Rumney wrote:
> On Wednesday, 26 December 2012 02:15:10 UTC+8, ken  wrote:
>
>> The problem, I believe, has to do with emacs' definition of what
>> signifies the end of a paragraph.  But I couldn't find any such
>> definition.  Any help?
>
> What is the major mode for the buffer? Is it the same as in Emacs
> 21.4 previously, or different?

You ask a good question.  Yes, it's the same and it's called 
html-helper-mode.  In both versions I loaded/visited html files/buffers 
which then became subject to this hook in my ~/.emacs:

(autoload 'html-helper-mode "html-helper-mode" "Yay HTML" t)

Current version is: GNU Emacs 22.1.1 (i686-pc-linux-gnu, X toolkit, 
Xaw3d scroll bars) of 2012-12-14.

I thought that perhaps in this newer version there was some minor mode 
loaded by default (automatically, without my intention) which caused the 
change of behavior.

Output from "C-h m" for current emacs version (redacted for brevity):

---------------------------------------------------------------

Enabled minor modes:  Abbrev Auto-Compression Auto-Fill Blink-Cursor
Delete-Selection Desktop-Save Encoded-Kbd File-Name-Shadow Font-Lock
Global-Font-Lock Line-Number Menu-Bar Mouse-Wheel Pc-Selection
Shell-Dirtrack Show-Paren Tool-Bar Tooltip Unify-8859-On-Encoding
Utf-Translate-Cjk

(Information about these minor modes follows the major mode info.)

HTML helper mode:
Mode for editing HTML documents.

The main function html-helper-mode provides is a menu and keybindings
for the HTML tags one inserts when writing HTML documents. Selecting
the menu item or typing the key sequence for a command inserts the
corresponding tag and places point in the right place. If a prefix
argument is supplied, the tags is instead wrapped around the region.
Alternately, one can type in part of the tag and complete it with M-TAB.

There is also code for indentation, timestamps, skeletons for new
documents, and lots of other neat features.

Uses :`visual-basic-mode' (optional - see below ) for ASP and VBScript
       `easymenu' for menu creation
       `cc-mode'  for javascript support
       `tempo'    for templates

Supports server (actually ASP & PHP, JSP) and client
(JavaScript, VBScript) scripting

Customizable flags you would like to alter

`html-helper-mode-uses-visual-basic' : non nil requires 
visual-basic-mode and activates ASP and VBScript support functions
`html-helper-mode-uses-bold-italic' : non nil creates a bold italic face 
(could fail if there's not such face available)
`html-helper-mode-uses-KG-style' : nil to make Emacs consider 
PHP/JSP/ASP code blocks beginning in the first colum
`html-helper-mode-global-JSP-not-ASP' : non nil to make Emacs consider 
<% %> sequence as JSP blocks by default in html-helper-mode, set to nil 
in asp-html-helper-mode, set to t in jsp-html-helper-mode.
Alter the behaviour locally by changing 
html-helper-mode-local-JSP-not-ASP value

Special command (not in menu - default bound to [f4]): attempts a smart 
narrowing to the current scripting block. Fails in client script 
containing server script sections.
key             binding
---             -------

C-c		Prefix Command
TAB		html-helper-indent-command
RET		newline-and-indent
ESC		Prefix Command
<f4>		html-script-toggle-narrow

....

Written by nelson@santafe.edu, http://www.santafe.edu/~nelson/
Mantained by lauri@eng.it, http:/www.gest.unipd.it/~saint/

\f
Abbrev minor mode (indicator Abbrev):
Toggle Abbrev mode in the current buffer.
With argument ARG, turn abbrev mode on iff ARG is positive.
In Abbrev mode, inserting an abbreviation causes it to expand
and be replaced by its expansion.
\f
Auto-Compression minor mode (no indicator):
Toggle automatic file compression and uncompression.
With prefix argument ARG, turn auto compression on if positive, else off.
Return the new status of auto compression (non-nil means on).
\f
Auto-Fill minor mode (indicator Fill):
Toggle Auto Fill mode.
With arg, turn Auto Fill mode on if and only if arg is positive.
In Auto Fill mode, inserting a space at a column beyond 
`current-fill-column'
automatically breaks the line at a previous space.

The value of `normal-auto-fill-function' specifies the function to use
for `auto-fill-function' when turning Auto Fill mode on.
\f
....
\f
---------------------------------------------------------------

upgrade nonsensifies fill-paragraph

[ken]

For quite a while I've been using the highest upgrade of emacs available 
to RH/Centos 5.8, i.e., 21.4.  But because I wanted to start using 
webdav functionality in emacs, I scrapped that and downloaded and 
compiled version 22.1.1.  With this upgrade came problems (some of which 
I've encountered and had to fix in previous upgrades).  One of these is 
what "fill-paragraph" does.

I'll have a nicely formatted html unordered list, something like this:

<ul>
   <li>This is a longer line of text for a single list
   item.  We're going to use it to test to see how
   well
   word-wrapping works with this new version of emacs (22.1.1).  It's
   always a real pain to reformat list items so that they look nice.
  </li>
  <li>Another line of text is no problem just typing it in without
   editing anything which affects where the line-breaks are located.
   Everything is happy so far.
  </li>
  <li>Now a third line.  After typing in this, I'll move the point up to
   the first list item and try to reformat it with <kbd>M-q</kbd>.
  </li>
</ul>

Fairy readable, but I want to improve the first list item's formatting, 
so I put the point between the first "<li>" and its matching "</li>" and 
to M-q.  I get this:

<ul> <li>This is a longer line of text for a single list item.  We're
   going to use it to test to see how well word-wrapping works with this
   new version of emacs (22.1.1).  It's always a real pain to reformat
   list items so that they look nice.  </li> <li>Another line of text is
   no problem just typing it in without editing anything which affects
   where the line-breaks are located.  Everything is happy so far.  </li>
   <li>Now a third line.  After typing in this, I'll move the point up to
   the first list item and try to reformat it with <kbd>M-q</kbd>.  </li>
   </ul>

which is of course *much worse*.  And not how the previous version 
behaved (with exactly the same ~/.emacs).

The problem, I believe, has to do with emacs' definition of what 
signifies the end of a paragraph.  But I couldn't find any such 
definition.  Any help?