2

I'm a big fan of fill-paragraph, and also sentence-end-double-space being set to t so that I can easily navigate and edit via backward-sentence, forward-sentence, kill-sentence, transpose-sentences and so on.

However there is one minor flaw with this combination - if I hit M-q (i.e. fill-paragraph) on a paragraph like this:

This sentence ends with a wink ;-)  And it's followed by two spaces
then another sentence.

then it will trim one of the two spaces after the smiley, because it does not recognise the smiley as being the end of the sentence. Is there a clean way to fix it to preserve these two spaces, whilst not breaking the existing behaviour defined by the sentence-end function? I can think of three possibilities:

  1. Take the regexp generated by (sentence-end), tweak it to recognise smileys, and store it in the sentence-end variable - but then it's a static regexp which doesn't honour changes to variables like sentence-end-without-space.
  2. Copy the whole of the sentence-end function and then hack it to cope with smileys, but then I have to maintain my own version in parallel with the upstream one.
  3. Hack sentence-end as in 2. and then try to get the change merged upstream, but I don't know how realistic that is.

Are there any better options?

Improve this question
2
  • @Drew I included the 'elisp tag because options 2 and 3 involve hacking elisp - is that not a reasonable use of the tag?
    – Adam Spiers
    Sep 20, 2017 at 0:44
  • 1
    No, it's not. Tag elisp should be for questions about the Lisp language itself, specifically Emacs Lisp, not about how to do something using it.
    – Drew
    Sep 20, 2017 at 1:49

3 Answers 3

Reset to default
1

Based on your #1, it seems like you prefer not to set the option sentence-end because you still want the function sentence-end to generate a value that takes sentence-end-without-period, sentence-end-double-space, sentence-end-without-space into account.

In that case, you could set the user option sentence-end-base. Perhaps change the default value of [.?!…‽][]\"'”’)}]* to

(setq sentence-end-base "\\([.?!…‽][]\"'”’)}]*\\|[;:]-?[])]\\)")

depending on what your smiley habits are.

Improve this answer
1
  • Thanks, this looks like the cleanest and simplest solution to me! If I had been slightly more diligent and spent a few more seconds looking at the sentence-end function I'd have probably noticed this myself. BTW, that's an interesting trick for including ] inside a [...] character class; never seen that before. IIRC in other languages you can typically just escape it.
    – Adam Spiers
    Sep 21, 2017 at 9:54
0

Use variable sentence-end, not function sentence-end. The variable is even a user option, so you can customize it. You can also give it a buffer-local value, if you want.

See the Emacs manual, node Sentences.

Improve this answer
1
  • Sorry - that approach is exactly what I meant by option 1, but I now realise that I forgot to explicitly mention that the idea was to put the tweaked value in the sentence-end variable. I'll edit the question accordingly.
    – Adam Spiers
    Sep 20, 2017 at 0:42
0

You do not need to copy sentence-end. You can just add an advice:

(defun sentence-end-smileys (re)
  "Add smileys to sentence-end regexps returned by function `sentence-end'."
  (concat re "\\|[[:space:]]?[;:X]-[()]  "))

(advice-add #'sentence-end :filter-return #'sentence-end-smileys)
Improve this answer
3
  • Thanks, that's a nice trick although wouldn't it conflict with the sentence-end-double-space logic at the end of the sentence-end function? For example, it wouldn't work if the smiley comes at the end of a line. Also from experience I find that using advice can sometimes get a bit hairy, so I prefer to avoid it where possible.
    – Adam Spiers
    Sep 21, 2017 at 9:59
  • @AdamSpiers If a change to a library function is general, clean, and does not incur incompatibilities the best way is to change the library and send the changes as a pull request to the developer. If the change is more like an adaption to personal preferences advising is better than copying. Advices allow for more selective changes to existing functions. Therefore advices have the potential to survive orthogonal changes to the library function. When I write advices I sometimes include a warning for the case that the package version changes so I can revisit the advice in these circumstances.
    – Tobias
    Sep 21, 2017 at 10:12
  • 1
    @AdamSpiers You are clearly right about sentence-end-double-space. I didn't care too much about the absolute correctness of the sentence-end construct. In basic testing I just made sure that your example works. I wanted to pass the main message that you probably don't need to copy and you can just advice. I heard about double-spaces and stuff like that but I don't use it often. So I am not an expert on the field of the sentence-end methods.
    – Tobias
    Sep 21, 2017 at 10:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.