From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: window-configurations and marks Date: Sun, 27 Apr 2014 00:22:20 +0900 Message-ID: <87k3acnmj7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <535BA2EA.5050801@online.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1398525835 22760 80.91.229.3 (26 Apr 2014 15:23:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Apr 2014 15:23:55 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Andreas =?utf-8?Q?R=C3=B6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 26 17:23:48 2014 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 1We4SB-0008Fk-L8 for ged-emacs-devel@m.gmane.org; Sat, 26 Apr 2014 17:23:47 +0200 Original-Received: from localhost ([::1]:34226 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1We4SA-0008K4-TU for ged-emacs-devel@m.gmane.org; Sat, 26 Apr 2014 11:23:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1We4S0-0008Jw-Hz for emacs-devel@gnu.org; Sat, 26 Apr 2014 11:23:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1We4Rt-0001ku-2a for emacs-devel@gnu.org; Sat, 26 Apr 2014 11:23:36 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:35258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1We4Rs-0001SM-OD for emacs-devel@gnu.org; Sat, 26 Apr 2014 11:23:28 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id C1BB0970AE9; Sun, 27 Apr 2014 00:22:20 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B1B5C1A276E; Sun, 27 Apr 2014 00:22:20 +0900 (JST) In-Reply-To: <535BA2EA.5050801@online.de> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:171633 Archived-At: Hi, Andreas! Andreas R=C3=B6hler writes: > Best way is to clean up the core-functions. >=20 > For example have a look at "mark". Its docstring says: >=20 > "Return this buffer's mark value as integer, or nil if never set. >=20 > In Transient Mark mode, this function signals an error if > the mark is not active. However, if `mark-even-if-inactive' is non-nil, > or the argument FORCE is non-nil, it disregards whether the mark > is active, and returns an integer or nil in the usual way." >=20 > IMO only the first line/feature is reasonable. > The remaining stuff belongs to commands making use of it, not here > - nil or point is all needed. One can argue naming (eg, the current function should be named `active-mark' and `mark' should just return the mark as an integer or nil). However there's good reason for factoring out the behavior relying on Transient Mark mode, because that is behavior chosen by the user that should be implemented consistently across mark-using commands. I personally prefer the spellings `(mark)' and `(mark t)' to `(active-mark)' and `(mark)', because users who enable t-m-m expect it to affect all uses of the mark. Therefore the "easier to write" name should be used for the function affected by t-m-m. I agree that `mark-even-if-inactive' is an ugly hack give the FORCE argument.