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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47757 in the body.
You can then email your comments to 47757 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: bug-auctex <at> gnu.org
Subject: 13.0.6; Point position after indent-for-tab-command with
 LaTeX-syntactic-comments
Date: Tue, 13 Apr 2021 16:39:32 -0300

Hi All,

As of the latest AUCTeX release, when `LaTeX-syntactic-comments' is t, 
as it is by default, calling `indent-for-tab-command' ("TAB") before the 
start of the comment text on the line will move point to the start of 
the comment text.  I believe this to be unexpected, but I might be 
missing something from expected behavior.  Either way, I can provide at 
least one example of inconvenience resulting from this when it interacts 
with `electric-indent-mode' (also on by default).

I'm not claiming this behavior is new, but I don't recall it being the 
case previously.  Anyway, I just said "as of the latest AUCTeX release" 
because that's where I verified the behavior.  It might well be older, I 
don't know.

An ECM to reproduce the issue is:

Start `emacs -Q'.

Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/auctex-13.0.6")
(load "auctex.el" nil t t)
(setq TeX-parse-self t)
(setq TeX-auto-save t)
#+end_src

Visit a `.tex' file with contents ("|" represents point position):
#+begin_src latex

|% comment

#+end_src

Call `indent-for-tab-command' ("TAB"), and point moves to:
#+begin_src latex

% |comment

#+end_src

Whether there was actually some indenting to do or not, as long as point 
was before the start of the text (somewhere in the comment prefix, or 
before it) point is moved to the start of the comment text.  I would 
expect it not to move at all if there is no indent to be done, and only 
move if indenting deletes the place where point was, in which case, I'd 
expect point to end at the comment character (only after a possible 
whitespace).

As far as I could dig, this results from (or is related to) 
`LaTeX-syntactic-comments', which is set to t by default.  Setting 
`LaTeX-syntactic-comments' to nil eliminates the described behavior.

