[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: Tassilo Horn
Subject: bug#47757: 13.0.6; Point position after indent-for-tab-command with LaTeX-syntactic-comments
Date: Sun, 18 Apr 2021 18:28:34 +0200
User-agent: mu4e 1.5.11; emacs 28.0.50

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.

Hey, I hope you did not take any offense in my words.  I just wanted to
nag you a bit.  Obviously, it's my job do test my changes properly.

> 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.

Hm, sounds reasonable.

> 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.

Hm, indeed.  But that doesn't actually seem to come from the commend
being inside an environment but from the comment being indented.

> 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.

Great, then I'll cut a new ELPA release with just that so that there's a
fixed version ASAP.

> 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.

I think I agree but have no time for doing that right now.  I'll have a
look whenever I find some spare time next week.

> 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.


> 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. ;-)

I'd be very suspicious if my name occurred in any release codename.  I'm
an expert in testing exactly the things that still work. :-)


reply via email to

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