Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible to add support for org headings? #3

Closed
sooheon opened this issue Jun 2, 2016 · 2 comments
Closed

Possible to add support for org headings? #3

sooheon opened this issue Jun 2, 2016 · 2 comments

Comments

@sooheon
Copy link

sooheon commented Jun 2, 2016

I think handling of * in org can be improved. For example, with:

* Heading 1
Foo bar baz. Quux.

* Heading 2

das from Quux will delete the leading * of the next heading. das from Foo will delete text of Heading 1.

Org headings (prefixed by *) have the property that they will never hard wrap, even when manually calling M-q. So it's safe to assume that the newline of an org heading line is always the end of a sentence. Can we support this so that something matching the org heading regex is always a sentence in and of itself?

Also, what would it take to implement the impossible case in the readme for lines ending with period and next sentence beginning immediately in hard-wrapped buffers?

@noctuid
Copy link
Owner

noctuid commented Jun 3, 2016

Yeah this package could use some work. Right now it makes some dumb assumptions about the start of a sentence (e.g. it won't work with a sentence starting at the beginning of the buffer). For text that isn't hard-wrapped, it's easiest to just assume that a capital letter (or a left quote or something) at the beginning of the line always starts a sentence. For it to work with hard-wrapped text as well, I'll need to add a variable for regexps that can precede the start of a sentence for different modes. In org mode this would also include things like line comments and tables I guess. I don't really use hard-wrapping most of the time, so I never did this, but I'll fix this problem next time I get the chance.

noctuid added a commit that referenced this issue Aug 6, 2016
Improvements:
- Add tests
- Add a variable to customize how delimiters are treated (i.e. whether
  quotations are considered the start or end of a sentence)
- Add a variable to change the outer/inner text objects to
  include/exclude delimiters
- Allow regular emacs commands to take prefix counts
- Improve handling of comments
- Fix text object bugs (failing at the buffer end; outer text object
  selecting as much space as possible after the sentence)
- Positions are now added to the jump list for evil commands
- Fix cases where the point is in between sentences
- Be more lenient in deciding valid sentence beginnings (addresses #3;
  should work correctly with soft-wrapped sentences now)

Refactoring:
- Use a variable not a register to store positions
- Use forward-char and backward-char instead of
  left-char and right-char
- Fix looking-back warnings
- More precise jumping using submatch instead backpedaling
  (removes need for sentence-nav--maybe-before-sentence-start-p)
- Explicitly use cl-lib
- etc.
@noctuid
Copy link
Owner

noctuid commented Aug 31, 2016

Okay this example should now work as expected. I've made a lot of other improvements, so the behavior should be saner in general. Accurate support for hard-wrapped sentences is implemented and requires that sentence-nav-hard-wrapping is non-nil and that sentence-nav-non-sentence-line-alist is customized properly for the current major mode (which is fairly simple). I've added basic support for org mode. I'll flesh out the list of regexps for org mode and add support for markdown mode when I get the chance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants