Re: upgrade nonsensifies fill-paragraph

["B. T. Raven" <btraven@nihilo.net>]

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

> 
> 
> 
> 
>