Re: [O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi Michael, I fixed this again in maint, please let me know if it's now okay for you. Thanks, -- Bastien
Re: [O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi Bastien On Thu, Mar 20, 2014 at 3:15 PM, Bastien b...@gnu.org wrote: I fixed this again in maint, please let me know if it's now okay for you. Thanks, Yes, also release_8.2.5h-809-g61d still solves my use case with literal links in a table, thank you. I tested only GNU Emacs and can not tell for XEmacs. Michael
Re: [O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi Michael, Michael Brand michael.ch.br...@gmail.com writes: On Sat, Mar 1, 2014 at 12:13 PM, Bastien b...@gnu.org wrote: I see. The following patch fixes it but it's just a quick try, I need to review possible side-effects more carefully. In the meantime, if you can confirm it works for you, that'd help. The patch works, thank you. I'll continue to use it. I've now applied this patch, thanks for testing it so far. -- Bastien
Re: [O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi Michael, Michael Brand michael.ch.br...@gmail.com writes: is a regression for Shift-enter on 1 in the table below when hyperlinks are configured to be literal: | [[http://www.orgmode.org]] | 1 | | | [[http://www.orgmode.org]] | | | | [[http://www.orgmode.org]] | | | You mean when `bracket' is not part of `org-activate-links'? I can reproduce the problem... but it goes away when I instrument `org-move-to-column' for debugging. I'll have to digg deeper -- if you have more information on your side, please share. Thanks, -- Bastien
Re: [O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi Bastien On Sat, Mar 1, 2014 at 10:02 AM, Bastien b...@gnu.org wrote: Michael Brand michael.ch.br...@gmail.com writes: is a regression for Shift-enter on 1 in the table below when hyperlinks are configured to be literal: | [[http://www.orgmode.org]] | 1 | | | [[http://www.orgmode.org]] | | | | [[http://www.orgmode.org]] | | | You mean when `bracket' is not part of `org-activate-links'? I don't know if and how the variable org-activate-links is related. I used the function org-toggle-link-display or the menu to get the state with the variable org-descriptive-links being nil which is for display the full links literally. Michael
Re: [O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi Michael, Michael Brand michael.ch.br...@gmail.com writes: I don't know if and how the variable org-activate-links is related. I used the function org-toggle-link-display or the menu to get the state with the variable org-descriptive-links being nil which is for display the full links literally. I see. The following patch fixes it but it's just a quick try, I need to review possible side-effects more carefully. In the meantime, if you can confirm it works for you, that'd help. Thanks, diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 1553e4f..9837e13 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -344,9 +344,12 @@ Works on both Emacs and XEmacs. (indent-line-to column))) (defun org-move-to-column (column optional force buffer ignore-invisible) - (let ((buffer-invisibility-spec ignore-invisible)) + (let ((buffer-invisibility-spec + (and ignore-invisible + (member '(org-link) buffer-invisibility-spec (if (featurep 'xemacs) - (org-xemacs-without-invisibility (move-to-column column force buffer)) + (org-xemacs-without-invisibility + (move-to-column column force buffer)) (move-to-column column force (defun org-get-x-clipboard-compat (value) -- Bastien
Re: [O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi Bastien On Sat, Mar 1, 2014 at 12:13 PM, Bastien b...@gnu.org wrote: I see. The following patch fixes it but it's just a quick try, I need to review possible side-effects more carefully. In the meantime, if you can confirm it works for you, that'd help. The patch works, thank you. I'll continue to use it. Michael
Re: [O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi Bastien On Thu, Feb 6, 2014 at 9:59 AM, Bastien b...@gnu.org wrote: Jason Lewis ja...@dickson.st writes: when using the Shift-enter feature in a table to copy values down, it fails to place the cursor where you expect it to if the previous column has a fixed width and the contents of the cell is truncated. Fixed in maint, thanks for reporting this! The related commit commit 323c7b3de2211a7d61bf0c71c6f5923b1ea62297 Author: Bastien Guerry b...@altern.org Date: Thu Feb 6 09:58:17 2014 +0100 org-table.el: Fix bugs about cursor repositioning * org-table.el (org-table-copy-down) (org-table-find-dataline, org-table-move-row) (org-table-insert-hline, org-table-kill-row): Use `org-move-to-column' with the IGNORE-INVISIBLE arg set to `t', so that abbreviated rows don't interfer with setting the cursor back at the correct position. Thanks to Jason Lewis for reporting one of these bugs. is a regression for Shift-enter on 1 in the table below when hyperlinks are configured to be literal: | [[http://www.orgmode.org]] | 1 | | | [[http://www.orgmode.org]] | | | | [[http://www.orgmode.org]] | | | Michael
Re: [O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi Jason, Jason Lewis ja...@dickson.st writes: when using the Shift-enter feature in a table to copy values down, it fails to place the cursor where you expect it to if the previous column has a fixed width and the contents of the cell is truncated. Fixed in maint, thanks for reporting this! -- Bastien
