Commits

Peter Szilagyi  committed 07f33ff

Fixed a bug in tuareg-compute-indent (M-q) where it indented too far.

  • Participants
  • Parent commits 1962237

Comments (0)

Files changed (1)

File elisp/contrib/tuareg/tuareg.el

        (tuareg-indent-comments
         (let* ((comment-begin (save-excursion
                                 (tuareg-beginning-of-literal-or-comment-fast)))
+               ;; Handle some ocamldoc block syntax.  This provides a
+               ;; way to indent embedded source code and avoid
+               ;; indenting verbatim text.
                block-column
                block-verbatim-p
                block-end-regexp
                (block-begin
                 (save-excursion
-                  ;; The delimiter doesn't necessarily have to be on a
-                  ;; line by itself, but it does need to end the line.
+                  ;; The delimiter needn't be on a line by itself.
+                  ;; However, we do require it to end the line.
                   (when (re-search-backward "[^{]\\({[[v]\\|\\[\\)[ \t]*$"
                                             comment-begin
                                             t)
                                                             (point)))
               ;; CR pszilagyi: An initial blank line in the block will
               ;; effectively reset the indentation column to zero.
+              ;; Maybe that's a feature, or maybe it's not.
               (cond (block-verbatim-p (current-column))
                     ((= (line-number-at-pos) 1) block-column)
                     (t (tuareg-compute-indent)))))))
   (tuareg-discover-phrase))
 
 (defun tuareg-indent-phrase ()
+  ;; CR pszilagyi: I think this should act more like M-q
+  ;; (fill-paragraph) inside a comment, at least outside an ocamldoc
+  ;; block (e.g., {[ ]}).  I would phrase that as "fill a comment
+  ;; paragraph".  However, that is a big change.
   "Depending of the context: justify and indent a comment,
 or indent all lines in the current phrase."
   (interactive)
                            (tuareg-beginning-of-literal-or-comment)
                            (point)))
                (begpoint (save-excursion
+                           ;; beginning of previous blank line or
+                           ;; outermost comment or literal
                            (while (and (> (point) cobpoint)
                                        (tuareg-in-comment-p)
                                        (not (looking-at "^[ \t]*$")))
                              (forward-line -1))
                            (max cobpoint (point))))
                (coepoint (save-excursion
+                           ;; after outermost comment ending
                            (while (tuareg-in-comment-p)
                              (re-search-forward "\\*)" nil 'end))
                            (point)))
                (endpoint (save-excursion
+                           ;; beginning of line after either next
+                           ;; blank line or outermost comment ender
                            (re-search-forward "^[ \t]*$" coepoint 'end)
                            (line-beginning-position 2)))
                (leading-star (tuareg-leading-star-p)))
             (forward-line 1)
             (back-to-indentation)
             (when (looking-at "\\*\\**\\([^)]\\|$\\)")
+              ;; CR pszilagyi: Why delete only the first "*", when
+              ;; there could be more?
               (delete-char 1)
               (setq endpoint (1- endpoint))))
           (goto-char (min (point) endpoint))
           (fill-region begpoint endpoint)
-          (re-search-forward "\\*)" nil 'end)
+          ;; CR pszilagyi: endpoint was after "*)", so this is likely
+          ;; to scan to the *next* comment when we fill the last
+          ;; paragraph in a comment.  Why?  Is it just a bug?
+          ;;
+          ;; I say "likely" because endpoint is invalidated by the
+          ;; fill, which has potentially changed the size of text we
+          ;; delimited.  The next setq fixes that.  I'm guessing this
+          ;; re-search-forward is a workaround to add stars to and
+          ;; fill the whole rest of the comment, in which case I think
+          ;; it should have a while around it like the definition of
+          ;; coepoint.  Since the c-mode M-q doesn't try to do
+          ;; anything this fancy, I'm going to err on the side of
+          ;; reducing the scope of the star-filling for now, in order
+          ;; to avoid this filling too much.
+          ;;
+          ;;(re-search-forward "\\*)" nil 'end)
           (setq endpoint (point))
           (when leading-star
             (goto-char begpoint)