bug#47757: 13.0.6; Point position after indent-for-tab-command with LaTeX-syntactic-comments

[Gustavo Barros]

On Sun, 18 Apr 2021 at 04:17, Tassilo Horn <tsdh@gnu.org> wrote:

> Gustavo Barros <gusbrs.2016@gmail.com> writes:
>
> Hi Gustavo,
>
> > I'm sorry to report that I've missed a problem in my testing.
>
> Hehe, yesterday evening I've release 13.0.7 on ELPA, code-name 
> "Gustavo
> did the testing". ;-)
>
> But no worries!

Well, I am sorry.  But, to be fair, I admitted to light testing, and I 
was looking at indentation behavior.  True, `LaTeX-syntactic-comments' 
should have put me on better tracks there, but I'm not that familiar 
with this particular machinery, so testing also filling did not come 
naturally.  And I also did not keep the fix after testing, so that I did 
not notice "something was off", which only happened after I got it from 
the release.

> > The commit to fix the interaction between `LaTeX-back-to-indentation'
> > and `electric-indent-mode' seems to have broken paragraph filling in
> > comments.
>
> Ouch, indeed.  I've hopefully just fixed it in git using this 
> definition
> which changes the behavior from "move point to the comment content 
> only
> for indent commands" to "don't move point there for newline commands":
>
> --8<---------------cut here---------------start------------->8---
> (defun LaTeX-back-to-indentation (&optional force-type)
>   "Move point to the first non-whitespace character on this line.
> If it is commented and comments are formatted syntax-aware move
> point to the first non-whitespace character after the comment
> character(s), but only if `this-command' is not a newline
> command, i.e., `TeX-newline' or the value of
> `TeX-newline-function'.  The optional argument FORCE-TYPE can be
> used to force point being moved to the inner or outer indentation
> in case of a commented line.  The symbols 'inner and 'outer are
> recognized."
>   (if (or (and force-type
>                (eq force-type 'inner))
>           (and (not force-type)
>                (or (and (TeX-in-line-comment)
>                         (eq major-mode 'doctex-mode))
>                    (and (TeX-in-commented-line)
>                         ;; Only move after the % if we're not
>                         ;; performing a newline command (bug#47757).
>                         (not (memq this-command
>                                    `( TeX-newline
>                                       ,TeX-newline-function)))
>                         LaTeX-syntactic-comments))))
>       (progn
>         (beginning-of-line)
>         ;; Should this be anchored at the start of the line?
>         (TeX-re-search-forward-unescaped
>          (concat "\\(?:" TeX-comment-start-regexp "+[ \t]*\\)+")
>          (line-end-position) t))
>     (back-to-indentation)))
> --8<---------------cut here---------------end--------------->8---
>
> Please give it a try.  I'll release 13.0.8 if you don't find another
> regression.

Yesterday, after I wrote, I still did some digging.  Considering Emacs' 
and AUCTeX's codebases, `LaTeX-back-to-indentation' only occurs in 
`latex.el'.  Within it, there are four "bare" (no args) calls to the 
function, two of them in `LaTeX-indent-line' which, as far as I can 
tell, is as expected.  The other two are in filling related functions, 
one in `LaTeX-fill-region-as-para-do' the other in 
`LaTeX-fill-move-to-break-point'.  Perhaps those should receive an 
explicit argument, so as to work as expected during filling, regardless 
of what is happening on the side of indentation proper, so as to make 
filling more resilient and independent from indent behavior.  WDYT?  As 
far as I get it, calls in the form `(LaTeX-back-to-indentation (if 
LaTeX-syntactic-comments 'inner 'outer))' should reproduce exactly the 
previous state of things for those two functions.

Anyway, I did some testing again.  Again lightly, but I've tested now 
indent, it's interaction with `electric-indent', and filling.  I 
considered the following cases: 1) the new fix for 
`LaTeX-back-to-indentation' by itself; 2) the new fix with the suggested 
change in `LaTeX-fill-region-as-para-do' and 
`LaTeX-fill-move-to-break-point'; 3) the new fix with the suggested 
change in `LaTeX-fill-region-as-para-do' and 
`LaTeX-fill-move-to-break-point'.  I only considered the case where 
`LaTeX-syntactic-comments' is t.

I did find one filling related glitch, inside environments.  Examples:

#+begin_src latex
\begin{itemize}
\item test
 % a comment. and new sentence.
 % a new line.
\end{itemize}

\begin{quote}
 % a comment. and new sentence.
 % a new line.
\end{quote}

% a comment. and new sentence.
% a new line.
#+end_src

Filling those comments within itemize and quote will not join those 
lines, whereas outside the environments it does.  The later is expected 
behavior, as far as I can tell.  Long lines do get properly filled in 
either case, just the joining of contiguous short ones does not happen.

However, this was already the case before the fix and the release.  So I 
consider it to be a separate, though related, issue.

Other than that, I could spot no other problems within the described 
bounds of testing, and things work as expected for all three cases.

Summing up.  The new fix looks good to me regardless of anything else. 
Still, I do think it is a good idea to protect the calls 
`LaTeX-back-to-indentation' in `LaTeX-fill-region-as-para-do' and 
`LaTeX-fill-move-to-break-point' by making the argument explicit.  If 
you choose to do so, both of the fixes to `LaTeX-back-to-indentation' 
work.  However, considering the episode, I'd still recommend the second, 
as it seems to go on the safer side of things.  For example, I did check 
all direct calls to `LaTeX-back-to-indentation', but if somewhere up the 
code chain a function which calls it with an argument is itself called 
without an argument, this was not covered in my digging.  I would not 
expect it, but I did not check.  The filling glitch in environments is a 
separate problem, as it already occurred before the first fix.

Well, if all goes well, I hope you can release soon the codenamed 
"Tassilo cleaned up after Gustavo's testing", since "Gustavo did the 
testing again" would probably raise user's eyebrows at this point. ;-)

Thanks for bearing with the issue.

Best regards,
Gustavo.