Fix visual line movement

[olnw]

Closes #91

Summary of Changes

Implement changes discussed in #91. I think this needs review from someone else, but I wanted to get the ball rolling.

New functions:

• symex--current-visual-line-bounds
• symex--current-visual-line-empty-p
• symex-select-nearest-in-visual-line

Removed functions:

• symex-select-nearest-in-line Maybe it's better to keep this function? With these changes, it won't be called by anything.

Also modified symex-previous-visual-line and symex-next-visual-line to use symex-select-nearest-in-visual-line.

Public Domain Dedication

• [X] In contributing, I relinquish any copyright claims on my contribution and freely release it into the public domain in the simple hope that it will provide value.

(Why: The freely released, copyright-free work in this repository represents an investment in a better way of doing things called attribution-based economics. Attribution-based economics is based on the simple idea that we gain more by giving more, not by holding on to things that, truly, we could only create because we, in our turn, received from others. As it turns out, an economic system based on attribution -- where those who give more are more empowered -- is significantly more efficient than capitalism while also being stable and fair (unlike capitalism, on both counts), giving it transformative power to elevate the human condition and address the problems that face us today along with a host of others that have been intractable since the beginning. You can help make this a reality by releasing your work in the same way -- freely into the public domain in the simple hope of providing value. Learn more about attribution-based economics at drym.org, tell your friends, do your part.)

[countvajhula]

Hi @olnw . Apologies for the delay in getting to this. I haven't been able to reproduce the issue you describe. For example, in this:

"|this_is_a_really_long_line
↪ _of_text"

... if there is a space at the end of the first visual line, then going down with gj does select _of_text.

... but if there isn't a space at the end of the first visual line (and just an _), then it doesn't move at all, because, even though it is going up and down by visual line, since it is in Symex state rather than Normal state, it must still end on a legitimate selection. Since this_is..._of_text is a single Lisp identifier in this case, not moving seems correct to me, although I'm curious if you've run into any problems with this behavior.

Oddly enough, even with your changes, the second case does not move for me, so that both of these cases behave the same with or without your changes.

Are you finding that the first case is also not moving the selection to the next visual line?

Out of curiosity, what is the value of the word-wrap variable?

[olnw]

Hey 👋

There wasn't meant to be a space in that string; I just formatted it in a misleading way (my bad). Also, to be clear, that was just chosen as an arbitrary example: this applies generally for wrapped lines.

I just tested with emacs -Q on the following config, and there is no movement without the space.

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)

(use-package symex
  :ensure t
  :config (symex-initialize)
  :bind ("s-;" . symex-mode-interface))

When I load Symex from my branch, the cursor does move after running symex-next-visual-line. word-wrap is nil, and this is Emacs 29.1.

Now, on whether this is desirable. My expectation was that the g [h/j/k/l] bindings were present as a matter of convenience, for when movement was desired that wouldn't necessarily leave point immediately before a symex.

In Symex state, g h and g l will simply run forward/backward-char, which could leave the cursor anywhere. On the other hand, g j and g k behave "strictly", and only move the cursor if that places it before a symex. This seems like an asymmetry, but maybe that isn't a problem.

Summary:

symex-previous(/next)-visual-line will…

Currently: Move up/down a visual line, then select the nearest symex, but only if that symex is on the current logical line.

This will not always move up/down a visual line, since the nearest symex may be on the previous/next visual line (after moving) but still the same logical line.

With these changes: Move up/down a visual line, then select the nearest symex, but only if that symex is on the current visual line.

This will always move up/down a visual line.

[olnw]

Since this is the intended behaviour, and if you don't think it should be changed, I'm happy if you want to close this issue.