From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: orgtbl-mode and markdown Date: Tue, 18 Dec 2012 15:50:48 +0100 Message-ID: <66FAEC7A-9437-4ACD-A61E-4841AB8668EF@gmail.com> References: <1ssj73bvzr.fsf@voll.uninett.no> <1sbodrbhsl.fsf@voll.uninett.no> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:47450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkyVR-0001uD-It for emacs-orgmode@gnu.org; Tue, 18 Dec 2012 09:50:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkyVP-00034v-UM for emacs-orgmode@gnu.org; Tue, 18 Dec 2012 09:50:53 -0500 Received: from mail-ee0-f52.google.com ([74.125.83.52]:58548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkyVP-00034Y-EH for emacs-orgmode@gnu.org; Tue, 18 Dec 2012 09:50:51 -0500 Received: by mail-ee0-f52.google.com with SMTP id d17so368415eek.25 for ; Tue, 18 Dec 2012 06:50:50 -0800 (PST) In-Reply-To: <1sbodrbhsl.fsf@voll.uninett.no> 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Vegard Vesterheim Cc: emacs-orgmode@gnu.org On 18 dec. 2012, at 14:39, Vegard Vesterheim = wrote: > On Tue, 18 Dec 2012 14:07:36 +0100 Carsten Dominik = wrote: >=20 >> On 18 dec. 2012, at 09:33, Vegard Vesterheim = wrote: >>=20 >>> I had problems editing tables (using the minor mode orgtbl-mode) in >>> markdown files.=20 >>>=20 >>> To reproduce:=20 >>> - visit an empty buffer in markdown mode >>> - M-x orgtbl-mode >>> - create a new table (C-c |) >>> - try to edit a cell >>> - observe that the edited text is misplaced at the end of the line >>>=20 >>> The following patch against 709bf92950fb3e9dd7425e01eb53eedad43c7262 >>> seems to fix the problem >>>=20 >>> diff --git a/lisp/org-table.el b/lisp/org-table.el >>> index acad0bb..188a825 100644 >>> --- a/lisp/org-table.el >>> +++ b/lisp/org-table.el >>> @@ -4233,10 +4233,10 @@ overwritten, and the table is not marked as = requiring realignment." >>> t) >>> (eq N 1) >>> (looking-at "[^|\n]* +|")) >>> - (let (org-table-may-need-update) >>> - (goto-char (1- (match-end 0))) >>> - (backward-delete-char 1) >>> - (goto-char (match-beginning 0)) >>> + (let ((org-table-may-need-update) (mb (match-beginning 0)) = (me (match-end 0))) >>> + (goto-char (1- me)) >>> + (delete-backward-char 1) >>> + (goto-char mb) >>> (self-insert-command N)) >>> (setq org-table-may-need-update t) >>> (let* (orgtbl-mode >>=20 >>=20 >> This is really strange. Does markdown mode define hooks which kick = in >> on delete-backward-char and which to bad stuff with the match data? >=20 > Dunno. I just observed that (match-end 0) returned different results > immediately before and after (backward-delete-char 1).=20 >=20 >> Looks to me that this is a bug in markdown-mode, which should be >> reported to its authors. >=20 > Possibly, I am not proficient in elisp, hence the naive patch. But = isn't > it good practise to copy the match positions immediately after = matching > anyways?=20 Well this is very safe - but if you have to assume that every elisp = command does change match data behind your back, you would have to = create a lot of extra code. I think that you should report this to the = markdown people. I do not think we should have to make the change in = org-mode. I just checked markdown.el. Below you can find a more complete = description of what you can report to the markdown people: Regards - Carsten Bug report for markdown.el = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Markdown defines an after-change-function = `markdown-check-change-for-wiki-link'. This function is called after = each buffer change. The function contains a call to = `markdown-fontify-region-wiki-links'. If such a function would be = called through the general font-lock stuff, the match data would be = protected. However, here it is called directly from a change function. = So this function should protect match data explicitly: [lisp] Sir? diff -u markdown.el{.orig,} --- markdown.el.orig 2012-12-18 15:28:18.000000000 +0100 +++ markdown.el 2012-12-18 15:46:50.000000000 +0100 @@ -1861,16 +1861,17 @@ If a wiki link is found check to see if the backing file exists and highlight accordingly." (goto-char from) - (while (re-search-forward markdown-regex-wiki-link to t) - (let ((highlight-beginning (match-beginning 0)) - (highlight-end (match-end 0)) - (file-name - (markdown-convert-wiki-link-to-filename (match-string 1)))) - (if (file-exists-p file-name) + (save-match-data + (while (re-search-forward markdown-regex-wiki-link to t) + (let ((highlight-beginning (match-beginning 0)) + (highlight-end (match-end 0)) + (file-name + (markdown-convert-wiki-link-to-filename (match-string 1)))) + (if (file-exists-p file-name) + (markdown-highlight-wiki-link + highlight-beginning highlight-end markdown-link-face) (markdown-highlight-wiki-link - highlight-beginning highlight-end markdown-link-face) - (markdown-highlight-wiki-link - highlight-beginning highlight-end = markdown-missing-link-face))))) + highlight-beginning highlight-end = markdown-missing-link-face)))))) =20 (defun markdown-extend-changed-region (from to) "Extend region given by FROM and TO so that we can fontify all links.