I confirm that there still is following problem on 27.1.91.
Could someone take a look and show me work around?
> I am using emacs 27.1 with orgtbl-mode. On certain condition, typing
> <deletechar> distorts alighment of a table. Then, typing <up> moves
> previous line but far right position.
>
> | | rownames | | | rownames |
> | / | <l> | | / | <l> |
> |---+----------| -> |---+----------|
> | / | a | | | a |
>
> Here is a recipe to reproduce the glitch started from emcas -Q. I
> hope that together with bug#45091, this would be fixed before 27.2.
>
> 1. Create a buffer with (text-mode) and yank following table.
>
> | | rownames |
> | / | <l> |
> |---+----------|
> | | a |
>
> 2. (progn (require 'org) (call-interactively 'orgtbl-mode))
> 3. Move point to the first column and the third line with letter 'a'.
> 4. Hit <S-return>.
> 5. Hit <deletechar>.
> 6. Hit <up>.
Tak Kunihiro <homeros.misasa@gmail.com> writes: > I confirm that there still is following problem on 27.1.91. > Could someone take a look and show me work around? I cannot reproduce this with latest Org stable version 9.4.5. Can you try again and report? See https://orgmode.org/org.html#Installation on how to install using Org’s git repository if you want to try the latest version.
>> I confirm that there still is following problem on 27.1.91. >> Could someone take a look and show me work around? > > I cannot reproduce this with latest Org stable version 9.4.5. > > Can you try again and report? I downloaded Org 9.4.5 and reproduced the problem on 26.3, 27.2, and 28.0.50. Here is a recipe again. > On certain condition, typing <deletechar> distorts alignment of > a table. Then, typing <up> moves point to previous line but far > right position (column 14 instead of column 2). > > | | rownames | | | rownames | > | / | <l> | | / | <l> | > |---+----------| -> |---+----------| > | / | a | | | a | > > Here is a recipe to reproduce the glitch started from emcas -Q. > > 1. Create a buffer with (text-mode) and yank following table. > > | | rownames | > | / | <l> | > |---+----------| > | | a | > > 2. (progn (require 'org) (call-interactively 'orgtbl-mode)) > 3. Move point to the first column and the third line with letter 'a'. > 4. Hit <S-return>. > 5. Hit <deletechar>. > 6. Hit <up>.
I confirm that there is still problem with org-table
on Emacs 29.0.50 with org-version 9.5.
I created a function to produce the problem as shown below.
Can you try again?
(defun emacs-bug-reproduce-45915 ()
"Reproduce bug#45915."
;; (gnus-read-ephemeral-emacs-bug-group 45915)
(interactive)
(with-current-buffer (get-buffer-create "*temp buffer*")
(erase-buffer)
(require 'org)
(orgtbl-mode 1)
(insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version))
(insert "| | rownames |
| / | <l> |
|---+----------|
| | a |"))
(switch-to-buffer-other-window "*temp buffer*")
(execute-kbd-macro (kbd "M-< C-n C-n C-n C-n C-f C-f"))
(message "I will hit S-<return>.")
(sit-for 2)
(execute-kbd-macro (kbd "S-<return>"))
(message "I will hit <delete>.")
(sit-for 2)
(execute-kbd-macro (kbd "<delete>"))
(message "I will call previous-line.")
(sit-for 2)
(call-interactively 'previous-line))
;;; (call-interactively 'emacs-bug-reproduce-45915)
>>> I confirm that there still is following problem on 27.1.91.
>>> Could someone take a look and show me work around?
>>
>> I cannot reproduce this with latest Org stable version 9.4.5.
>>
>> Can you try again and report?
>
> I downloaded Org 9.4.5 and reproduced the problem on 26.3, 27.2,
> and 28.0.50. Here is a recipe again.
>
>> On certain condition, typing <deletechar> distorts alignment of
>> a table. Then, typing <up> moves point to previous line but far
>> right position (column 14 instead of column 2).
>>
>> | | rownames | | | rownames |
>> | / | <l> | | / | <l> |
>> |---+----------| -> |---+----------|
>> | / | a | | | a |
>>
>> Here is a recipe to reproduce the glitch started from emcas -Q.
>>
>> 1. Create a buffer with (text-mode) and yank following table.
>>
>> | | rownames |
>> | / | <l> |
>> |---+----------|
>> | | a |
>>
>> 2. (progn (require 'org) (call-interactively 'orgtbl-mode))
>> 3. Move point to the first column and the third line with letter 'a'.
>> 4. Hit <S-return>.
>> 5. Hit <deletechar>.
>> 6. Hit <up>.
I confirm that there still is the problem with org-table on Emacs
28.0.90 pretest with org-version 9.5.1.
Here is a recipe to reproduce the problem. I still have to stick to
26.3.
1. emacs -Q
2. (defun emacs-bug-reproduce-45915 () ...)
3. (call-interactively 'emacs-bug-reproduce-45915)
(defun emacs-bug-reproduce-45915 ()
"Reproduce bug#45915."
;; (gnus-read-ephemeral-emacs-bug-group 45915)
(interactive)
(with-current-buffer (get-buffer-create "*temp buffer*")
(erase-buffer)
(require 'org)
(orgtbl-mode 1)
(insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version))
(insert "| | rownames |
| / | <l> |
|---+----------|
| | a |"))
(switch-to-buffer-other-window "*temp buffer*")
(execute-kbd-macro (kbd "M-< C-n C-n C-n C-n C-f C-f"))
(message "I will hit S-<return>.")
(sit-for 2)
(execute-kbd-macro (kbd "S-<return>"))
(message "I will hit <delete>.")
(sit-for 2)
(execute-kbd-macro (kbd "<delete>"))
(message "I will call previous-line.")
(sit-for 2)
(call-interactively 'previous-line))
> I confirm that there is still problem with org-table
> on Emacs 29.0.50 with org-version 9.5.
>
>>>> I confirm that there still is following problem on 27.1.91.
>>>> Could someone take a look and show me work around?
>>>
>>> I cannot reproduce this with latest Org stable version 9.4.5.
>>>
>>> Can you try again and report?
>>
>> I downloaded Org 9.4.5 and reproduced the problem on 26.3, 27.2,
>> and 28.0.50. Here is a recipe again.
>>
>>> On certain condition, typing <deletechar> distorts alignment of
>>> a table. Then, typing <up> moves point to previous line but far
>>> right position (column 14 instead of column 2).
>>>
>>> | | rownames | | | rownames |
>>> | / | <l> | | / | <l> |
>>> |---+----------| -> |---+----------|
>>> | / | a | | | a |
>>>
>>> Here is a recipe to reproduce the glitch started from emcas -Q.
>>>
>>> 1. Create a buffer with (text-mode) and yank following table.
>>>
>>> | | rownames |
>>> | / | <l> |
>>> |---+----------|
>>> | | a |
>>>
>>> 2. (progn (require 'org) (call-interactively 'orgtbl-mode))
>>> 3. Move point to the first column and the third line with letter 'a'.
>>> 4. Hit <S-return>.
>>> 5. Hit <deletechar>.
>>> 6. Hit <up>.
[-- Attachment #1: Type: text/plain, Size: 309 bytes --] Tak Kunihiro <homeros.misasa@gmail.com> writes: > I confirm that there still is the problem with org-table on Emacs > 28.0.90 pretest with org-version 9.5.1. > > Here is a recipe to reproduce the problem. I still have to stick to > 26.3. I was able to reproduce. Can you try the attached fix? Best, Ihor [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-org-table.el-Fix-orgtbl-mode-not-remapping-delete-ke.patch --] [-- Type: text/x-diff, Size: 1090 bytes --] From 7b1a7d43e090292b6bd821c65a644f8c599b2044 Mon Sep 17 00:00:00 2001 Message-Id: <7b1a7d43e090292b6bd821c65a644f8c599b2044.1639918362.git.yantar92@gmail.com> From: Ihor Radchenko <yantar92@gmail.com> Date: Sun, 19 Dec 2021 20:49:54 +0800 Subject: [PATCH] org-table.el: Fix orgtbl-mode not remapping delete key * lisp/org-table.el (orgtbl-setup): Remap `delete-forward-char' in addition to `deleta-char'. The former is called in Emacs >26. Fixes https://orgmode.org/list/1AD1B9B7-5A15-4F86-9274-B04B83694C85@misasa.okayama-u.ac.jp --- lisp/org-table.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/org-table.el b/lisp/org-table.el index 1546cd563..0560e32a1 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -5290,6 +5290,7 @@ (defun orgtbl-setup () (org-remap orgtbl-mode-map 'self-insert-command 'orgtbl-self-insert-command 'delete-char 'org-delete-char + 'delete-forward-char 'org-delete-char 'delete-backward-char 'org-delete-backward-char) (org-defkey orgtbl-mode-map "|" 'org-force-self-insert)) t)) -- 2.32.0
Dear Ihor
Thank you for the patch. I applied the patch to org-table.el on Emacs
28.0.90.
And I still see the problem there. Is the problem solved by the patch
on your environment?
Tak
Ihor Radchenko <yantar92@gmail.com> writes:
> Tak Kunihiro <homeros.misasa@gmail.com> writes:
>
>> I confirm that there still is the problem with org-table on Emacs
>> 28.0.90 pretest with org-version 9.5.1.
>>
>> Here is a recipe to reproduce the problem. I still have to stick to
>> 26.3.
>
> I was able to reproduce. Can you try the attached fix?
>
> Best,
> Ihor
>
> From 7b1a7d43e090292b6bd821c65a644f8c599b2044 Mon Sep 17 00:00:00 2001
> Message-Id: <7b1a7d43e090292b6bd821c65a644f8c599b2044.1639918362.git.yantar92@gmail.com>
> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Sun, 19 Dec 2021 20:49:54 +0800
> Subject: [PATCH] org-table.el: Fix orgtbl-mode not remapping delete key
>
> * lisp/org-table.el (orgtbl-setup): Remap `delete-forward-char' in
> addition to `deleta-char'. The former is called in Emacs >26.
>
> Fixes https://orgmode.org/list/1AD1B9B7-5A15-4F86-9274-B04B83694C85@misasa.okayama-u.ac.jp
> ---
> lisp/org-table.el | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lisp/org-table.el b/lisp/org-table.el
> index 1546cd563..0560e32a1 100644
> --- a/lisp/org-table.el
> +++ b/lisp/org-table.el
> @@ -5290,6 +5290,7 @@ (defun orgtbl-setup ()
> (org-remap orgtbl-mode-map
> 'self-insert-command 'orgtbl-self-insert-command
> 'delete-char 'org-delete-char
> + 'delete-forward-char 'org-delete-char
> 'delete-backward-char 'org-delete-backward-char)
> (org-defkey orgtbl-mode-map "|" 'org-force-self-insert))
> t))
Tak Kunihiro <homeros.misasa@gmail.com> writes:
> Thank you for the patch. I applied the patch to org-table.el on Emacs
> 28.0.90.
>
> And I still see the problem there. Is the problem solved by the patch
> on your environment?
The problem was solved on my side, but _not_ using your reproducer
explicitly. If I save the buffer from your reproducer as a file and
later open in, the patch does solve the problem. However, when I run the
reproducer as is, a similar-looking problem emerges.
Using your reproducer, something very strange is going on.
With the patch, <delete> is correctly mapped to org-delete-char, which
calls (delete-char 1) at some point. However, this (delete-char 1)
somehow deletes 2!! chars instead of 1. This should be some tricky Emacs
issue (bug?). In any case, I am not ready to dig into what is going on
in Emacs. I do not think that such problem is going to appear during
normal Emacs usage. At least, I was unable to reproduce it by other
means than your reproducer function.
To illustrate the issue, one can use the following version of the
reproducer. Feel free to report this to Emacs upstream.
(defun emacs-bug-reproduce-45915 ()
"Reproduce bug#45915."
;; (gnus-read-ephemeral-emacs-bug-group 45915)
(interactive)
(with-current-buffer (get-buffer-create "*temp buffer*")
(erase-buffer)
(require 'org)
(orgtbl-mode 1)
(insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version))
(insert "| | rownames |
| / | <l> |
|---+----------|
| | a |"))
(switch-to-buffer-other-window "*temp buffer*")
(execute-kbd-macro (kbd "M-< C-n C-n C-n C-n C-f C-f"))
(message "I will hit S-<return>.")
(sit-for 2)
(execute-kbd-macro (kbd "S-<return>"))
(message "I will hit <delete>.")
(sit-for 2)
;; (execute-kbd-macro (kbd "<delete>"))
(delete-char 1)
(message "I will call previous-line.")
(sit-for 2)
(call-interactively 'previous-line))
Best,
Ihor
Tak Kunihiro <homeros.misasa@gmail.com> writes:
> Thank you for the patch. I applied the patch to org-table.el on Emacs
> 28.0.90.
>
> And I still see the problem there. Is the problem solved by the patch
> on your environment?
The problem was solved on my side, but _not_ using your reproducer
explicitly. If I save the buffer from your reproducer as a file and
later open in, the patch does solve the problem. However, when I run the
reproducer as is, a similar-looking problem emerges.
Using your reproducer, something very strange is going on.
With the patch, <delete> is correctly mapped to org-delete-char, which
calls (delete-char 1) at some point. However, this (delete-char 1)
somehow deletes 2!! chars instead of 1. This should be some tricky Emacs
issue (bug?). In any case, I am not ready to dig into what is going on
in Emacs. I do not think that such problem is going to appear during
normal Emacs usage. At least, I was unable to reproduce it by other
means than your reproducer function.
To illustrate the issue, one can use the following version of the
reproducer. Feel free to report this to Emacs upstream.
(defun emacs-bug-reproduce-45915 ()
"Reproduce bug#45915."
;; (gnus-read-ephemeral-emacs-bug-group 45915)
(interactive)
(with-current-buffer (get-buffer-create "*temp buffer*")
(erase-buffer)
(require 'org)
(orgtbl-mode 1)
(insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version))
(insert "| | rownames |
| / | <l> |
|---+----------|
| | a |"))
(switch-to-buffer-other-window "*temp buffer*")
(execute-kbd-macro (kbd "M-< C-n C-n C-n C-n C-f C-f"))
(message "I will hit S-<return>.")
(sit-for 2)
(execute-kbd-macro (kbd "S-<return>"))
(message "I will hit <delete>.")
(sit-for 2)
;; (execute-kbd-macro (kbd "<delete>"))
(delete-char 1)
(message "I will call previous-line.")
(sit-for 2)
(call-interactively 'previous-line))
Best,
Ihor
Dear Ihor,
> However, this (delete-char 1) somehow deletes 2!! chars instead of
> 1. This should be some tricky Emacs issue (bug?). In any case, I am
> not ready to dig into what is going on in Emacs. I do not think that
> such problem is going to appear during normal Emacs usage. At least, I
> was unable to reproduce it by other means than your reproducer
> function.
>
> To illustrate the issue, one can use the following version of the
> reproducer. Feel free to report this to Emacs upstream.
(defun emacs-bug-reproduce-45915 ()
"Reproduce bug#45915."
;; (gnus-read-ephemeral-emacs-bug-group 45915)
(interactive)
(with-current-buffer (get-buffer-create "*temp buffer*")
(erase-buffer)
(require 'org)
(orgtbl-mode 1)
(insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version))
(insert "| | rownames |
| / | <l> |
|---+----------|
| | a |"))
(switch-to-buffer-other-window "*temp buffer*")
(execute-kbd-macro (kbd "M-< C-n C-n C-n C-n C-f C-f"))
(message "I will hit S-<return>.")
(sit-for 2)
(execute-kbd-macro (kbd "S-<return>"))
(message "I will hit <delete>.")
(sit-for 2)
;; (execute-kbd-macro (kbd "<delete>"))
(delete-char 1)
(message "I will call previous-line.")
(sit-for 2)
(call-interactively 'previous-line))
I still see the problem with GNU Emacs 29.0.50 (build 8,
x86_64-apple-darwin21.5.0, NS appkit-2113.50 Version 12.4 (Build 21F79))
of 2022-05-23 with org-version 9.5.3.
I create org-tables and revise these everyday. On duplication of a
cell, I hit S-<return> often. The problem occurs, with my use case, once
in 5 minutes. IOW point moves unexpectedly once in 5 minutes.
I think that there is an issue in `org-table-copy-down'. However, I
cannot tell what specifically is not good.
Is this issue of Emacs instead of Org?
Tak Kunihiro <homeros.misasa@gmail.com> writes:
> I still see the problem with GNU Emacs 29.0.50 (build 8,
> x86_64-apple-darwin21.5.0, NS appkit-2113.50 Version 12.4 (Build 21F79))
> of 2022-05-23 with org-version 9.5.3.
>
> I create org-tables and revise these everyday. On duplication of a
> cell, I hit S-<return> often. The problem occurs, with my use case, once
> in 5 minutes. IOW point moves unexpectedly once in 5 minutes.
To clarify, I haven't applied the patch onto Org upstream.
Before the patch, the table is distorted because of an omission in Org.
After the patch, the table is distorted only using your reproducer
specifically, and the issue appears to be on Emacs side.
Best,
Ihor
Ihor Radchenko <yantar92@gmail.com> writes:
> To clarify, I haven't applied the patch onto Org upstream.
> Before the patch, the table is distorted because of an omission in Org.
> After the patch, the table is distorted only using your reproducer
> specifically, and the issue appears to be on Emacs side.
I now applied the patch onto main via 65e19a081.
This should solve part of the problem.
The remaining part should be solved on Emacs side (AFAIU).
Best,
Ihor
As Ihor pointed out, delete-char deletes two letters. Can someone take a look and evaluate if this is issue with delete-char? I simplified the recipes as shown below. #+begin_src emacs-lisp (defun emacs-bug-reproduce-45915 () "Reproduce bug#45915." ;; (gnus-read-ephemeral-emacs-bug-group 45915) (interactive) (with-current-buffer (get-buffer-create "*temp buffer*") (erase-buffer) (require 'org) (orgtbl-mode 1) (insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version)) (insert "| 1 |")) (switch-to-buffer-other-window "*temp buffer*") (execute-kbd-macro (kbd "M-< C-n C-f C-f")) (message "I will hit <S-return>.") (sit-for 2) (execute-kbd-macro (kbd "<S-return>")) (sit-for 2) (message "I will hit <delete>.") (sit-for 2) (execute-kbd-macro (kbd "<delete>")) (message "Two letters were deleted unexpectedly.")) ;;; (call-interactively 'emacs-bug-reproduce-45915) #+end_src
I confirmed that delete-char still deletes two letters on emacs-version: 28.2, org-version: 9.5.5. I found out (org-table-align) in (org-table-copy-down) makes this situation. Can someone take a look (org-table-align)? TIA #+begin_src emacs-lisp (defun emacs-bug-reproduce-45915 () "Reproduce bug#45915." ;; (gnus-read-ephemeral-emacs-bug-group 45915) (interactive) (with-current-buffer (get-buffer-create "*temp buffer*") (erase-buffer) (require 'org) (orgtbl-mode 1) (insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version)) (insert "| 1 |")) (switch-to-buffer-other-window "*temp buffer*") (execute-kbd-macro (kbd "M-< C-n C-f C-f")) (message "I will call #'org-table-copy-down.") (sit-for 2) (call-interactively #'org-table-copy-down) (sit-for 2) (message "I will hit <delete>.") (sit-for 2) (execute-kbd-macro (kbd "<delete>")) (message "Two letters were deleted unexpectedly.")) ;;; (call-interactively 'emacs-bug-reproduce-45915) #+end_src
Eli Zaretskii <eliz@gnu.org> writes: >> I don't think this is the right solution. One possible solution that >> is better is to bind <Delete> to an org-table specific command, which >> would insert some character displayed as a thin space between the two >> spaces that have the 'display' property. But I'll let Ihor chime in. > > One other possibility is to use a slightly different :relative-width > factor for the two spaces in a table cell: one with the value of 1, > the other with 1.001 (say). They will be indistinguishable on > display, but since the values are not equal, both stretch gfyphs will > be displayed, not just one. This is a good idea. I used it to fix the reported issue. Fixed on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9dde82411aefe5a6728eef95c3629dbf266fefa5 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp,
> 45915@debbugs.gnu.org, emacs-orgmode@gnu.org
> Date: Thu, 22 Sep 2022 20:03:55 +0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > One other possibility is to use a slightly different :relative-width
> > factor for the two spaces in a table cell: one with the value of 1,
> > the other with 1.001 (say). They will be indistinguishable on
> > display, but since the values are not equal, both stretch gfyphs will
> > be displayed, not just one.
>
> This is a good idea. I used it to fix the reported issue.
>
> Fixed on main.
Great. So I guess this bug report can be closed?
>>> One other possibility is to use a slightly different :relative-width
>>> factor for the two spaces in a table cell: one with the value of 1,
>>> the other with 1.001 (say). They will be indistinguishable on
>>> display, but since the values are not equal, both stretch gfyphs will
>>> be displayed, not just one.
>>
>> This is a good idea. I used it to fix the reported issue.
>>
>> Fixed on main.
>
> Great. So I guess this bug report can be closed?
Nice. Yes, please close this bug report.
> Date: Fri, 23 Sep 2022 06:36:58 +0900 (JST)
> Cc: yantar92@gmail.com, homeros.misasa@gmail.com, 45915@debbugs.gnu.org,
> emacs-orgmode@gnu.org, tkk@misasa.okayama-u.ac.jp
> From: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
>
> >>> One other possibility is to use a slightly different :relative-width
> >>> factor for the two spaces in a table cell: one with the value of 1,
> >>> the other with 1.001 (say). They will be indistinguishable on
> >>> display, but since the values are not equal, both stretch gfyphs will
> >>> be displayed, not just one.
> >>
> >> This is a good idea. I used it to fix the reported issue.
> >>
> >> Fixed on main.
> >
> > Great. So I guess this bug report can be closed?
>
> Nice. Yes, please close this bug report.
Thanks, done.