noctuid / emacs-sentence-navigation Goto Github PK

hi noctuid, is this library still alive?

it works for me (on 28.1), despite the other issue saying its broken.

i have been starting to port some break/non-break rules from OmegaT and the Okapi Framework into elisp: https://codeberg.org/martianh/segment, for use in some basic translation functionality in Emacs. One of the benefits of using such rules is that there are sets for different languages. Another one is that each rule has two regexes, one looking backward and one looking foward, which makes it possible to break when a given abbreviation ends a sentence, and not break when it doesn't.

I'm wondering whether I should work on making them (particularly the after break regexes) work with this library or if its better to start over from scratch.

I'm not positive on this, but I was trying out this package and noticed that evil's sentence backward motion did work while none from this package didn't in the following situation.

emacs: try sentence-navigation package

# Please enter the commit message for your changes. |Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your branch is ahead of 'origin/master' by 4 commits.
#   (use "git push" to publish your local commits)
#
# Changes to be committed:
#	modified:   emacs/.emacs.d/inits/conf/evil.el
#

Where | denotes the cursor (the second sentence in the commit instructions comment), it's not posible to jump back to the beginning of the first sentence. A cursory skim of the readme leads me to believe that it's because the beginning of a sentence is detected by a capital letter at the beginning of a line:

By default, this package assumes that a capital letter at the beginning of the line starts a sentence.

I did try enabling hard wrapping but of course that requires modification of the alist as well.

I was just wondering if I'm doing it the wrong way.

My Environment

• OS: MX Linux 18
• $ uname -r: 4.19.0-5-amd64
• dotfiles
• i3wm version 4.13
• ~/.config/i3
• GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2019-11-19
• ~/.emacs.d

Issue

All sentence-nav commands are broken and not executed at all. I only this message: rx--translate-symbol: Unknown rx symbol ‘maybe-sentence-end’.

Add metadata and make melpa recipe.. and clean it up a bit before that.

• MX Linux 17
• GNU Emacs 26.1
• init.el
• sentence navitagion 20180408.1619

I'm sorry if that's a basic question, but I can't understand Emacs regex. I want to add the comma , and maybe other characters as stops for the sentence navigation. I suppose this should go to sentence-nav--sentence-end-search or sentence-nav--sentence-search, but I can't get it to work. How could I add this functionality?

There is a bug when you select objects that aren't sentences.

When I have text that isn't a sentence vis doesn't select anything and vas selects too much.

For instance:

def some_func(argument_1, argument_2):
    pass

When I'm anywhere in this snippet, the as motion will select everything in this paragraph and up to the beginning of the document.

Another example:

THE TERMINATOR
(deadpan)
Hasta la vista. Baby.

Here it would be great if sentence-navigation could recognize (deadpan) and THE TERMINATOR as sentences as well.

I don't know, it seems this is a feature request rather than a bug report.

Sentence navigation doesn't work correctly in org-mode with letters and numeric outline that is cascaded. The example below will skip straight from 1. to 2. and not go to a.

Is there a way to get this to work correctly in org-mode or I can just use org-forward sentence. In regulare text-mode, your commands are much better. I just think the cascaded outlining is confusing the navigation. Also, I tried with sentence-nav-hard-wrapping set to t but that didn't help.

It seems the commands for sentence-nav-forward-eng work better than the regular commans but still skip over the a. or b. in the lists that are indented.

Consider ! and ? and 。 to always be the end of a sentence. Deal with ... and actual ellipsis characters. Consider nested quotations.

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?