From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Mon, 11 Dec 2017 01:30:34 +0200 Message-ID: <494c0c44-8172-b40d-d6e1-32765b1e6042@yandex.ru> References: <20171129233237.27462.23351@vcs0.savannah.gnu.org> <5d668ce5-1482-a3d4-c01b-7d996a532567@yandex.ru> <20171130214621.GA22157@ACM> <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> <20171201154913.GB3840@ACM> <1e542021-e389-cca4-6acd-349efddb2652@yandex.ru> <20171201223529.GG3840@ACM> <4a94ec5c-efdd-50f1-ff4d-277f5f45c2df@yandex.ru> <83lgil1qme.fsf@gnu.org> <83d13x1j2s.fsf@gnu.org> <34abea95-c7f7-e8fa-8407-8c2fd2a4cfe1@yandex.ru> <83y3mkzw1n.fsf@gnu.org> <83mv2zzv7z.fsf@gnu.org> <83o9nexy48.fsf@gnu.org> <83d13uxug5.fsf@gnu.org> <41e3f343-816f-d2db-6575-6ef43d54957f@yandex.ru> <838tecuqjb.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512948683 21540 195.159.176.226 (10 Dec 2017 23:31:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Dec 2017 23:31:23 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 11 00:31:19 2017 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 1eOB42-0005I5-QS for ged-emacs-devel@m.gmane.org; Mon, 11 Dec 2017 00:31:19 +0100 Original-Received: from localhost ([::1]:50150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOB47-0001v1-W6 for ged-emacs-devel@m.gmane.org; Sun, 10 Dec 2017 18:31:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOB3U-0001tX-Dy for emacs-devel@gnu.org; Sun, 10 Dec 2017 18:30:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eOB3P-0001Ob-DW for emacs-devel@gnu.org; Sun, 10 Dec 2017 18:30:44 -0500 Original-Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:45514) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eOB3P-0001O5-3L; Sun, 10 Dec 2017 18:30:39 -0500 Original-Received: by mail-wm0-x22c.google.com with SMTP id 9so11411219wme.4; Sun, 10 Dec 2017 15:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6xcapyOtwUA30U2h55je0pvnsm2ou2yurXp4Z83nfeM=; b=VJkQi2JhZTTtI9A4v+twEFYBf0tyIuDJE8DA5xVbbsZUr9d32ZKVHHDgKr6qacw2o3 7cIR60AXaU5uv++bKJkqQnzK3ayx7zVA5hdxQHz1ybXNQZsQQxFLW6fgIngepS9rxxzN jHJuTnyYLblRK4Pea94SsErHkdR29O/A0PcyAzM62ZOIRwA0cujM7noK4ajFIaQwEWf/ i5XSExhhI2vONvYKUlIENx39UuOlRjEIUDJ//94NzFqE68+YjxvP3Zj2nJPx6z1ojy/A kZ/E2TyuP8vEFAIYTydodH9S+OZCKvCK2kStmgFgFG+Xrdd0mR2aknXBZmYUB+9SkNto +/wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6xcapyOtwUA30U2h55je0pvnsm2ou2yurXp4Z83nfeM=; b=nLaXCubJcUfnd2r0O++x7CvJSYrfUn9yW0ue/ZqUKmt+JzNnOT28ClrIMgVshuPYIV FSqyB4hcesn+5IBciRhq86PWj2wcwfIPhjfPvJqN/f7oYLaY3n35nnG4o/wiBHT7YVdE 1WnhhDMPL3zB+Vp6Um5F1QHS++jFoLammln+vmM8azvjK+kmVd7Ya1Wftw5EM+F5Bdu5 PldVkwiIOsjD5J7KUJLJmCfafw9DeYJ3h3tEp+lmMzhebpzhZ0POOcNY5BCITGx+Dlff QBi23QxuPeK9f5Xf/WctyWYrAMwQlCDBRKfGwQjIExU0WLB+BHUzX4uq2mPA6jUv8Una 3pkg== X-Gm-Message-State: AKGB3mKdPwgpo1dh4RdPBOzlWpGui8y6X0OrgyW+uAatMRPQh7CtUBLT rDCSUtEYcTOxoIyzEP9wIMSsXHL4 X-Google-Smtp-Source: AGs4zMaZHRVcm/jkr6dBzq1hHj4LDEtWwac+MV3ZuKHrc/JfXov3ysSeabpHSah0Y0YuSjfkGRBjKw== X-Received: by 10.28.1.14 with SMTP id 14mr9783144wmb.51.1512948637707; Sun, 10 Dec 2017 15:30:37 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id p17sm7803801wma.23.2017.12.10.15.30.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Dec 2017 15:30:36 -0800 (PST) In-Reply-To: <838tecuqjb.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22c 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:220868 Archived-At: On 12/9/17 12:47 PM, Eli Zaretskii wrote: > You explained that you consider the design and implementation of > prog-indentation-context unnecessarily complex, and that a simpler > design and implementation would be more elegant, given the current > practices in related modes. You have _not_ explained why keeping the > prog-indentation-context stuff would prevent us from supporting MMM > and similar features as easily as under your proposed changes. I'm honestly might be forgetting some things, given the brain-numbing effects of discussions like this, but: - We need to expand the scope of use of all elements of prog-indentation-context but the first to other facilities as well, such as font-lock, beginning-of-defun-function, etc, at which point the name of the variable kind of ceases to make sense. Out of all these, font-lock is the most apparent to the user, and thus, arguably, the most important. It is, luckily, not an issue in most major modes, but it *is* an issue in CC Mode, which you said you wanted to see supported. - PREVIOUS-CHUNKS, given how it's permissively documented now, will likely prevent some useful caching mechanisms inside major modes that will decide to use it (in particular the first option will, "A string containing text"). I also fail to see how one would write support for it without having to program two fairly different code paths. - In case the discussion about moving 'widen' calls to indent-for-tab-command and indent-according-to-mode concludes affirmatively, we won't be able to use prog-widen there because prog-indentation-context gets set "later". This issue can probably be avoided by dropping the backing variable and moving to a similar-but-different design with hooks like prog-first-column-function, prog-current-chunk-function, etc, but these details still need to be finalized, and for that I'm waiting for Alan's feedback on adapting CC Mode to MMM. - Then, we'll go onto solving the less well-examined issues with our designer hands tied more strongly than they could have been, because we've committed to one particular API, one that's harder to smoothly migrate over from. Next, WHAT HAPPENS IF WE SUPPORT PROG-INDENTATION-CONTEXT PROPERLY: - All the major modes will have to be adapted to use prog-widen in indentation code, and maybe some other places they use 'widen' at now. This, in turn, will break their uses in mmm-mode, polymode, and whatever other MMM packages are out there (including mhtml-mode, but it's easy to fix). - Thus, MMM frameworks will need to be updated, changing over from the current practice. Compatibility shims will need to be added in them, to work with both older and new Emacs. So if you were worried that removing prog-indentation-context would cause inconvenience to antlr-mode (its last released version which jumped the gun with supporting prog-indentation-context), properly supporting prog-indentation-context will cause more breakage overall, in said MMM frameworks. Until they all get updated and all users install the new versions, by various means those updates are delivered.