From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change f59d1be: Move undo amalgamation to lisp. Date: Wed, 07 Oct 2015 15:28:44 -0400 Message-ID: References: <20151005134118.10933.50859@vcs.savannah.gnu.org> <87h9m52sh8.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: ger.gmane.org 1444246156 10264 80.91.229.3 (7 Oct 2015 19:29:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2015 19:29:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 07 21:29:07 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZjuOf-0002hd-Jb for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 21:29:05 +0200 Original-Received: from localhost ([::1]:59152 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjuOe-0001j2-UW for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 15:29:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjuOP-0001is-9B for emacs-devel@gnu.org; Wed, 07 Oct 2015 15:28:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjuOM-0006xp-2v for emacs-devel@gnu.org; Wed, 07 Oct 2015 15:28:49 -0400 Original-Received: from relais.videotron.ca ([24.201.245.36]:48664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjuOL-0006xA-Vt for emacs-devel@gnu.org; Wed, 07 Oct 2015 15:28:46 -0400 Original-Received: from ceviche.home ([24.201.111.67]) by VL-VM-MR002.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0NVV003TD7FWU8E0@VL-VM-MR002.ip.videotron.ca> for emacs-devel@gnu.org; Wed, 07 Oct 2015 15:28:44 -0400 (EDT) Original-Received: by ceviche.home (Postfix, from userid 20848) id E321D66428; Wed, 07 Oct 2015 15:28:44 -0400 (EDT) In-reply-to: <87h9m52sh8.fsf@russet.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 24.201.245.36 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191060 Archived-At: >> I think this code should be called from self-insert-command rather than >> from pre-command-hook. > On a hook? Or do I just directly call a function defined in lisp form C? Yes, you can just call a Lisp function directly from C. Typically, you do it as follows: ... call2 (Qmy_function, arg1, arg2); ... foo_syms () { ... DEFSYM (Qmy_function, "my-function"); ... } Since these functions are somewhat internal, I like to call them with a leading "internal-" prefix, but that's my own preference rather than a real convention we follow. > Does the same argument apply to the post-command-hook and > after-change-functions also? For the after-change-functions: yes, very much so. For the post-command-hook, I also think we could/should call the function directly rather than go through post-command-hook, but there are arguments in favor of either choice. At least, calling the function directly is safer in the sense that it is closer to the pre-existing code. >> And it should also be called from delete-char. > Yes, next on my list. Ah, fine, then. >> We don't actually know that (cdr last-before-nil) and (car >> last-before-nil) are numbers. The previous self-insert-command might >> have performed all kinds of buffer modifications (via abbrev-expansion, >> post-self-insert-hook, ...). > Hmmm. That's unfortunate -- I was trying to avoid "global" state and > just user buffer state; the undo-list seemed like a sensible place to > get this knowledge from. The current logic in remove_excessive_undo_boundaries is far from perfect, but unless you have a really good idea how to do it differently, I recommend you just try to reproduce it in Elisp. Stefan