[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63790: 30.0.50; prog-fill-reindent-defun regression
From: |
Juri Linkov |
Subject: |
bug#63790: 30.0.50; prog-fill-reindent-defun regression |
Date: |
Fri, 09 Jun 2023 20:37:04 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) |
>>>> (re-search-forward "\\s-*\\s<" (line-end-position) t)
>>>
>>> It's looking for a comment that begins after point (possibly preceded by
>>> whitespace). There is no comment after point in the presented scenario.
>>>
>>>> It's nil in the reported case, so 'fill-paragraph' is not called.
>>>
>>> I guess when there is an active region, we would force the behavior to
>>> "refill" the region, no matter whether it is inside a comment, or contains
>>> a comment, or outside of any comments and simply contains code?
>> While 'prog-fill-reindent-defun' doesn't support indentation of an
>> arbitrary region of code and indents only the top-level list (defun),
>> it looks like the right thing is to fill the region.
>
> Okay?
Unless it's possible to make 'M-q' more predictable.
>> I still don't understand why 'M-q' now does the same what 'C-M-q' was
>> doing all the time with code indentation?
>
> C-M-q (indent-pp-sexp) reindents the list that follows point. Not the same
> thing. And it's only available in Lisp.
I tried in emacs-28 and in ruby-mode 'C-M-q' reindents the code.
This is from the Help window:
C-M-q runs the command prog-indent-sexp (found in ruby-mode-map),
which is an interactive byte-compiled Lisp function in ‘prog-mode.el’.
It is bound to C-M-q, <menu-bar> <ruby> <Indent Sexp-9>.
(prog-indent-sexp &optional DEFUN)
Indent the expression after point.
When interactively called with prefix, indent the enclosing defun
instead.
>> Also why 'prog-fill-reindent-defun'
>> can't indent the region of code, but only the region of comments?
>
> Do you want it to?
It would be nice, and it's easy to implement just by calling 'indent-region'.
>> Shouldn't 'M-q' only refill comments, and 'C-M-q' only indent code, as
>> before?
>
> Up until now, we thought that making two actions on one key binding
> available is a good thing, given that the context usually helps to
> disambiguate. This one seems like an exception, but IMHO not a strong
> enough one to roll back the change.
Before the change, the distinction was clear: 'C-M-q' reindents code, 'M-q'
refills text in comments. Whereas I admit that 'M-q' is useless on code,
now the distinction is blurred, and DWIM is not reliable.