From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Fwd: A TAB operation reform question. Date: Tue, 11 Oct 2022 08:54:22 -0400 Message-ID: References: <87tu4blmf0.fsf@laptop.lockywolf.net> <87mta3krsg.fsf@laptop.lockywolf.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5779"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Vladimir Nikishkin Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 11 15:58:41 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oiFmK-0001Ey-IW for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 15:58:40 +0200 Original-Received: from localhost ([::1]:41840 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiFmJ-0002Pr-Jr for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 09:58:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33484) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiEmT-0006Ey-KI for emacs-devel@gnu.org; Tue, 11 Oct 2022 08:54:46 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29991) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiEmD-0006dV-St for emacs-devel@gnu.org; Tue, 11 Oct 2022 08:54:39 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CC37810013B; Tue, 11 Oct 2022 08:54:27 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 04B211000D5; Tue, 11 Oct 2022 08:54:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1665492866; bh=ebcL49tD2Y9ibXCN8lEZLqlGqD9/It+tE16XZgMqDnw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f/V1aO8QedjBDQVBd6cSvbkaMh4AIaKVZ4l9ftqiESCQjkMx/3+3C2rf1JdmeWFzV NANjr078uu6Cf/fU49YwcVsgHvdQrHYIGIaA2JKKG12nCLX6qzS560VrsFfm0Ul9+3 8wkVAIbnPn87qrVKFgfiMvQwc3+8pCLvdrVADcq0oE+V06rk7icDEeHRqTCHuicNaQ kevhIYkZxEW+SZJjB9KkUoZ+vYVwxDPIgCdogu4PA97W/+y1sw7Ax/xEFJSFM0QAnZ wgzMpNtT8HodTEwDWq+5xc96s6kDbLfDNTfQot+0eHkugwQ/1jw1y66rQfp+dWrfYG igb8NhVtLvWWg== Original-Received: from pastel (65-110-220-202.cpe.pppoe.ca [65.110.220.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 27D611208E2; Tue, 11 Oct 2022 08:54:25 -0400 (EDT) In-Reply-To: <87mta3krsg.fsf@laptop.lockywolf.net> (Vladimir Nikishkin's message of "Tue, 11 Oct 2022 10:37:06 +0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:297486 Archived-At: I agree there's a problem that needs fixing. TAB should be bound to a "DWIM" command which major modes should be able to tweak and override any way they want, which basically means that this command should do little more than run some kind of hook. Maybe we should split the code of `indent-for-tab-command` into a few separate functions, each one implementing a particular functionality (one for indent, one for completion, one for inserting a TAB, one for indent region, IIRC), and then recombine them into the original functionality by compositing them with `add-function`. The idea would be that major/minor modes would not (re)bind TAB any more but would `add-function` to a new `tab-dwim-function` instead. End-users would then be able to rebind TAB for their own use without having to fight with all the major/minor modes doing their own rebindings of TAB. Of course, they'd also have the option of adding their own functionality to that new `tab-dwim-function`. Stefan Vladimir Nikishkin [2022-10-11 10:37:06] wrote: > I am sorry for "forwarding" an email, but I initially thought that > "help-gnu-emacs" would be more appropriate. > > But still, I would like to ask what Emacs developers think about this > issue. Would it be possible to repurpose TAB from "sometimes TAB, > sometimes indent, sometimes complete", to a more general-purpose dwim > framework? > > Vladimir Nikishkin writes: > >> Hello, Emacs users and developers >> >> I would like to ask if a reform to the way TAB (C-i) works has been >> considered? And if "yes", then how hard would it be to implement it? >> >> The motivation is the following: >> >> The way TAB works at the moment is peculiar. >> >> There is this "indent-for-tab-command", which either indents, or inserts >> a tab-character, or completes... unless "tab-always-indent" is set to >> some special value, but there are mode-specific >> modename-tab-always-indent, but they are also sometimes ignored. Also, >> org-mode overrides it with "org-cycle", and perhaps, other modes do too. >> Also, "tab" is considered to be "the place somehow close to completion >> functions", so M-C-i==M-TAB is "ispell-complete-word", and a lot of >> other packages try to make their completion somehow close to TAB. >> >> This looks a bit like a mess, partly because TAB is almost universally >> seen as a "dwim" entry point, but it is not officially so in Emacs. >> >> Could there be an alternative protocol? Could TAB be make a DWIM entry >> point "officially"? >> >> In particular, could it be possible to make a "hard-switch" variable >> "tab-always-inserts-tab", which would be the opposite of >> "tab-always-indent", but simpler, and it would be possible to override >> it in the major modes, thus making "c-tab-always-indent" unnecessary. >> >> If tab-always-inserts-tab is set to nil, TAB (for example) would be >> looking in some customizable list of functions, say >> "tab-dwim-list-functions", and run each function until some does not >> return non-nil. The default list could be something like >> (indent-if-possible indent-comment-if-possible hs-fold-if-possible >> complete-if-possible insert-tab). >> Using TAB with a prefix-argument would always insert a TAB. (which would >> be an exception to the rule "default prefix argument is 4", but I think >> it would be understandable.). >> >> This way, instead of rebinding tab to org-cycle, org-mode could prepend >> "org-cycle" to this list, or make it the only member of the list, but >> this would still allow the users to plug in custom dwim functions >> further into the list, such as ispell-word (not completion), jump >> between table cells, and such.