From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Andreas_R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: window-configurations and marks Date: Sat, 26 Apr 2014 14:13:30 +0200 Message-ID: <535BA2EA.5050801@online.de> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1398514445 6724 80.91.229.3 (26 Apr 2014 12:14:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Apr 2014 12:14:05 +0000 (UTC) Cc: Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 26 14:13:56 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 1We1US-00087u-DB for ged-emacs-devel@m.gmane.org; Sat, 26 Apr 2014 14:13:56 +0200 Original-Received: from localhost ([::1]:33706 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1We1UR-0002h1-PJ for ged-emacs-devel@m.gmane.org; Sat, 26 Apr 2014 08:13:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1We1UG-0002Zv-Rj for emacs-devel@gnu.org; Sat, 26 Apr 2014 08:13:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1We1U9-0006qi-A6 for emacs-devel@gnu.org; Sat, 26 Apr 2014 08:13:44 -0400 Original-Received: from mout.kundenserver.de ([212.227.17.10]:53332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1We1U8-0006qW-Vt for emacs-devel@gnu.org; Sat, 26 Apr 2014 08:13:37 -0400 Original-Received: from [192.168.178.32] (brln-4db9f399.pool.mediaWays.net [77.185.243.153]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0MGGwx-1WigRe0YJL-00FEEO; Sat, 26 Apr 2014 14:13:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.4.0 In-Reply-To: X-Provags-ID: V02:K0:2zoWVmgFIQRHsV4RkbKRbsg8tcNHwVmUcOiw4ICq6Fo 4M6/7wb5shJxyzrMdVktZc3d/ttENWc57q0Dw35VRSETKSWnnh M+u7Bqh7h8wG0R/X7SRaK0Rf3tUz6ek360gkWBh0yJRaGXk8M7 bWNuZttVCjQxW2+vcCFmhRmzqfuD8tRHVBXCUxFfunou9avkfp dJR5Y9UH0DkYx5WoETNXr8xNN3eRekVeuKm+hqRaX73iGeHgVs shuQwAdZZZyef8IyW9BhvUIDGdyc5/0LJIk4w478QaHqa2ytXv vsHYnzOXUs3AvsogRlEkguF+ng/t7Gr7NliwrCx83mhVSukmoG wqcfxQucQED4UPh9W5fsK5I5WZC9mTqx7qP0XRZhm X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.10 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:171632 Archived-At: On 24.04.2014 15:15, Stefan Monnier wrote: > > A lot of code assumes that "mark-active non-nil implies that (mark) > points somewhere", and I think it's a reasonable assumption. > > But occasionally this property is invalid. One place I found where > it can be invalidated is in set-window-configuration because > window-configurations keep a copy of the mark, which is hence reset by > set-window-configuration without paying attention to its connection to > mark-active. > > I just installed a patch which changes set-window-configuration so as to > call deactivate-mark when mark-active is non-nil and we set the mark to > point nowhere. But I don't like this patch: > - I don't like to idea of running arbitrary Elisp code from the middle of > set-window-configuration. > - It calls for calling activate-mark in the reverse case. > - It's done "per-window" whereas the mark is "per-buffer". > > So, I'm really thinking that the better fix is to change > set-window-configuration such that it does not touch the mark (which > really doesn't have anything to do with windows or > window-configurations, and indeed window-state doesn't include > information about the mark). > > Any objection? > > > Stefan > > Hi Stefan, can't object at this point, as IMO the basics are confused to such an extend, these and other quirks are to expect. Remember related matter being discussed around "interactive-p". Best way is to clean up the core-functions. For example have a look at "mark". Its docstring says: "Return this buffer's mark value as integer, or nil if never set. 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." 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. Just an example. Cleaning that stuff up would save a lot of time and bugs later on. Cheers, Andreas