Существуют ли различия в функциональных возможностях при использовании соглашения с двумя пробелами против одного пробела в конце предложения?

Вопрос: Какие практические причины есть не в набор , sentence-end-double-spaceчтобы nil?

Этот вопрос вдохновил недавно возрожденный поток, посвященный распознаванию предложений, которые не заканчиваются двумя пробелами .

В ручном узле Emacs по предложениям отмечается, что команды предложений предполагают, что мы используем соглашение американской машинистки о том, что в конце предложения ставится два пробела (в отличие, скажем, от французского соглашения об одном пробеле). Аргументы за / против соглашения о двух пространствах, по-видимому, становятся довольно полемическими (например, этот кусок Slate ).

Меня не особо заботит внешний вид, поскольку я позволяю LaTeX обрабатывать мои наборы текста, но соглашение о двух пробелах заложено в мышечную память. Однако, когда я вставляю текст в буфер Emacs из других источников (веб-страниц и т. Д.), Это почти всегда в соглашении с одним пробелом. Это отчасти раздражает в духе «как они смеют отличаться от меня», и я испытываю желание sentence-end-double-spaceперейти nilк Реальности. Я никогда не делал, однако, потому что я всегда предполагал, что что-то сломается, если я это сделаю. У меня просто нет твердой основы для такого предположения.

Итак: есть ли практические последствия с точки зрения потери функциональности для установки sentence-end-double-spaceна nil? Единственное существенное изменение, о котором я могу думать, - это то, что функции заполнения преобразуют соглашение о двух пробелах в соглашение об одном пробеле.

Единственное следствие, которое я вижу, - это способность распознавать периоды по аббревиатурам.

Как сказано в gnu.org :

Если вы хотите использовать только один пробел между предложениями, вы можете установить переменную sentence-end-double-spaceравной nil, чтобы команды предложений останавливались для одиночных пробелов. Однако, это имеет недостаток: нет никакого способа , чтобы различать периоды, конечных предложений и те , которые указывают на сокращения .

Поэтому для удобного и надежного редактирования мы рекомендуем придерживаться соглашения о двух пробелах. Переменная sentence-end-double-spaceтакже влияет на заполнение .

Я никогда не использовал соглашение о двух пробелах, я думаю, это зависит от того, как / что вы редактируете.

На самом деле это не ответ на поставленный вопрос («что я потеряю, если я настроен sentence-end-double-spaceна nil»), а скорее что-то вроде третьего пути ;-). (Кроме того, это (частичная) копия сообщения, которое я только что написал в своем блоге ; если это неуместно, кто-то, пожалуйста, удалите это, но я надеюсь, что это может быть полезно.)

Итак, в основном, почему вы хотите что-то потерять , настроив что-то против вашего вкуса? В конце концов, это Emacs!

(defvar sentence-end-double-space-threshold 2
  "How many occurrences of \".  \" per kilobyte should be enough
  to declare this file as using two spaces after sentences.")

(defun set-sentence-end-double-space ()
  "Set `sentence-end-double-space' according to how often the
  literal string \".  \" occurs in the current buffer."
  (make-local-variable 'sentence-end-double-space)
  (if (>= (* (count-matches "\\.  ") 1024)
      (* (buffer-size) sentence-end-double-space-threshold))
      (setq sentence-end-double-space t)
    (setq sentence-end-double-space nil)))

(add-hook 'find-file-hook 'set-sentence-end-double-space)     

Теперь, когда вы открываете файл, Emacs решает (используя очень консервативное значение sentence-end-double-space-threshold, которое вы можете использовать, setqкак считаете нужным), какой это стиль. (Очевидно, что это не помогает в случае вставки из браузера или чего-либо еще. Это можно сделать, посоветовав yankи - при необходимости - заменив пробелы в выдернутом тексте по мере необходимости, но эй, у меня было только 15 минут для этого!)

PS. Конечно, это не учитывает периоды в EOLs и т.д .; но опять же, порог очень низкий.