somelauw / evil-org-mode Goto Github PK

Hi, it would be convenient to have text object help source code selection in babel env.

This issue was identified in Doom Emacs which uses https://github.com/hlissner/evil-org-mode instead. However I am duplicating the issue here in case it is a problem with this upstream repo.

Original issue description: -

When in a non-org buffer such as a fundamental buffer and using df<SPC> to delete up to and including the next space character, everything works as expected and in the same way that Vim works. However when in an Org mode buffer, using the same sequence deletes everything up to but not including the next space character.

Please note that df<SPC> denotes the sequence df followed by a press of the space bar.

As an example, consider the following sentence, where the pipe symbols denote the current point (on the letter "a"):

This is |a|n example.

If this is a non-org buffer then the result of df<SPC> will be:

This is example.

However doing exactly the same in an Org mode buffer produces:

This is  example.

(note the two spaces after "is").

This appears to be an issue with evil-org-delete which is not present in the base evil-delete.

Description:

^ doesn't work as expected, currently it duplicates the behaviour of pressing 0.

Expected behaviour:

Pressing ^ should move the cursor to the current lines first non-blank character.

Actual behaviour:

Pressing ^ moves the cursor to the beginning of the current line.

Cause:

^ is bound to org-beginning-of-line in this function:
evil-org--populate-base-bindings
https://github.com/Somelauw/evil-org-mode/blob/master/evil-org.el#L493

This function only moves the cursor to the beginning of the line when ^ is pressed.

Possible solution:

Removing the current ^ and $ bindings from:
evil-org--populate-base-bindings

Restores them to the default evil behaviour:
^ evil-first-non-blank and $ evil-end-of-line

Additional notes:

org-beginning-of-line has an alternate behaviour when the variable org-special-ctrl-a/e is set to t. That makes C-a toggle the cursor between the current lines beginning and the first non-blank character.

A similar behaviour occurs when C-e is pressed (in the default emacs state). Then the cursor jumps between the end of the headline and the end of the tag(s).

The org-{beginning,end}-of-line functions only seems to check for the key bindings C-a and C-e, therefore these functions alternate behaviour won't work with the evil bindings ^ and $.

Until I enter insert mode or press C-h c M-h, those keystrokes are not available in an org buffer.

My evil-org configuration

