Re: paragraph-start and fill-paragraph in texinfo-mode

[Alan Mackenzie]

Hi, Joseph!

On Mon, 12 Sep 2005, Joseph Kiniry wrote:

>Hi Richard et al,

[ .... ]

>A grep-tree of all paths in my load-path reveals that the only place
>the suspicious subexpression "//+\\|\\**" is used (literally) is
>in cc-vars.el wrt the defcustom of c-comment-prefix-regexp.

>After some debugging, the problem seems to be with
>c-setup-paragraph-style [it's actually c-setup-paragraph-variables] via
>c-add-style [actually, c-set-style].  

This problem was reported by somebody else in late June, and has been
fixed in the CC Mode CVS at Sourceforge.  It didn't seem very urgent then
(it's been in the source since 4004 BC, and there'd only been one
complaint about it), so we didn't immediately amend the source in the
Emacs CVS.  Sorry!  It seems urgent now.  Martin, let's do another
mini-release!

>I define my own programming styles and use c-add-style to add them to
>c-style-alist.  If I set the &optional set-p in the application of
>c-add-style, then c-setup-paragraph-style sets paragraph-start as if
>it were not a buffer local variable.  Thus, all buffers henceforth
>have comment-line-prefix and c-paragraph-start appended to their 
>paragraph-start.

Yes, this is bad, and has been fixed, as noted above.  Personally, I
don't think c-add-style should have this set-p option - Creating a style
and applying a style to a buffer are two entirely different things IMAO.
Joseph, as a user, how would you feel if c-add-style were to lose this
set-p option?

>I find the documentation for dont-override in c-set-style to be obtuse.

It could be better, couldn't it?  Actually, the entire doc-string looks
like it would benefit from a flame-thrower.  ;-)  As for the (CC Mode)
manual, it doesn't even mention DONT-OVERRIDE.  I'm revising the manual
at the moment, so the entry for c-set-style will get fixed in due course.
I'll have a look at that doc string sometime in the next few days, and
send you (Joseph) a patch.

>Regardless of use, the definition of a new c-style should not impact
>buffers in other styles, yet it does, due to the use of
>paragraph-start as a global variable in c-setup-paragraph-style.

Agreed 100%.  It's been fixed, see the patch below.  Again, sorry the fix
didn't reach the Emacs CVS before the bug bugged you. 

>My apologies, but I am not familiar enough with cc-styles to provide a
>quick patch, nor would I trust my patch with such a small data set
>with which to test.  Perhaps the CC Mode maintainers have a position
>on this situation?  I have CCed them on this note.

Which was much appreciated.  Thank you!

Here's that patch from Sourceforge:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Modified Files:
      Tag: Branch_5_30
        cc-styles.el 
Log Message:
c-set-style and c-setup-paragraph-variables: Abort the command if we're
  not in a CC Mode buffer.


Index: cc-styles.el
===================================================================
RCS file: /cvsroot/cc-mode/cc-mode/cc-styles.el,v
retrieving revision 5.149.2.6
retrieving revision 5.149.2.7
diff -C2 -d -r5.149.2.6 -r5.149.2.7
*** cc-styles.el        13 Jun 2005 17:26:54 -0000      5.149.2.6
--- cc-styles.el        24 Jun 2005 19:46:47 -0000      5.149.2.7
***************
*** 357,360 ****
--- 357,362 ----
                               (cons c-indentation-style 0)
                               'c-set-style-history))))))
+   (or c-buffer-is-cc-mode
+       (error "Buffer %s is not a CC Mode buffer (c-set-style)" (buffer-name)))
    (or (stringp stylename)
        (error "Argument to c-set-style was not a string"))
***************
*** 489,493 ****
  
    (interactive)
! 
    (setq c-current-comment-prefix
        (if (listp c-comment-prefix-regexp)
--- 491,497 ----
  
    (interactive)
!   (or c-buffer-is-cc-mode
!       (error "Buffer %s is not a CC Mode buffer (c-setup-paragraph-variables)"
!            (buffer-name)))
    (setq c-current-comment-prefix
        (if (listp c-comment-prefix-regexp)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

>Best,
>Joe

-- 
Alan Mackenzie (Munich, Germany)