Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

2017-12-22 Thread Nicolas Goaziou
Hello,

Nathan Aclander  writes:

> Now I'm curious, do you have an example list where this would be
> obviously confusing and ambiguous?

* Headline 1

** Sub-headline

- Plain list

  - Sub-list

  - Sub-item

[X]


If the point is at [X], any headline, plain-list or item could claim
`M-S-'. This can be confusing if the surrounding structure is not
visible around point.

Regards,

-- 
Nicolas Goaziou0x80A93738



Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

2017-12-10 Thread Nathan Aclander

Nicolas Goaziou  writes:
> This is confusing because it is ambiguous. The same point could
> correspond to a table, multiple lists, and multiple headings, all
> reclaiming S-M-left binding.

I think I agree with your point that having the S-M-left bindings
overloaded by other modes reclaiming S-M-left will get confusing.

However, I don't use the S-M-left binding, but rather call
org-shiftmetaleft or org-shiftmetaright, I've never used other minor
modes in sublist so I'm not sure if there are any that also re-purpose
the org-shiftmetaleft/right commands.

Now I'm curious, do you have an example list where this would be
obviously confusing and ambiguous?

> You can also define a function that does this and add it to
> `org-shiftmetaleft-hook' or `org-shiftmetaright-hook'.

Yup, I wrote a function that ends up doing this for me.

Nathan


signature.asc
Description: PGP signature


Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

2017-12-10 Thread Nicolas Goaziou
Hello,

Nathan Aclander  writes:

> Using ^ as point like you did, what I am expecting to happen is:
>
> Case 1:
>  
> * Heading
>
> - foo
>   - ^bar
> second bar line
>
> M-S-left/right moves
>
> - bar
>   second bar line 
>
> left and right.
>
> Case 2:
>
> - foo
>   - bar
> ^second bar line
>
> M-S-left/right moves
>
> - bar
>   second bar line 
>
> left and right.
>
> Case 3:
>   ...
>   some very long text
>   ^some very long text
>   some very long text
>   ...
>
> Whatever sub list that "some very long text" is part of should be moved
> left and right.
>
> None of these scenarios seem very confusing, and ( at least to me ) seem
> more consistent than the current behavior. Could you explain why you
> find adding this behavior would make this confusing?

This is confusing because it is ambiguous. The same point could
correspond to a table, multiple lists, and multiple headings, all
reclaiming S-M-left binding.

Of course, we could apply the change to the closest, i.e., the inner,
structure, but, in some cases, e.g. the third one, the context is not
obvious. You may end up ignoring if the whole section was shifted, or
just some random sub-list. 

I don't find this behaviour particularly satisfactory. OTOH, only
reacting when point is on item bullet's line is totally unambiguous.

> As a current workaround, what I have to do is:
>
> 1. save point
> 2. Go to the parent sub-list
> 3. Shift left or right
> 4. move point back to its previous location. 

You can also define a function that does this and add it to
`org-shiftmetaleft-hook' or `org-shiftmetaright-hook'.

I suggest to do that if you think that's better.

Regards,

-- 
Nicolas Goaziou0x80A93738



Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

2017-12-09 Thread Nathan Aclander

Allen Li  writes:
> I think what Nicolas is saying is this (^ is point):
>
> * ^Heading
>
> M-S-left/right works here.
>
> * Heading
> ^content text
>
> M-S-left/right does not work here.  Let’s assume that it does work
> here to be consistent with the feature/bug you are requesting.
>
> * Heading
>
> - foo
>   - bar
> ^second bar line
>
> M-S-left/right does not work here.  Let’s assume that it does work
> here per the feature/bug you are requesting.  Does it move bar, foo,
> or Heading?  What if the text is very long and you cannot see where
> you are?
>
>   ...
>   some very long text
>   ^some very long text
>   some very long text
>   ...
>
> What M-S-left/right does would be very confusing.

Using ^ as point like you did, what I am expecting to happen is:

Case 1:
 