As for an example of a resulting inconvenience of this behavior, when 
`electric-indent-mode' is on (which is the case by default), if point is 
at the start of the line, as in:

#+begin_src latex

|% comment

#+end_src

And we want to add some blank lines before comment, it would be only 
natural to hit "RET" a couple of times.  If we do so, the result is:

#+begin_src latex


%
|comment

#+end_src

While I'd expect it to be:

#+begin_src latex



|% comment

#+end_src


Best regards,
Gustavo.

PS: Please keep me CC'd.



Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.20, cairo version 1.16.0)
of 2021-03-25
Package: 13.0.6

current state:
==============
(setq
AUCTeX-date "2021-04-02"
window-system 'x
LaTeX-version "2e"
TeX-style-path '("~/.emacs.d/auctex"
		  "/home/gustavo/.emacs.d/elpa/auctex-13.0.6/style"
		  "/home/gustavo/.emacs.d/auctex/auto"
		  "/home/gustavo/.emacs.d/auctex/style" "auto" "style")
TeX-auto-save t
TeX-parse-self t
TeX-master t
TeX-command-list '(("TeX"
		     "%(PDF)%(tex) %(file-line-error) %`%(extraopts) 
		     %S%(PDFout)%(mode)%' %(output-dir) %t"
		     TeX-run-TeX nil
		     (plain-tex-mode ams-tex-mode texinfo-mode) :help
		     "Run plain TeX")
		    ("LaTeX" "%`%l%(mode)%' %T" TeX-run-TeX nil
		     (latex-mode doctex-mode) :help "Run LaTeX")
		    ("Makeinfo" "makeinfo %(extraopts) %(o-dir) %t"
		     TeX-run-compile nil (texinfo-mode) :help
		     "Run Makeinfo with Info output")
		    ("Makeinfo HTML"
		     "makeinfo %(extraopts) %(o-dir) --html %t"
		     TeX-run-compile nil (texinfo-mode) :help
		     "Run Makeinfo with HTML output")
		    ("AmSTeX"
		     "amstex %(PDFout) %`%(extraopts) %S%(mode)%' 
		     %(output-dir) %t"
		     TeX-run-TeX nil (ams-tex-mode) :help "Run AMSTeX")
		    ("ConTeXt"
		     "%(cntxcom) --once --texutil %(extraopts) 
		     %(execopts)%t"
		     TeX-run-TeX nil (context-mode) :help "Run ConTeXt 
		     once")
		    ("ConTeXt Full" "%(cntxcom) %(extraopts) 
		    %(execopts)%t"
		     TeX-run-TeX nil (context-mode) :help
		     "Run ConTeXt until completion")
		    ("BibTeX" "bibtex %(O?aux)" TeX-run-BibTeX nil
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode context-mode)
		     :help "Run BibTeX")
		    ("Biber" "biber %s %(output-dir)" TeX-run-Biber nil
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Run Biber")
		    ("View" "%V" TeX-run-discard-or-function t t :help
		     "Run Viewer")
		    ("Print" "%p" TeX-run-command t t :help "Print the 
		    file")
		    ("Queue" "%q" TeX-run-background nil t :help
		     "View the printer queue" :visible 
		     TeX-queue-command)
		    ("File" "%(o?)dvips %d -o %f " TeX-run-dvips t
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Generate PostScript file")
		    ("Dvips" "%(o?)dvips %d -o %f " TeX-run-dvips nil
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Convert DVI file to PostScript")
		    ("Dvipdfmx" "dvipdfmx %d -o %(O?pdf)" 
		    TeX-run-dvipdfmx nil
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Convert DVI file to PDF with dvipdfmx")
		    ("Ps2pdf" "ps2pdf %f %(O?pdf)" TeX-run-ps2pdf nil
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Convert PostScript file to PDF")
		    ("Glossaries" "makeglossaries %(O?aux)" 
		    TeX-run-command
		     nil
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Run makeglossaries to create glossary\n 
		     file")
		    ("Index" "makeindex %(O?idx)" TeX-run-index nil
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Run makeindex to create index file")
		    ("upMendex" "upmendex %(O?idx)" TeX-run-index t
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Run upmendex to create index file")
		    ("Xindy" "texindy %s" TeX-run-command nil
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Run xindy to create index file")
		    ("Check" "lacheck %s" TeX-run-compile nil 
		    (latex-mode)
		     :help "Check LaTeX file for correctness")
		    ("ChkTeX" "chktex -v6 %s" TeX-run-compile nil 
		    (latex-mode)
		     :help "Check LaTeX file for common mistakes")
		    ("Spell" "(TeX-ispell-document \"\")" 
		    TeX-run-function nil
		     t :help "Spell-check the document")
		    ("Clean" "TeX-clean" TeX-run-function nil t :help
		     "Delete generated intermediate files")
		    ("Clean All" "(TeX-clean t)" TeX-run-function nil t 
		    :help
		     "Delete generated intermediate and output files")
		    ("Other" "" TeX-run-command t t :help
		     "Run an arbitrary command")
		    )
)

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Wed, 14 Apr 2021 10:28:05 +0200

Gustavo Barros <gusbrs.2016 <at> gmail.com> writes:

Hi Gustavo,

> As of the latest AUCTeX release, when `LaTeX-syntactic-comments' is t,
> as it is by default, calling `indent-for-tab-command' ("TAB") before
> the start of the comment text on the line will move point to the start
> of the comment text.  I believe this to be unexpected, but I might be
> missing something from expected behavior.  Either way, I can provide
> at least one example of inconvenience resulting from this when it
> interacts with `electric-indent-mode' (also on by default).

I was able to reproduce the behavior by your very good recipe.
Basically, I like the behavior to move point to the actual comment text
but the combination with `electric-indent-mode' is indeed very annyoing.
I've changed it on our git master so that it'll jump after the % only if
the currently executing interactive command is an indentation command
(and not, e.g., `TeX-newline').

Here's the changed definition.  Please eval it and see if you spot some
raw edges.

--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 an actual indentation
command.  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 actually
                        ;; performing an indent command and something
                        ;; else like our `TeX-newline-function' which
                        ;; will be invoked automatically by
                        ;; `electric-indent-mode' (bug#47757).
                        (memq this-command
                              `(,indent-line-function
                                indent-for-tab-command
                                LaTeX-indent-line))
                        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))) ;; <-- C-x C-e here!
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Wed, 14 Apr 2021 08:43:50 -0300

Hi Tassilo,

On Wed, 14 Apr 2021 at 05:28, Tassilo Horn <tsdh <at> gnu.org> wrote:

> I was able to reproduce the behavior by your very good recipe.
> Basically, I like the behavior to move point to the actual comment 
> text
> but the combination with `electric-indent-mode' is indeed very 
> annyoing.
> I've changed it on our git master so that it'll jump after the % only 
> if
> the currently executing interactive command is an indentation command
> (and not, e.g., `TeX-newline').
>
> Here's the changed definition.  Please eval it and see if you spot 
> some
> raw edges.

Thank you very much for looking into this.

I've tested (lightly) the new definition, it does indeed fixes the 
interaction with `electric-indent-mode' and, as far as I can tell, 
introduces no other problems, and leaves no "raw edges" I could spot.

So it was intended behavior after all!  But, still, now that I became 
aware of it, I'm a little baffled by it.  I'm on the verge of asking you 
to make this configurable, but I'm still not sure about it.  Is this 
behavior indeed new?  My git-blame-fu, which is not very good, says it 
is pretty old.  But I really don't recall ever noticing it, perhaps it 
is just the age of that little piece between the keyboard and the 
chair...

To be a little more precise, I do like it to be able to move to the 
beginning of the comment content, just as you do.  As a matter of fact, 
I use a local variant of package `mwim' for the purpose.  But I'm not 
sure this is something I'd expect (or like) `indent-for-tab-command' (& 
friends) to do.  Also, I don't really get why this behavior should 
depend on `LaTeX-syntactic-comments'.  True, its docstring says it 
"influences the behavior indentation and filling", but I'd assume this 
means the end result of the indentation and filling in the buffer, not 
quite a difference in point behavior.  Regarding the later, why being 
"handled according to LaTeX syntax" means point is left at the beginning 
of the comment content instead of at the end of whitespace?  In other 
words, isn't "performing inner or outer indentation" (to use the 
terminology in `LaTeX-current-indentation') something different from 
"where to place point after indenting"?

Anyway, if this is old behavior and users are already familiar with it, 
it is certainly the case that I'll eventually get used to it too, and 
tampering with it is inadvisable.  And, even if it is new(ish), feel 
free to let the last couple of paragraphs just slide away.  Unless you 
happen to think there is something interesting in those observations, in 
which case I'm happy to discuss further.

Thanks again for the quick response and fix!

Best regards,
Gustavo.

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Sat, 17 Apr 2021 10:01:31 +0200

Gustavo Barros <gusbrs.2016 <at> gmail.com> writes:

Hi Gustavo,

> So it was intended behavior after all!  But, still, now that I became
> aware of it, I'm a little baffled by it.  I'm on the verge of asking
> you to make this configurable, but I'm still not sure about it.  Is
> this behavior indeed new?

No, not really.  AUCTeX does it at least since 2004 where
`LaTeX-syntactic-comments' was named
`LaTeX-format-comment-syntax-aware'.  And `electric-indent-mode' is on
by default since 2013, too (I don't know what was the first emacs
version with that change).  So indeed, it also baffles me that nobody
spotted the annoying newline behavior until now.

> To be a little more precise, I do like it to be able to move to the
> beginning of the comment content, just as you do.  As a matter of
> fact, I use a local variant of package `mwim' for the purpose.  But
> I'm not sure this is something I'd expect (or like)
> `indent-for-tab-command' (& friends) to do.  Also, I don't really get
> why this behavior should depend on `LaTeX-syntactic-comments'.  True,
> its docstring says it "influences the behavior indentation and
> filling", but I'd assume this means the end result of the indentation
> and filling in the buffer, not quite a difference in point behavior.
> Regarding the later, why being "handled according to LaTeX syntax"
> means point is left at the beginning of the comment content instead of
> at the end of whitespace?  In other words, isn't "performing inner or
> outer indentation" (to use the terminology in
> `LaTeX-current-indentation') something different from "where to place
> point after indenting"?

Well, maybe, maybe not.  I see as `LaTeX-syntactic-comments' as
"consider the contents of comments to be LaTeX entities, too", and then
it makes sense for TAB to end up at the actual content of the comment
and not the comment starter.

> Anyway, if this is old behavior and users are already familiar with
> it, it is certainly the case that I'll eventually get used to it too,
> and tampering with it is inadvisable.  And, even if it is new(ish),
> feel free to let the last couple of paragraphs just slide away.
> Unless you happen to think there is something interesting in those
> observations, in which case I'm happy to discuss further.

I can follow your reasoning but given that you are not really opposed to
the current behavior and neither are other users, let's just keep it
as-is.

Bye,
Tassilo

Message #28 received at 47757-done <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: 47757-done <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Sat, 17 Apr 2021 10:17:05 +0200

I'm closing this issue.

Message #31 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Sat, 17 Apr 2021 07:43:44 -0300

On Sat, 17 Apr 2021 at 05:01, Tassilo Horn <tsdh <at> gnu.org> wrote:

Hi Tassilo,

> No, not really.  AUCTeX does it at least since 2004 where
> `LaTeX-syntactic-comments' was named
> `LaTeX-format-comment-syntax-aware'.  And `electric-indent-mode' is on
> by default since 2013, too (I don't know what was the first emacs
> version with that change).  So indeed, it also baffles me that nobody
> spotted the annoying newline behavior until now.

> [...]

> I can follow your reasoning but given that you are not really opposed 
> to
> the current behavior and neither are other users, let's just keep it
> as-is.

It's all good.  If it is old, and that old, I very much agree that a 
change is not only not granted but also not advisable.  The interaction 
with `electric-indent-mode' was indeed annoying, but that's already 
gone.  Thanks for taking the time to consider these random thoughts 
though.

Best regards,
Gustavo

Message #37 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Sat, 17 Apr 2021 23:35:22 -0300

On Wed, 14 Apr 2021 at 08:43, Gustavo Barros <gusbrs.2016 <at> gmail.com> 
wrote:

Hi Tassilo,

> On Wed, 14 Apr 2021 at 05:28, Tassilo Horn <tsdh <at> gnu.org> wrote:
>
>> I was able to reproduce the behavior by your very good recipe.
>> Basically, I like the behavior to move point to the actual comment 
>> text
>> but the combination with `electric-indent-mode' is indeed very 
>> annyoing.
>> I've changed it on our git master so that it'll jump after the % only 
>> if
>> the currently executing interactive command is an indentation command
>> (and not, e.g., `TeX-newline').
>>
>> Here's the changed definition.  Please eval it and see if you spot 
>> some
>> raw edges.
>
> Thank you very much for looking into this.
>
> I've tested (lightly) the new definition, it does indeed fixes the 
> interaction
> with `electric-indent-mode' and, as far as I can tell, introduces no 
> other
> problems, and leaves no "raw edges" I could spot.

I'm sorry to report that I've missed a problem in my testing.  The 
commit to fix the interaction between `LaTeX-back-to-indentation' and 
`electric-indent-mode' seems to have broken paragraph filling in 
comments.

To reproduce, use the same setup as the one used in the original report 
(only with the new released version) and visit a file with a long 
comment line. Now call `fill-paragraph' "M-q" with point in this comment 
line.  The line is not filled.  Either reverting to the old definition 
of `LaTeX-back-to-indentation' or disabling `LaTeX-syntactic-comments' 
brings back filling to working conditions.

Best regards,
Gustavo.

Message #43 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Sun, 18 Apr 2021 09:17:52 +0200

Gustavo Barros <gusbrs.2016 <at> 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!

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

Thanks,
Tassilo

Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: 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

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

> Gustavo Barros <gusbrs.2016 <at> 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.

Message #55 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Sun, 18 Apr 2021 09:35:46 -0300

On Sun, 18 Apr 2021 at 09:14, Gustavo Barros <gusbrs.2016 <at> gmail.com> 
wrote:

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

Biting my own tongue on the copy-paste critiques here. "3)" was meant to 
be "the *first* fix with the suggested change in 
`LaTeX-fill-region-as-para-do' and `LaTeX-fill-move-to-break-point'".

Best regards,
Gustavo.

Message #61 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: 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

Gustavo Barros <gusbrs.2016 <at> 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.

Agreed.

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

Bye,
Tassilo

Message #67 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Sun, 18 Apr 2021 15:54:16 -0300

On Sun, 18 Apr 2021 at 13:28, Tassilo Horn <tsdh <at> gnu.org> wrote:

Hi Tassilo,

> Gustavo Barros <gusbrs.2016 <at> 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.
>

Oh! none taken.  Quite the contrary.  I am a little embarrassed to have 
actually missed the issue.  Though it happens to everyone, every once in 
a while.  Anyway, your "nag" was received in a warmhearted welcoming 
spirit at this end.  But I appreciate your concern.  As we know, email 
conversations between people who never met in person can be touchy 
sometimes.

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

Despite that, shouldn't the contiguous lines be filled?

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

Sounds good to me.

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

Also sounds good to me.

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

Great.

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

hahaha, It seems so am I!  :-)

Bye,
Gustavo

Message #73 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Sun, 18 Apr 2021 21:07:26 +0200

Hi Gustavo,

>>> 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.
>
> Despite that, shouldn't the contiguous lines be filled?

That's the question.  Given that long lines are still filled, I'm
tempted to say that contiguous short lines should also be joined.  OTOH,
I wouldn't be surprised if that's a feature...

Oh, yeah, I've just checked the docs (info "(auctex) Filling"):

--8<---------------cut here---------------start------------->8---
   Code comments are comments preceded by code or text in the same line.
Upon filling a region, code comments themselves will not get filled.
Filling is done from the start of the region to the line with the code
comment and continues after it.  In order to prevent overfull lines in
the source code, a linebreak will be inserted before the last
non-comment word by default.  This can be changed by customizing
'LaTeX-fill-break-before-code-comments'.  If you have overfull lines
with code comments you can fill those explicitely by calling
'LaTeX-fill-paragraph' or pressing 'M-q' with the cursor positioned on
them.  This will add linebreaks in the comment and indent subsequent
comment lines to the column of the comment in the first line of the code
comment.  In this special case 'M-q' only acts on the current line and
not on the whole paragraph.
--8<---------------cut here---------------end--------------->8---

So it seems like AUCTeX considers any comment not starting in column one
(zero?) as a code comment, and then it'll fill only that line and not
the complete comment paragraph.

Now the question is if whitespace qualifies as "code or text".  Most
probably it shouldn't but I'm not too sure.

Bye,
Tassilo

Message #79 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Sun, 18 Apr 2021 18:05:34 -0300

On Sun, 18 Apr 2021 at 16:07, Tassilo Horn <tsdh <at> gnu.org> wrote:

Hi Tassilo,

> Hi Gustavo,
>
>>>> 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.
>>
>> Despite that, shouldn't the contiguous lines be filled?
>
> That's the question.  Given that long lines are still filled, I'm
> tempted to say that contiguous short lines should also be joined. 
> OTOH,
> I wouldn't be surprised if that's a feature...
>
> Oh, yeah, I've just checked the docs (info "(auctex) Filling"):
>
> --8<---------------cut here---------------start------------->8---
>    Code comments are comments preceded by code or text in the same 
>    line.
> Upon filling a region, code comments themselves will not get filled.
> Filling is done from the start of the region to the line with the code
> comment and continues after it.  In order to prevent overfull lines in
> the source code, a linebreak will be inserted before the last
> non-comment word by default.  This can be changed by customizing
> 'LaTeX-fill-break-before-code-comments'.  If you have overfull lines
> with code comments you can fill those explicitely by calling
> 'LaTeX-fill-paragraph' or pressing 'M-q' with the cursor positioned on
> them.  This will add linebreaks in the comment and indent subsequent
> comment lines to the column of the comment in the first line of the 
> code
> comment.  In this special case 'M-q' only acts on the current line and
> not on the whole paragraph.
> --8<---------------cut here---------------end--------------->8---
>
> So it seems like AUCTeX considers any comment not starting in column 
> one
> (zero?) as a code comment, and then it'll fill only that line and not
> the complete comment paragraph.
>
> Now the question is if whitespace qualifies as "code or text".  Most
> probably it shouldn't but I'm not too sure.

Well, in this case, I do have an opinion: The lines should be joined, 
and indentation whitespace does not qualify as "code or text".  That's 
the way it works elsewhere in Emacs, as far as I can tell.

Besides, not being able to fill comment paragraphs inside environments 
is a relevant (and arbitrary) limitation, I think.  As a matter of fact, 
I have a good example.  One of those things that belong to those "muscle 
memory workarounds on a not very conscious level", but now that I think 
of it, this is the reason.  The situation is the following.  When I have 
to translate a quote from a reference, which happens quite a lot since 
I'm not from an English speaking country, I translate the quote's text, 
but keep the original as a comment right below it, inside the 
environment.  Now, there is no way to fill this commented paragraph 
properly.  The semi-conscious workaround is the following: add a blank 
line between the translated and the original text; select the commented 
paragraph; uncomment it; select it again; fill it; navigate back; delete 
the blank line.  All that instead of "M-q", and the result is still not 
good, because the filling was not done considering the two characters 
the comment takes, so that it still occasionally extrapolates 
fill-column in the end.

I've just tested this again, and it turns out this behavior is also 
dependent on `LaTeX-syntactic-comments'.  If `LaTeX-syntactic-comments' 
is set to nil, the filling of the comment paragraph indented inside the 
quote environment does occur as expected (or, at least, as I'd expect 
it).  In my view, this is enough evidence that the mentioned 
documentation paragraph should not be taken as meaning this is a 
feature, since whitespace is not being interpreted as "code or text" 
when `LaTeX-syntactic-comments' is nil, and that this should be seen as 
a bug related to `LaTeX-syntactic-comments'.

Best regards,
Gustavo.

Message #85 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Fri, 23 Apr 2021 20:59:21 +0200

Gustavo Barros <gusbrs.2016 <at> gmail.com> writes:

Hi Gustavo,

>> Now the question is if whitespace qualifies as "code or text".  Most
>> probably it shouldn't but I'm not too sure.
>
> Well, in this case, I do have an opinion: The lines should be joined,
> and indentation whitespace does not qualify as "code or text".  That's
> the way it works elsewhere in Emacs, as far as I can tell.

Indeed, `LaTeX-fill-paragraph' didn't consider them code comments but
then `LaTeX-fill-region-as-paragraph' did.  Should be fixed now.

Bye,
Tassilo

Message #91 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Fri, 23 Apr 2021 16:53:46 -0300

On Fri, 23 Apr 2021 at 15:59, Tassilo Horn <tsdh <at> gnu.org> wrote:

Hi Tassilo,

> Indeed, `LaTeX-fill-paragraph' didn't consider them code comments but
> then `LaTeX-fill-region-as-paragraph' did.  Should be fixed now.

Thank you very much!

Bye,
Gustavo.

Message #97 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Fri, 23 Apr 2021 22:53:56 +0200

Gustavo Barros <gusbrs.2016 <at> gmail.com> writes:

Hi Gustavo,

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

I've made the args explicit now, even so explicit that it became one
'inner and one 'outer, so not depending on `LaTeX-syntactic-comments'.
I've also added a test case for filling with syntactic comments
including code comments.

Bye,
Tassilo

Message #103 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 47757 <at> debbugs.gnu.org
Subject: Re: bug#47757: 13.0.6; Point position after indent-for-tab-command
 with LaTeX-syntactic-comments
Date: Fri, 23 Apr 2021 19:58:56 -0300

On Fri, 23 Apr 2021 at 17:53, Tassilo Horn <tsdh <at> gnu.org> wrote:

Hi Tassilo,

> I've made the args explicit now, even so explicit that it became one
> 'inner and one 'outer, so not depending on `LaTeX-syntactic-comments'.
> I've also added a test case for filling with syntactic comments
> including code comments.

Oh, that's great.  I only had suggested the conditional because that 
would reproduce exactly the status quo, and because I don't know well 
the workings of the involved functions.  But I did think further 
simplification might possible according to the point position 
requirements in each case.  If you took the trouble to look into it, 
even better.  And tests on top of it!  Thank you very much yet again!

Bye,
Gustavo.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.