From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Omar_Antol=C3=ADn_Camarena?= Subject: org-backward-paragraph probably should *not* signal user-error at start of buffer Date: Thu, 27 Jul 2017 15:10:00 -0700 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1143ae32967e78055553d4b5" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1daqzA-0007W3-8t for emacs-orgmode@gnu.org; Thu, 27 Jul 2017 18:10:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1daqz9-0000g0-7L for emacs-orgmode@gnu.org; Thu, 27 Jul 2017 18:10:24 -0400 Received: from mail-ua0-x22b.google.com ([2607:f8b0:400c:c08::22b]:35463) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1daqz9-0000er-3n for emacs-orgmode@gnu.org; Thu, 27 Jul 2017 18:10:23 -0400 Received: by mail-ua0-x22b.google.com with SMTP id d29so141922664uai.2 for ; Thu, 27 Jul 2017 15:10:21 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org --001a1143ae32967e78055553d4b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I just noticed that org-backward-paragraph raises a user error if you call it at the beginning of the buffer. This is not what the general backward-paragraph command does, nor is it what I remember other Emacs movement commands doing when the move can't actually be done. I think consistency with other movement commands is reason enough to change the behavior of org-backward-paragraph, but here's a potentially more convincing reason: the function org-inside-LaTeX-fragment-p is supposed to return nil if point is inside a LaTeX fragment (and a truthy value otherwise). But since org-inside-LaTeX-fragment-p uses org-backward-paragraph internally, what actually happens is that it works as described *unless* you are at the beginning of the buffer in which case it doesn't return any value at all but instead signals a user-error! I've worked around this in my own code by changing (org-inside-LaTeX-fragment-p) to (unless (bobp) (org-inside-LaTeX-fragment-p)), but it feels like org-backward-paragraph should be changed instead. --=20 Omar Antol=C3=ADn Camarena --001a1143ae32967e78055553d4b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just noticed that org-backward-paragraph raises a u= ser error if you call it at the beginning of the buffer. This is not what t= he general backward-paragraph command does, nor is it what I remember other= Emacs movement commands doing when the move can't actually be done.
I think consistency with other movement commands is reason = enough to change the behavior of org-backward-paragraph, but here's a p= otentially more convincing reason: the function org-inside-LaTeX-fragment-p= is supposed to return nil if point is inside a LaTeX fragment (and a truth= y value otherwise). But since org-inside-LaTeX-fragment-p uses org-backward= -paragraph internally, what actually happens is that it works as described = *unless* you are at the beginning of the buffer in which case it doesn'= t return any value at all but instead signals a user-error!
<= div>

I've worked around this in my own= code by changing (org-inside-LaTeX-fragment-p) to (unless (bobp) (org-insi= de-LaTeX-fragment-p)), but it feels like org-backward-paragraph should be c= hanged instead.

--
Oma= r Antol=C3=ADn Camarena
--001a1143ae32967e78055553d4b5--