On Tue, 18 Dec 2012 14:07:36 +0100 Carsten Dominik <carsten.domi...@gmail.com> wrote:
> On 18 dec. 2012, at 09:33, Vegard Vesterheim <vegard.vesterh...@uninett.no> > wrote: > >> I had problems editing tables (using the minor mode orgtbl-mode) in >> markdown files. >> >> To reproduce: >> - 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 >> >> The following patch against 709bf92950fb3e9dd7425e01eb53eedad43c7262 >> seems to fix the problem >> >> 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 > > > 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? Dunno. I just observed that (match-end 0) returned different results immediately before and after (backward-delete-char 1). > Looks to me that this is a bug in markdown-mode, which should be > reported to its authors. 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? - Vegard V -