* Heading

- foo
  - ^bar
second bar line

M-S-left/right moves

- bar
  second bar line 

left and right.

Case 2:

- foo
  - bar
^second bar line

M-S-left/right moves

- bar
  second bar line 

left and right.

Case 3:
  ...
  some very long text
  ^some very long text
  some very long text
  ...

Whatever sub list that "some very long text" is part of should be moved
left and right.

None of these scenarios seem very confusing, and ( at least to me ) seem
more consistent than the current behavior. Could you explain why you
find adding this behavior would make this confusing?

As a current workaround, what I have to do is:

1. save point
2. Go to the parent sub-list
3. Shift left or right
4. move point back to its previous location. 

Nathan


signature.asc
Description: PGP signature


Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

2017-12-09 Thread Allen Li
On Sat, Dec 9, 2017 at 4:41 PM, Nathan Aclander
 wrote:
>
> Nicolas Goaziou  writes:
>
>> I don't qualify this as a bug. These commands explicitly work when point
>> is at the beginning of an item. Indeed, the sub-item may be arbitrarily
>> large, contain tables... it would be confusing to move the whole
>> sub-list when its structure is out of sight.
>
> Why do you think it would be confusing to move the whole sub-list? Why
> would it be move confusing when the point is on the sub-item vs. when
> the point is on the parent item?
>
> I think the inconsistency is unintuitive here, and causes confusion. And
> I think since large sub-items already get moved when the point is
> at the beginning, it would make sense to also move them when the point
> is on the sub item.
>
> Nathan

I think what Nicolas is saying is this (^ is point):

* ^Heading

M-S-left/right works here.

* Heading
^content text

M-S-left/right does not work here.  Let’s assume that it does work
here to be consistent with the feature/bug you are requesting.

* Heading

- foo
  - bar
^second bar line

M-S-left/right does not work here.  Let’s assume that it does work
here per the feature/bug you are requesting.  Does it move bar, foo,
or Heading?  What if the text is very long and you cannot see where
you are?

  ...
  some very long text
  ^some very long text
  some very long text
  ...

What M-S-left/right does would be very confusing.



Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

2017-12-09 Thread Nathan Aclander

Nicolas Goaziou  writes:

> I don't qualify this as a bug. These commands explicitly work when point
> is at the beginning of an item. Indeed, the sub-item may be arbitrarily
> large, contain tables... it would be confusing to move the whole
> sub-list when its structure is out of sight.

Why do you think it would be confusing to move the whole sub-list? Why
would it be move confusing when the point is on the sub-item vs. when
the point is on the parent item?

I think the inconsistency is unintuitive here, and causes confusion. And
I think since large sub-items already get moved when the point is
at the beginning, it would make sense to also move them when the point
is on the sub item.

Nathan


signature.asc
Description: PGP signature


Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

2017-12-01 Thread Nicolas Goaziou
Hello,

Nathan Aclander  writes:

> When using lists in org like the following:
>
> - Item 1
>   - Sub-item 1
>   - Sub-item 1
> - Item 2
> - Item 3
>
> I can shift them left and right using ~org-shiftmetaright~ or
> ~org-shiftmetaleft~.
>
> This also works on the following list:
>
> - Item 1
>   - This is a very long sub-item that is definitely going to be longer
> than 80 characters.
>   - Sub-item 2
> - Item 2
> - Item 3
>
> When my cursor is on the second line ( the line that begins with "This
> is a very..." I can move the sub-item left and right as expected.
>
> When my cursor is on the third line ( the line that begins with "than
> 80..." I get a message saying:
>
> "user-error: This command is active in special context like tables,
> headlines or items"
>
> Because this *does* work when my cursor is on the above line, I know org
> knows how to handle multi line items. Therefore I think it's a bug that
> org doesn't recognize the cursor being inside a list when it is on the second
> line of a multi item list.

I don't qualify this as a bug. These commands explicitly work when point
is at the beginning of an item. Indeed, the sub-item may be arbitrarily
large, contain tables... it would be confusing to move the whole
sub-list when its structure is out of sight.

Regards,

-- 
Nicolas Goaziou



[O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

2017-12-01 Thread Nathan Aclander
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


When using lists in org like the following:

- - Item 1
  - Sub-item 1
  - Sub-item 1
- - Item 2
- - Item 3

I can shift them left and right using ~org-shiftmetaright~ or
~org-shiftmetaleft~.

This also works on the following list:

- - Item 1
  - This is a very long sub-item that is definitely going to be longer
than 80 characters.
  - Sub-item 2
- - Item 2
- - Item 3

When my cursor is on the second line ( the line that begins with "This
is a very..." I can move the sub-item left and right as expected.

When my cursor is on the third line ( the line that begins with "than
80..." I get a message saying:

"user-error: This command is active in special context like tables,
headlines or items"

Because this *does* work when my cursor is on the above line, I know org
knows how to handle multi line items. Therefore I think it's a bug that
org doesn't recognize the cursor being inside a list when it is on the second
line of a multi item list.

Hopefully I've explained myself clearly, this is my first time
submitting an org bug report. Thanks for the continuing effort going in
to org. 

Please CC me in responses as I'm not subscribed to this list.

Nathan

Emacs  : GNU Emacs 27.0.50 (build 7, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2017-11-20
Package: Org mode version 9.1.2 (release_9.1.2-40-g6ca906 @ 
/usr/local/share/emacs/27.0.50/lisp/org/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-fontify-whole-heading-line t
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-agenda-files 
'("/home/current_user/.emacs.d/org-gcal-calanders/schedule.org")
 org-startup-folded nil
 org-mode-hook '(highlight-sexp-mode (closure (t) nil (org-bullets-mode 1))
 #[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-show-block-all append local] 5]
 #[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes 
turn-on-flyspell)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-fontify-quote-and-verse-blocks t
 org-fontify-done-headline t
 org-occur-hook '(org-first-headline-recenter)
 org-structure-template-alist '(("e" "#+BEGIN_SRC emacs-lisp \n?\n#+END_SRC") 
("s" "#+BEGIN_SRC ?\n\n#+END_SRC")
("e" "#+BEGIN_EXAMPLE\n?\n#+END_EXAMPLE") ("q" 
"#+BEGIN_QUOTE\n?\n#+END_QUOTE")
("v" "#+BEGIN_VERSE\n?\n#+END_VERSE") ("V" 
"#+BEGIN_VERBATIM\n?\n#+END_VERBATIM")
("c" "#+BEGIN_CENTER\n?\n#+END_CENTER") ("C" 
"#+BEGIN_COMMENT\n?\n#+END_COMMENT")
("l" "#+BEGIN_EXPORT latex\n?\n#+END_EXPORT") 
("L" "#+LaTeX: ")
("h" "#+BEGIN_EXPORT html\n?\n#+END_EXPORT") 
("H" "#+HTML: ")
("a" "#+BEGIN_EXPORT ascii\n?\n#+END_EXPORT") 
("A" "#+ASCII: ") ("i" "#+INDEX: ?")
("I" "#+INCLUDE: %file ?"))
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers 
org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
 org-return-follows-link t
 org-open-non-existing-files t
 org-confirm-shell-link-function 'yes-or-no-p
 org-link-parameters '(("id" :follow org-id-open) ("rmail" :follow 
org-rmail-open :store org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link) 
("irc" :follow org-irc-visit :store org-irc-store-link)
   ("info" :follow org-info-open :export org-info-export 
:store org-info-store-link)
   ("gnus" :follow org-gnus-open :store org-gnus-store-link)
   ("docview" :follow org-docview-open :export 
org-docview-export :store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store 
org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export org-bbdb-export 
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link) ("file+sys") 
("file+emacs") ("doi" :follow org--open-doi-link)
   ("elisp" :follow org--open-elisp-link) ("file"