[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47757: 13.0.6; Point position after indent-for-tab-command with LaTe

From: Gustavo Barros
Subject: bug#47757: 13.0.6; Point position after indent-for-tab-command with LaTeX-syntactic-comments
Date: Sun, 18 Apr 2021 09:14:37 -0300
User-agent: mu4e 1.4.15; emacs 27.2

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

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
  (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
        ;; Should this be anchored at the start of the line?
         (concat "\\(?:" TeX-comment-start-regexp "+[ \t]*\\)+")
         (line-end-position) t))
--8<---------------cut here---------------end--------------->8---

Please give it a try.  I'll release 13.0.8 if you don't find another

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
\item test
 % a comment. and new sentence.
 % a new line.

 % a comment. and new sentence.
 % a new line.

% a comment. and new sentence.
% a new line.

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]