Breaking change with auto-filling in Org mode with recent commit

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Breaking change with auto-filling in Org mode with recent commit

Kaushal Modi
Hello,

I have noticed auto-filling to stop doing the right thing after commit http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9b463fa8648b7baed95a44f4317cb7402fd8bf1c

I have verified that reverting just that commit brings things back to stable state.

Examples in Org mode *with auto-fill-mode enabled*:

=====
#+BEGIN_SRC nim
# echo @["a", "b", "c"].join(' ') # Error: type mismatch: got (seq[string], char)
#+END_SRC
=====

Before commit 9b463fa8:
- With point at the end of that comment line starting with "echo", if I hit Enter, filling will *not* happen on that line.

After commit 9b463fa8:
- With point at the end of that comment line starting with "echo", if I hit Enter, filling will happen, resulting in invalid code:
=====
#+BEGIN_SRC nim
# echo @["a", "b", "c"].join(' ') # Error: type 
mismatch: got (seq[string], char)
#+END_SRC
=====

Another example:

=====
* Heading
1. =["a", "b", "c"].join(" ")= does not work, but =join(["a", "b", "c"], " ")= works.
=====

Before commit 9b463fa8:
- With point at the end of that Org list item, if I hit Enter, I will get:
=====
* Heading
1. =["a", "b", "c"].join(" ")= does not work, but =join(["a", "b",
   "c"], " ")= works.
=====
- Then if I hit M-RET, I get:
=====
* Heading
1. =["a", "b", "c"].join(" ")= does not work, but =join(["a", "b",
   "c"], " ")= works.
2.
=====
Notice that space inserted at the beginning of "   "c"], " ")= works." line is important!

After commit 9b463fa8:
- With point at the end of that Org list item, if I hit Enter, I will get:
=====
* Heading
1. =["a", "b", "c"].join(" ")= does not work, but =join(["a", "b",
"c"], " ")= works.
=====
- Then if I hit M-RET, I get:
=====
* Heading
1. =["a", "b", "c"].join(" ")= does not work, but =join(["a", "b",
"c"], " ")= works.
=====
As that extra space now not inserted, Org does not detect that I am trying to continue in the same list and starts a new Org heading.

I have just given an example using Org. The change in Emacs core though seems to have broken the fundamental operation of auto-filling in comments.
--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Breaking change with auto-filling in Org mode with recent commit

Eric Abrahamsen-2
Kaushal Modi <[hidden email]> writes:

> Hello,
>
> I have noticed auto-filling to stop doing the right thing after commit http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9b463fa8648b7baed95a44f4317cb7402fd8bf1c

[...]

> I have just given an example using Org. The change in Emacs core though seems to have broken the fundamental operation of auto-filling in comments.

I've been seeing the same thing in message-mode.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Breaking change with auto-filling in Org mode with recent commit

Tom Tromey-4
In reply to this post by Kaushal Modi
>>>>> "Kaushal" == Kaushal Modi <[hidden email]> writes:

Kaushal> I have noticed auto-filling to stop doing the right thing after commit
Kaushal> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9b463fa8648b7baed95a44f4317cb7402fd8bf1c

Yes, sorry about this.
It's being fixed in bug#28003.

Tom

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Breaking change with auto-filling in Org mode with recent commit

Kaushal Modi
On Wed, Aug 9, 2017 at 12:12 PM Tom Tromey <[hidden email]> wrote:

Yes, sorry about this.
It's being fixed in bug#28003.

From my testing, this commit has fixed the issues I mentioned earlier: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=81656add8117e8d1b7faab18b330d0706462b433
 
Thanks!
--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Breaking change with auto-filling in Org mode with recent commit

Kaushal Modi
On Thu, Aug 10, 2017 at 1:54 PM Kaushal Modi <[hidden email]> wrote:
From my testing, this commit has fixed the issues I mentioned earlier: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=81656add8117e8d1b7faab18b330d0706462b433
 
Thanks!

Hi Tom,

I replied too soon.

I found this use case which is still broken, in emacs-lisp-mode:

==== 
(defcustom foo-boolean nil
  "Some foo variable.
Some long description that needs to be auto-filled and will span multiple lines."
  :group 'foo
  :type 'boolean)
=====

With the point anywhere in the doc-string, hit M-q. You will get:

=====
(defcustom foo-boolean nil
  "Some foo variable.
Some long description that needs to be auto-filled and will span
  multiple lines."  :group 'foo :type 'boolean)
=====

But actually this should have happened:

=====
(defcustom foo-boolean nil
  "Some foo variable.
Some long description that needs to be auto-filled and will span
multiple lines."
  :group 'foo
  :type 'boolean)
=====
--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Breaking change with auto-filling in Org mode with recent commit

Noam Postavsky-2
On Thu, Aug 10, 2017 at 5:34 PM, Kaushal Modi <[hidden email]> wrote:

>
> I found this use case which is still broken, in emacs-lisp-mode:
>
> ====
> (defcustom foo-boolean nil
>   "Some foo variable.
> Some long description that needs to be auto-filled and will span multiple
> lines."
>   :group 'foo
>   :type 'boolean)
> =====
>
> With the point anywhere in the doc-string, hit M-q. You will get:
>
> =====
> (defcustom foo-boolean nil
>   "Some foo variable.
> Some long description that needs to be auto-filled and will span
>   multiple lines."  :group 'foo :type 'boolean)
> =====
>
> But actually this should have happened:
>
> =====
> (defcustom foo-boolean nil
>   "Some foo variable.
> Some long description that needs to be auto-filled and will span
> multiple lines."
>   :group 'foo
>   :type 'boolean)
> =====

This is Bug#24622 I think.

Loading...