From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Ibuffer: w and B default to buffer at current line Date: Sun, 18 Sep 2016 17:26:03 +0300 Message-ID: <83r38hi8sk.fsf@gnu.org> References: > <83intw5our.fsf@gnu.org>> <3dbc0c03-56f9-4b6f-bd3b-258458967665@default> <83zin630i9.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1474208827 12727 195.159.176.226 (18 Sep 2016 14:27:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Sep 2016 14:27:07 +0000 (UTC) Cc: tino.calancha@gmail.com, drew.adams@oracle.com, emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 18 16:27:02 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bld3O-0000oB-JK for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 16:26:46 +0200 Original-Received: from localhost ([::1]:50304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bld3M-0002hE-P0 for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 10:26:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bld2e-0002gz-8V for emacs-devel@gnu.org; Sun, 18 Sep 2016 10:26:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bld2Y-0008MO-HE for emacs-devel@gnu.org; Sun, 18 Sep 2016 10:25:55 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bld2U-0008HT-0A; Sun, 18 Sep 2016 10:25:50 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2912 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bld2R-0001Xw-Ux; Sun, 18 Sep 2016 10:25:48 -0400 In-reply-to: (message from John Wiegley on Sat, 17 Sep 2016 14:35:57 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:207547 Archived-At: > From: John Wiegley > Cc: drew.adams@oracle.com, emacs-devel@gnu.org, tino.calancha@gmail.com > Date: Sat, 17 Sep 2016 14:35:57 -0700 > > > If DWIM is okay in the UI, then functions that behave in support of that UI > > should also be okay. > > Since this responses surprised me a bit, I'm going to assume that I've > misunderstood somehow. > > Let me give a hypothetical example: Assume for the sake of argument that > `count-lines' did not report characters as well, and that someone wished to > extend the `count-lines' command so that, given a prefix arg, it would count > characters instead of lines. > > What I think should happen in this case is that a new command be created: > count-items-in-region, which by default counts lines, but with a prefix > argument counts characters. This leaves that command open to many new > behaviors in future, while `count-lines' keeps doing just what it says: count > lines. If we have 2 functions, one only for counting lines and another only for counting characters, then how will we give a user a command that can do both depending on the prefix argument? In Emacs, every command is a function, so eventually, we would need to have a single function which could do both, right? Therefore, the only issue here is whether that function should be called count-lines or something else, right? Now let's make one step forward, and imagine a command that decides whether or not to count characters as well as lines based on some context, whatever that may be, and imagine that such a command could reliably make that decision. We will then have a function with such a DWIMish modus operandi, which is totally okay, and is actually the _only_ way of having such commands in Emacs -- by writing a function which implements that DWIM. IOW, as long as having DWIM in a command is okay, it should also be okay in a function, because in Emacs every command is a function. > What I would object to is adding a new argument to `count-lines', called > `characters-p', that changes the behavior of count-lines to now count > characters instead (again, remember this is hypothetical, I know that today's > `count-lines' already counts characters as well). Then how would you implement a command which could do both, under some circumstances? > Just because I want DWIM from my interface, doesn't mean I need to implement > it as DWIM in my functions. But there are no user interfaces in Emacs except functions. And if you are saying that DWIM can only be present in top-level functions that have an interactive spec, then (a) I think this is too restrictive and will cause us to put too much code on the top level, and (b) we cannot prevent Lisp programs from invoking commands as functions. > I believe -- very strongly -- that each function should do one thing > and one thing well, and this one thing should be documented well. I > don't like magical functions with lots of alternative behaviors, > unless it is a command created for the purpose of magically > dispatching to other functions based on its context of use. Such > magical interface functions are quite alright in my book; but > complexifying the behavior of core functions is not. This all boils down to the definition of "core functions", I guess. If you want to apply this rule only to core functions, you had better came up with a very good and precise definition. I predict that this would be hard to do, and we will have many incidents of Lisp programs that try to call non-core DWIM functions and requests to remove a function from the core to make it more DWIMish. IOW, I believe this goal is not reachable in Emacs, not in practice anyway.