(use-package evil-org
  :ensure t
  :after (org evil)
  :config
  (add-hook 'org-mode-hook 'evil-org-mode)
  (add-hook 'evil-org-mode-hook
            (lambda ()
              (evil-org-set-key-theme)))
  (add-hook 'org-mode-hook
            (lambda ()
              (define-key evil-normal-state-local-map
                (kbd "TAB") (kbd "<tab>"))))
  (add-hook 'org-agenda-mode-hook
            (lambda ()
              (dolist (kv (list
                           (list (kbd "TAB") (kbd "<tab>"))
                           (list (kbd "RET") (kbd "<return>"))
                           (list (kbd "M-RET") (kbd "M-<return>"))
                           '("\M-S" org-save-all-org-buffers)
                           '("\M-F" org-agenda-follow-mode)))
                (define-key evil-motion-state-local-map
                  (car kv) (car (cdr kv))))))
  (require 'evil-org-agenda)
  (evil-org-agenda-set-keys))

When trying to use o and O (I haven't changed their default bindings from evil-org-open-below
and evil-org-open-above), I am getting the following error:

Symbol's function definition is void: case

My Emacs version is 24.5.1

I have not been able to debug as C-g cannot interupt the command. Has anyone else run into this and have any workaround?

Same functionality works fine with Emacs 26.3

I just want to swap a few of them:

(use-package evil-org
	:after org
	:config
	(add-hook 'org-mode-hook 'evil-org-mode)
	(add-hook 'evil-org-mode-hook
		  (lambda ()
		    (evil-org-set-key-theme)))
	(require 'evil-org-agenda)
	(evil-org-agenda-set-keys)
	(evil-define-key 'motion evil-org-mode-map
	  (kbd "i") 'org-agenda-clock-in
	  (kbd "o") 'org-agenda-clock-out
	  (kbd "x") 'org-agenda-clock-cancel
	  (kbd "I") 'org-agenda-diary-entry
	  (kbd "O") 'delete-other-windows
	  (kbd "X") 'org-agenda-bulk-action))

This doesn't seem to work. For org I see you can use evil-org-set-key-theme but I'm not sure how else I'd customize the org-agenda bindings.

With evil-org-mode, in org mode, H is evil-window-top, M is evil-window-middle, and L is evil-window-bottom.

In org agenda mode, with evil-org-mode, H is org-agenda-do-date-earlier, M is org-agenda-bulk-remove-all-marks, and L is org-agenda-do-date-later.

I want evil-window-top, evil-window-middle, and evil-window-bottom. How about binding gH to evil-window-top, gM to evil-window-middle, and gL to evil-window-bottom?

I've added the snippet in the README to my ~/.emacs file.

When I open an org file it seems to default to normal org-mode with evil-mode enabled.

I have to switch off evil-mode and then switch on evil-org.

Installed via MELPA. Not sure if it's a bug on my end or the feature isn't there yet?

Originally noticed by @Stebalien in syl20bnr/spacemacs#9010, but applies to evil-org too. In some cases, o(evil-org-open-below) and O(evil-org-open-above) continue item lists even when just below the list.

His original post explains the problem:

o (insert-item-below) can be very aggressive. For example, pressing o in either of the following states:

* Item
  - A
█

* Item
  - A

█

Opens a new item instead of opening a new line:

* Item
  - A
  - |

(in the second case, the cursor goes up).

When calling evil-org-open-links on a region with multiple links, I get:

evil-org-open-links: Symbol’s value as variable is void: org-link-search-failed

I'm using emacs 26.3 and org 9.3.6

Apparently, the variable org-link-search-failed is now named org-link--search-failed.
No idea when that change occurred, but replacing this in the function evil-org-generic-open-links seemed to work.

dd currently does not force a renumber and I think it is very intuitive that it should.

Running 25.3.1 on 64bit Arch Linux

I have the following evil-org config, with return bindings enabled:

(use-package evil-org
  :after org
  :hook ((org-mode . evil-org-mode)
         (evil-org-mode
          . (lambda () (evil-org-set-key-theme '(textobjects insert navigation additional todo return)))))

  :config

  (require 'evil-org-agenda)
  (evil-org-agenda-set-keys))

I believe the documentation say that if I press enter on an empty list item like this:

1. blah
2. |

It should make a blank line:

1. blah
|

But instead it does this:

1. blah
2. |
3. 

Repeatedly pressing enter keeps appending more numbers to the end of the list while keeping the cursor on 2.

Interestingly, this also seems to happen with 1), +, and maybe other lists, but doesn't happen with - lists.

Title seems self explanatory to me.

Thanks to anybody that tackles this. I have too many other projects atm, otherwise I would take a stab at it.

For motions like "vie" to work.

Enter the following text in your org-mode buffer.

Foo *bar* baz *quux*.

Foo =bar= baz =quux=.

Foo /bar/ baz /quux/.

Foo _bar_ baz _quux_.

Foo ~bar~ baz ~quux~.

Foo +bar+ baz +quux+.

Now try die key sequence on each bar. For markup + and = (which stand for code and verbatim respectively), die deletes the preceding text up to a previous paragraph, instead of just deleting contents inside markup. Deleting quux, however, works correctly.

I find the behaviour of paragraph text objects (ip and ap, which are defined in evil) not always intuitive/useful when used in org-mode. It often includes too much other content like headings and code blocks. In practice when you use ip or ap, it's more likely you want to use iE or aE (evil-org-inner/an-element). In fact, Emacs org-mode uses M-h for org-mark-element instead of org-mark-paragraph.

Should ip and ap perhaps be mapped to evil-org-inner-element and evil-org-an-element instead ofiE and aE?

Debugger entered--Lisp error: (file-error "https://melpa.org/packages/evil-org-20170622.1310.el" "Not fo$
  signal(file-error ("https://melpa.org/packages/evil-org-20170622.1310.el" "Not found"))                
  package-install-from-archive([cl-struct-package-desc evil-org (20170622 1310) "evil keybindings for or$
  mapc(package-install-from-archive ([cl-struct-package-desc evil-org (20170622 1310) "evil keybindings $
  package-download-transaction(([cl-struct-package-desc evil-org (20170622 1310) "evil keybindings for o$
  package-install(evil-org)                                                                              
  (if (package-installed-p package) nil (package-install package))                                       
  prelude-require-package(evil-org)                                                                      
  mapc(prelude-require-package (yafolding org evil-org evil-org-agenda))                                 
  prelude-require-packages((yafolding org evil-org evil-org-agenda))                                     
  eval-buffer(#<buffer  *load*-627407> nil "/home/chris/dotfiles/emacs/evilvanilla/.emacs.d/personal/cus$
  load-with-code-conversion("/home/chris/dotfiles/emacs/evilvanilla/.emacs.d/personal/custom.el" "/home/$
  load("/home/chris/dotfiles/emacs/evilvanilla/.emacs.d/personal/custom.el")                             
  mapc(load ("/home/chris/dotfiles/emacs/evilvanilla/.emacs.d/personal/custom.el"))                      
  (progn (message "Loading personal configuration files in %s..." prelude-personal-dir) (mapc (quote loa$
  (if (file-exists-p prelude-personal-dir) (progn (message "Loading personal configuration files in %s..$
  eval-buffer(#<buffer  *load*> nil "/home/chris/dotfiles/emacs/evilvanilla/.emacs.d/init.el" nil t)  ; $
  load-with-code-conversion("/home/chris/dotfiles/emacs/evilvanilla/.emacs.d/init.el" "/home/chris/dotfi$
  load("/home/chris/dotfiles/emacs/evilvanilla/.emacs.d/init" t t)                                       
  #[0 "^H\205\266^@     \306=\203^Q^@\307^H\310Q\202?^@ \311=\204^^^@\307^H\312Q\202?^@\313\307\314\315#$
  command-line()                                                                                         
  normal-top-level()  

This occurs by adding the following to prelude/custom.el:
(prelude-require-packages '(yafolding org evil-org evil-org-agenda))

Any idea what might be the cause of this issue?

Runtime Environment

• MX Linux 17
• GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2018-11-28
• Evil version 1.2.14
• Evil Org Version: 20180323.2306
• .emacs.d
• packages

Use-package declaration

(use-package evil-org
  :ensure t
  :after org
  :config
  (add-hook 'org-mode-hook 'evil-org-mode)
  (add-hook 'evil-org-mode-hook
            (lambda ()
              (evil-org-set-key-theme)))
  (require 'evil-org-agenda)
  (evil-org-agenda-set-keys))

Issue

Whenever I run the command vie in normal mode to select an inner element, the command fails and I get the following message:

evil-org-select-inner-element: Symbol’s function definition is void: s-ends-with\?

From an org src buffer, :w does save the original file, but :wq just quits the buffer without saving the file.

A while ago tab stopped working correctly (could not fold/unfold drawers). It turned out that other people had the same issue: https://www.reddit.com/r/emacs/comments/aidi7r/cant_fold_logbook/
To fix it, I need to have this:

    (with-eval-after-load 'evil
      (evil-define-key 'normal outline-mode-map (kbd "<tab>") #'org-cycle)
      (evil-define-key 'normal outline-mode-map (kbd "TAB") #'org-cycle))

I also noticed that other keys are not bound correctly as well, like ) is bound to evil-forward-sentence-begin instead of evil-org-forward-sentence etc.

What could cause these issues? Does evil-org need an update or have I screwed up my config? :)

My evil-org config looks like this:

  (use-package evil-org
    :ensure t
    :after org
    :config
    (require 'evil-org-agenda)
    (with-eval-after-load 'evil
      (evil-define-key 'normal outline-mode-map (kbd "<tab>") #'org-cycle)
      (evil-define-key 'normal outline-mode-map (kbd "TAB") #'org-cycle))
    (evil-org-agenda-set-keys)
    (add-hook 'org-mode-hook 'evil-org-mode)
    (add-hook 'evil-org-mode-hook
              (lambda ()
                (evil-org-set-key-theme))))

I'm using emacs 27.0.91 with spacemacs develop branch, which integrates this package. On spacemacs, emacs hangs which I described in spacemacs's #13684:

Reproduction:

• Start Emacs
• create a .org file
• write something like

    * foo
      - bar
        1. put your cursor at this line
            barfoo
        2. foofoo

• place the cursor at line "put your cursor at this line"
• press "o"(evil-open-below)
• and then emacs freezes.

I haven't tested with a pure environment(e.g. only emacs, evil and this package), but i think it's reproducable.

I also track it down with edebug and found out emacs freezed when somewhere around

(defun org-list-write-struct (struct parents &optional old-struct)
    ;; ...
    ;; 6. Apply structure modifications to buffer.
    (org-list-struct-apply-struct struct old-struct))

evil-org-mode binds and , but it doesn't bind RET, and M-RET.
RET and M-RET are used in terminal.

Both README.org and doc/keythemes.org don't explain that navigation bindings are available only in motion mode.

I'd want to have navigation bindings in normal mode, too.

Currently shift is a key theme because shift+movement would override Evil's H, J, K and L.
What about a context-sensitive compromise?
Namely:

(defun evil-org-shiftleft ()
  (interactive)
  ;; TODO: Use `org-at-heading-or-item-p' instead?
  (if (org-on-heading-p)
      (org-shiftleft)
    (evil-window-top)))

(defun evil-org-shiftright ()
  (interactive)
  (if (org-on-heading-p)
      (org-shiftright)
    (evil-window-bottom)))

(defun evil-org-shiftup ()
  (interactive)
  (if (org-on-heading-p)
      (org-shiftup)
    (evil-lookup)))

(defun evil-org-shiftdown ()
  (interactive)
  (if (org-on-heading-p)
      (org-shiftdown)
    (call-interactively 'evil-join)))

evil-join is rarely needed on headings, so we don't lose much here.
For the others, it's enough to move away from a header. I think it's a good middle ground.

What's your take on this?

Debugger entered--Lisp error: (void-function obsolete)
  obsolete("Please create a github issue if you want to keep RSI bindings." "0.9.1")

So, here I am filing the issue - seems the obsolete call is not good.

Also, I'm not sure what the RSI bindings are, but it seems I may want to keep them 😄

The current dependency list on MELPA marks MELPA's Org as a dependency.

The package says Org 8.0 is enough. (Emacs 25 has a newer version.)

Is it possible to remove the MELPA's Org dependency?
Some users don't want an additional Org installed on their computer on every update:

• Those who don't mind Emacs embedded version of Org.

• Those who want org-plus-contrib for additional features like org-agenda.

• Those with slow connections or who mind heavy packages.

Sometimes I press o/O but don't want to continue the item list or table

For example

|---+---|
| 1 | 2 |
| 3 | 4 |
|---+---|

and now I want to write something below the table but end up with

|---+---|
| 1 | 2 |
| 3 | 4 |
|---+---|
|   |   |

Here are some ideas:

1. Set evil-org-special-o/O to nil and use M-ret instead
2. Train myself to use 1o (a prefix argument cancels evil-org-special-o/O)
3. Press C-S-backspace to get rid of the continuation
4. Make RET cancel empty rows and items lists (see http://kitchingroup.cheme.cmu.edu/blog/2017/04/09/A-better-return-in-org-mode/ for an example)

I'm currently looking into the fourth option and considering adding a function similar to John Kitchen's to evil-org-mode.

I would like RET to follow capture file links in normal mode. It seems like evil-org-return will do it, but it's only bound in insert mode or in emacs mode. The binding in normal mode is evil-return, which doesn't follow capture links, at least with my current config. Is there a way to make this happen?

Description

The cursor moves in 3 different ways at the end of a headline, when it's contents are hidden, and there is an empty line above, below or on neither side of the contents.

Scenario 1

No empty line above or below the contents.

* headline1
contents

The headlines contents are hidden:
* headline1...

With the cursor at the end of the line (on the first of the 3 dots),
Moving forwards l, moves the cursor to the right of the 3 dots.

The following probably isn't a common behaviour, but if one tries to move forwards, then the cursor jumps back to the first of the 3 dots.

In this state, trying to move forwards doesn't work, and trying to move backwards h requires 2 presses. And when the cursor moves, then it jumps 2 characters backwards. (info below) [1]

Setting evil-move-beyond-eol to t (default: nil), makes the cursor movements behave "normally", moving to the right stops at the end of the 3 dots, and moving to the left from the first of the 3 dots, works as expected.

Scenario 2

Empty line above the contents:

* headline1

contents

The headlines contents are hidden:
* headline1...

Trying to move forwards from the end of the line (on the first of the 3 dots) doesn't work, but this might be expected behaviour, there probably is no reason to move the cursor past the 3 dots. (suggestion below) [2]

Moving to the left from the first of the 3 dots makes the cursor jump 2 characters to the left, over the 1. (info below) [1]

Setting evil-move-beyond-eol to t (default: nil), doesn't stop the cursor on the first of the 3 dots. It jumps to the end of the 3 dots, and moving to the left works as expected.

Scenario 3

Empty line below the contents and a second headline below the first:

* headline1
contents

* headline2

Headline1s contents are hidden:

* headline1...
* headline2

Moving forwards from the end of the line, moves the cursor to the right of the 3 dots. Trying to move forwards does nothing (expected behaviour), but trying to move backwards h doesn't work (unexpected behaviour).

Setting evil-move-beyond-eol to t (default: nil), and trying to move left h, still keeps the cursor stuck at the end of the 3 dots.

[1] Cursor jumps back 2 characters at end of the line

This happens in all scenarios.

With the cursor is at the end of the line (on the first of 3 dots), moving the cursor backwards h makes it jump over the 1 in * headline1....

Setting evil-move-beyond-eol to t (default: nil), stops this behaviour.

[2] Should the cursor move past the 3 dots?

Maybe in all 3 scenarios, the cursor should stop moving forwards on the first of the 3 dots, since it's the end of the headline.

When the cursor is at the end of the 3 lines, then the mode line shows the cursors line and column position to be on the hidden contents. This can be dangerous. If one for example deletes some characters backwards X, then the characters are removed from the hidden contents. But any accidental changes won't be visible until the contents are shown again.

Using the recommended use-package definition, keys in org-agenda aren't bound when opening it for the first time (M-x org-agenda and pressing a). Only after closing the buffer with g and opening it again in the same way can I navigate lines with j and k.

I guess evil-org-agenda-set-keys needs to be run before the agenda is opened to be effective.

Default vim/EVIL behavior: given the text

foo
foo asdfsadf bar
baz

The following sequence of actions will add " hello" to every line.

1. 0 (go to the beginning of the line)
2. C-v (start visual block mode)
3. $ (go to the end of the line)
4. 2j (select 3 lines in visual block mode)
5. A
6. " hello"
7. ESC

However, in org mode with evil-org-mode activated this is broken because $ is bound to evil-org-end-of-line.
Binding it to evil-end-of-line restores correct behavior.

There does not seem to be a text object for a table column.

Just needed it now.

Repro:
Under an orgmode headline, SPC i l p (for spacemacs; but otherwise any long line of text that goes beyond the current screen width would do) but don't format it. S-i to the line beginning then add - (a minus sign, then a space) at the beginning of this long line. Then g q l failed.

This is unfortunately distinct from vim behavior. In vim, the first line has the leading - (2 chars), and the subsequent lines are nicely formatted to have 2-char indent as well.

Org-agenda does not have any Evil bindings. It bugs me to press n/p just for that buffer. Any
plan in that area?

When evil-org is enabled in a buffer, evil-surround's surround-delete stops working.

Without evil-org, the shortcut ds (delete surround) deletes the specified delimiters:
(| is cursor)
-- {somet|hing}
ds}
something

When evil-org is enabled, ds does not behaves as expected.

It apperrs that s enters evil-surround-edit with a parameter other then 'delete . It wants to add a surround and expects a movement to know which region to surround.

one { t|wo } three

next paragraph

ds} (understands } as paragraph movement )
} (now it with {} up to the next paragraph

one { t{wo } three
} 
next paragraph

Screencast:

init.el :

(package-initialize)

(require 'evil)
(require 'evil-org)
(require 'evil-surround)

(evil-mode 1)
(global-evil-surround-mode 1)

Package versions (installed from melpa):

• evil-org-20171107.1159
• evil-surround-20171127.910
• evil-20171126.659
• undo-tree-20170706.246
• goto-chg-20170917.1200

The latest use-package exposes helpers around creating hooks. The installation in the Readme can be simplified to:

(use-package evil-org
  :ensure t
  :after org
  :hook ((org-mode . evil-org-mode)
         (evil-org-mode . evil-org-set-key-theme))
  :config
  (require 'evil-org-agenda)
  (evil-org-agenda-set-keys))

Also if users have general.el installed, the install can be further simplified to:

(use-package evil-org
  :ensure t
  :after org
  :ghook 'org-mode-hook
  :gfhook #'evil-org-set-key-theme
  :config
  (require 'evil-org-agenda)
  (evil-org-agenda-set-keys))

I'm not sure if this is intended behaviour or not, but pressing o in the following situation inserts a line break instead of opening a list item:

- Nunc aliquet, augue nec adipiscing interdum, lacus tellus malesuada massa,
  quis varius mi purus non odio. Nullam rutrum. Donec neque quam, dignissim in,
  mollis nec, sagittis eu, wisi. Etiam vel tortor sodales tellus ultricies
  commodo. Fusce sagittis, libero non molestie mollis, magna orci ultrices
  dolor, at vulputate neque nulla lacinia eros.█

This could probably be solved by using org-in-item-p instead of org-at-item-p in evil-org-open-below and some other places, but again I'm not sure whether this was intentional or not.

At some point in the past :w in an org src buffer would update and save the underlying org-file, but this hasn't worked for some time now, and now throws user-error: Please specify a file name for the buffer.

The following binding (suggested in #43) adds this feature back:

(define-key org-src-mode-map [remap evil-write] 'org-edit-src-save)

I'm using org-plus-contrib-20190624 and evil-org-20180323.2306.

Given (where | is pointer)

worl|d

Pressing X gives

wo|ld

Expected

wor|d

Entering a time range using the org-time-stamp interactive function twice should automaticaly append the second one after 2 dashes like so:
<2019-06-08 Sat>--<2019-06-11 Tue>

Currently it will enter the following:
<2019-06-08 Sat--<2019-06-11 Tue>>

Notice the double angular brackets at the end. The closing one of the first time stamp is being pushed because on the second call of the interactive function, the result is being inserted instead of appended.

In emacs mode, calling twice this function in a row works as intended.

Problem

At the moment,
[[ mostly behaves like org-backward-element
]] mostly behaves like org-forward-element

These bindings aren't perfect, because if ]] is used on the penultimate element it jumps back instead.

For example

* main heading
** subheading1
** subheading2 (Pressing ]] here goes back to main heading instead of subheading3)
** subheading3

Solution

We can fix this by binding ]] directly to org-forward-element, but since we already have gj and gk for org-forward/backward-element, it might also be an option to bind them to something else.
One idea is to bind [[ to org-previous-visible-heading and ]] to org-next-visible-heading.

Question

What should [[ and ]] be bound to?
Also, what to do with [] and ][?

It seems https://github.com/Somelauw/evil-org-mode/tree/v0.1.1 is from 2014 :)

At the end of evil-org-mode.el, you've got:

;; Set customizable theme
(evil-org-set-key-theme evil-org-key-theme)

Should this not be removed? The example configurations suggest we use evil-org-set-key-theme ourselves. This means evil-org-set-key-theme will run twice in my session. This works, but is suboptimal.

In my case, my Emacs framework uses evil-org as a basis for its evil+org integration, and I'd like to support the evil-org-set-key-theme use case as documented, but it'd require a little advice/auxiliary keymap gymnastics to do so.

Alternatively, it could be guarded with, say:

(unless evil-org-key-theme
  (evil-org-set-key-theme))

Side note: in your more elaborate example, you're setting:

(setf evil-org-key-theme '(navigation insert textobjects additional))

But don't call evil-org-set-key-theme, so those settings are never actualized.

The documentation (and source code) for evil-org-> and evil-org-< imply that If I use them inside org tables, columuns will be moved in the right direction. The actual behavior I'm seeing is just that the whole table is indented.

Consider the following excerpt from an org file:

medium line
much longer line
short line

When I enter the visual block selection in the first line, move two lines down and then press $, only a rectangular region is marked instead of until the end of all three lines.

This is a different behavior compared to the one implemented in evil and vim.

Instead, z is bound to org-agenda-view-mode-dispatch, so I cannot press zt, zz, zb, and other keystrokes starting with z.

I think the text objects should have appropriate types. Either characterwise, linewise or blockwise. Currently, they are all characterwise.

I think that:

• inner/an-org-object (ie and ae) should be characterwise
• inner/an-org-subtree (iR and aR) should be linewise.

However, I'm not sure whether org-element (iE/aE) and org-greater-element (ir/ar) should be characterwise or linewise.

In most cases, these operator select whole lines. The only exception that I know of is the following:

- hello world█

vaE(characterwise) creates the following selection

- [hello world]

If we make them linewise, the "- " will be included in the selection:

[- hello world]

On the other hand making them linewise makes them more intuitive when combining them with evil-yank and evil-delete.

If we start from

* foe█
* bar

"yaEp"(linewise) gives the following result:

* foe 
* foe
* bar

instead of (characterwise):

* foe* foe
* bar