From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Narendra Joshi Newsgroups: gmane.emacs.help Subject: Re: Seeking Advice about refactoring and advice snippet Date: Fri, 10 Feb 2017 19:14:55 +0530 Message-ID: <87tw8217oo.fsf@vicarie.i-did-not-set--mail-host-address--so-tickle-me> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1486734066 20675 195.159.176.226 (10 Feb 2017 13:41:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Feb 2017 13:41:06 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: Help Gnu Emacs mailing list To: Filipe Silva Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Feb 10 14:41:01 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ccBRY-0004sD-Sr for geh-help-gnu-emacs@m.gmane.org; Fri, 10 Feb 2017 14:40:57 +0100 Original-Received: from localhost ([::1]:43939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccBRe-0008VP-8E for geh-help-gnu-emacs@m.gmane.org; Fri, 10 Feb 2017 08:41:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccBRE-0008V7-0Q for help-gnu-emacs@gnu.org; Fri, 10 Feb 2017 08:40:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ccBR8-00009D-MM for help-gnu-emacs@gnu.org; Fri, 10 Feb 2017 08:40:36 -0500 Original-Received: from mail-pg0-x244.google.com ([2607:f8b0:400e:c05::244]:34063) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ccBR8-00007a-G4 for help-gnu-emacs@gnu.org; Fri, 10 Feb 2017 08:40:30 -0500 Original-Received: by mail-pg0-x244.google.com with SMTP id v184so3248871pgv.1 for ; Fri, 10 Feb 2017 05:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=nRr1qNcfO8uH2jX7FQfFENA+KtYUDfQtjaLDT8FokFg=; b=fcG51fjZV2wyvycCS/rfmPeT2otKy1sFzm3NVpARXMVVuyxYN4w+iACtpikf7080Tr IkmQhaEprh2LiE7P6gSkCXpmYuZC5kEcDOht+Cgq5kYgZSM5x2JYASC7/Sb5ChlPRTE7 JeuMaW82hTXNda2S1Xl2XA9PkVy3tyCKvLXK4RqaLw+DDd5IbC905VroP3ucwGStU1er RZ4mTI92BhcJBvwnWVeNtmlRrYstIQ9p0V+6R4YfLC2jjYB9jP04y9zFK20+Q8zsHfLB rN50mJ6EyLog7TwRJCFTRvfyUgK9FaSbhYS9bF1HymWakk0YjMkmDsaPrv1mo+LQgrny 67Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=nRr1qNcfO8uH2jX7FQfFENA+KtYUDfQtjaLDT8FokFg=; b=HfhesvoeslEVt6YJyyl/0Xoi3s+zRRlbPiLdBMhqHtcW/UnjGi1686N+s0fzOxB1au E6Kqszv/oMbwZKEE9uZ+Yfa3LaSX3EP+q+BEF0DYWocbbZczhbYAflRDzGd8Y8azlu// gCKql6aR6OatqjznYoA8jC+J6+ZRZ5dJIUVG9UHD/FdD/OBxqw/sFBfa7rEQTGcpDfgm 4sNZcACTTdR65d6aaYKiRjrMx41JYPIbuB+wjc3S6amWMA0QELnMjv3sAPpghs5b+9Ib wjMqSsCDF3jfVLfqJS/JjogF7Jt5Wuc0AJ6ZxQGAkxnkF1lvHdCbYHGuXVBbHZHyPJKa m0hA== X-Gm-Message-State: AMke39lZcRPYSS4R/Pg7Cc2M2ligBttBAWgZTgshX2MqgRQndxkk2+jPeWDjKSRVy0Axuw== X-Received: by 10.99.115.12 with SMTP id o12mr10689110pgc.165.1486734027911; Fri, 10 Feb 2017 05:40:27 -0800 (PST) Original-Received: from vicarie ([223.229.135.246]) by smtp.gmail.com with ESMTPSA id k78sm5860246pfb.93.2017.02.10.05.40.26 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 10 Feb 2017 05:40:27 -0800 (PST) X-Google-Original-From: Narendra Joshi In-Reply-To: (Filipe Silva's message of "Fri, 10 Feb 2017 09:43:53 -0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c05::244 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:112289 Archived-At: Filipe Silva writes: > Dear good people of the emacs help list, > > I have a working snippet that advices both kill-buffer and kill-this-buffer > to not kill the *scratch* buffer: > > (defun ninrod/scratch-bodyguard (buffer-assassin &rest arguments) > (let ((buffer-to-kill (buffer-name (current-buffer)))) > (if (equal buffer-to-kill "*scratch*") > (message "DENIED! don't kill my precious *scratch*!!") > (apply buffer-assassin arguments)))) > (defun ninrod/scratch-protection (buffer-assassin &rest arguments) > (let ((buffer-to-kill (car arguments))) > (if (equal buffer-to-kill "*scratch*") > (message "DENIED! don't kill my precious *scratch*!!") > (apply buffer-assassin arguments)))) > (advice-add #'kill-this-buffer :around #'ninrod/scratch-bodyguard) > (advice-add #'kill-buffer :around #'ninrod/scratch-protection) > > The problem is that these lines: > > (message "DENIED! don't kill my precious *scratch*!!") > (apply buffer-assassin arguments)))) > > Are repeated in both functions, so I thought that I could apply the DRY > principle and refactor the snippet to this: > > (defun ninrod--protection (buffer-assassin buffer-to-kill &rest > arguments) > (if (equal buffer-to-kill "*scratch*") > (message "DENIED! don't kill my precious *scratch*!!") > (apply buffer-assassin arguments))) > (defun ninrod/scratch-bodyguard (buffer-assassin &rest arguments) > (let ((buffer-to-kill (buffer-name (current-buffer)))) > (ninrod--protection 'buffer-assassin buffer-to-kill arguments))) > (defun ninrod/scratch-protection (buffer-assassin &rest arguments) > (let ((buffer-to-kill (car arguments))) > (ninrod--protection 'buffer-assassin buffer-to-kill arguments))) > (advice-add #'kill-this-buffer :around #'ninrod/scratch-bodyguard) > (advice-add #'kill-buffer :around #'ninrod/scratch-protection) > > This causes all hell to break loose. Now I can't even close emacs, because > apparently emacs tries to kill all buffers > and as I've just tampered with the kill buffer functions, well, it's bad. > Very bad. Why don't you call `called-interactively-p' to decide whether you would want to kill *scratch* or not? No other function should kill *scratch* anyways except `save-buffers-kill-terminal'. > I know I mean well, but I'm must be doing something very stupid. For > starters, I don't know if I can really pass around > functions as parameters? So it could be that? > > How would you refactor that snippet to apply the dry principle? > > thanks in advance, > > Filipe. -- Narendra Joshi