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: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings Date: Thu, 04 Mar 2021 08:20:08 -0500 Message-ID: References: <20210303191236.24697.93201@vcs0.savannah.gnu.org> <20210303191237.2B2D720E1B@vcs0.savannah.gnu.org> <87zgzkug5d.fsf@mail.linkov.net> <87a6rj5jdl.fsf@mail.linkov.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="20551"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 04 14:21:21 2021 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 1lHnuq-0005Fg-MT for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Mar 2021 14:21:20 +0100 Original-Received: from localhost ([::1]:33800 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHnup-0001Ca-NO for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Mar 2021 08:21:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35054) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHntn-0000Yk-Ll for emacs-devel@gnu.org; Thu, 04 Mar 2021 08:20:15 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:52687) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHntl-0000zq-2C for emacs-devel@gnu.org; Thu, 04 Mar 2021 08:20:14 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 961DE80C41; Thu, 4 Mar 2021 08:20:11 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CA07780229; Thu, 4 Mar 2021 08:20:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1614864009; bh=sEU4qoeyOumvfvFAnYqZYrki6aKQBIDW31z1JTRuid4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=JawGT1cf1F9h+0jXppiI4X4y3iYhZXBT2WNdWEytpEff3l9+8h31DDfEDCOe/q1PP 4lDQfWOWwmcO2Lgs/IJ2wqgTMX/6Sl8K1d1JP7XchOcqxygowicndUf7mf1sHeJogc KLMW8+IdA7k4lv371lnFNOx5hBgqi1rR2FbTtTYuojCXYBoCFk6sQLR2DFsJaXG9aU X1ckRujuqQ0UaSGG38vommW/g+ry/7ofv2Uutlh5w/InXd1e3pGImxpENQf78q/uGO Ipf9Ks7iraMJ1oxZQeiBX2yhpz0WufPX/W6P5gntoPeaeRYHpqJ/rKZyg/wUGqEowt Mnpf2gNLTvvJw== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6E5D81203C4; Thu, 4 Mar 2021 08:20:09 -0500 (EST) In-Reply-To: <87a6rj5jdl.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 04 Mar 2021 10:58:06 +0200") 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.23 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:265948 Archived-At: >> Any mode where you've found bad interactions? > > Only in two modes so far: > > 1. in emacs-lisp-mode sometimes the inner part of a large expression > gets to the beginning of the line, then trying to indent it with TAB > hides the remaining part. A workaround is to type SPC before indenting > with TAB. > > 2. in diff-mode TAB on a diff header line used to navigate to the next hunk > with 'diff-hunk-next', now it hides the next hunk. A workaround is to > move point to the next line before typing TAB to go to the next hunk. > > Are these a possible reasons that would prevent enabling cycling > in outline-minor-mode by default? Until we resolve them? Sounds like it, yes. [ As for how to resolve it (in terms of behavior rather than in terms of code), I think the cycling should only kick after trying indentation and the indentation function did not change the buffer. This is the kind of refinement in behavior which can't be obtained just by key bindings but is (barely) obtainable via `add-function`. ] >>> 3. (add-hook 'emacs-lisp-mode-hook 'outline-cycle-minor-mode) >>> without outline highlighting to not overwrite major mode faces >> In which way did the highlighting get in the way? > Actually, I discovered only now that outline faces with > outline-minor-mode-highlight don't override major mode faces. So at least it currently doesn't get in the way ;-) More seriously: it's because you've put `append` in the LAXMATCH part rather than the OVERRIDE part of the font-lock-keywords rule. >> FWIW, I think the only really good way to solve this problem is to >> replace `indent-for-tab-command` with a new command (call it >> `tab-dwim`?) which can be more finely configured by major and minor >> modes. E.g. by making it call `tab-dwim-function` on which modes can >> `add-function` at will (and at various depths so they can control >> whether it should take precedence or not over the "TAB causes >> indentation" or "TAB causes completion", ...). > > The problem is that too many commands bound to TAB need to adapt > this special handling: indent-for-tab-command, diff-hunk-next, > compilation-next-error, forward-button, etc. etc. And I'm saying we should reduce this to a single command (`tab-dwim`) and then instead of binding TAB modes should `add-function` to `tab-dwim-function`. >> The mechanism of priorities of keymaps coupled with "fallthrough" >> (either via the "menu-item + filter" trick or via some explicitly >> looking up the keymaps and calling the next command) isn't fine-grained >> enough to deal with the amount of overloading that people want to use on >> that poor TAB key. > It seems only some very high-level map like overriding-terminal-local-map > could handle this generally. That'd only be necessary as a temporary measure until modes learn not to bind TAB to their own command but to use `tab-dwim-functions` instead. Stefan