From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Monnier Subject: Re: orgalist-mode: wrong indentation in message mode after recent change in emacs Date: Tue, 23 Apr 2019 08:15:09 -0400 Message-ID: References: <87k1gdptsn.fsf@len.workgroup> <87ef6l9x13.fsf@tcd.ie> <87a7ghw2tc.fsf@nicolasgoaziou.fr> <87wojldmcx.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <87wojldmcx.fsf@tcd.ie> (Basil L. Contovounesios's message of "Tue, 23 Apr 2019 11:53:02 +0100") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sender: "Emacs-devel" To: "Basil L. Contovounesios" Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org List-Id: emacs-orgmode.gnu.org >>> The first is whether orgalist-mode couldn't use a custom >>> indent-line-function instead of advising what may or may not be set to >>> indent-relative by the user. >> I don't know how that would work in practice. > Me neither. >> But a minor mode taking control over `indent-line-function' sounds >> wrong. > Well, orgalist already "takes control" over indent-line-function and > indent-according-to-mode via advice, and the latter advice seems to > assume that indent-line-function is set to the default indent-relative > or indent-relative-first-indent-point. I haven't bothered to look at the advice to have an opinion here, so I'll let you guys figure out this part. >>> The second is why advice--buffer-local does what it does. Stefan, why >>> does it behave differently depending on local-variable-p? Why can't it >>> simply call make-local-variable before returning the symbol-value? Normally a hook runs both its local part and its global part, where the global part is represented in the local list by the special element `t`. When you do `make-local-variable` you're basically *copying* the global part to the local part, with the usual implications: when the global part is later modified those modifications won't be properly reflected in the local copy. That's why we had `make-local-hook` which is now automatically performed by `add-hook` depending on the `local` arg. The exact same thing goes for `add-function` when applied to a variable. In the current case, I think calling `make-local-variable` is likely harmless because *we* know the global value should likely never change, but that's not something that `add-function` knows to be true in general. So instead, `add-function` sets the local value to a function that looks up the global value and runs it, which is the moral equivalent of the `t` element on normal hooks. >>> The third is why indent-according-to-mode hard-codes the check for >>> indent-relative and indent-relative-first-indent-point. History. Comparing functions is always a bad idea. But I couldn't and still can't see how to avoid it here without introducing worse problems. >>> Wouldn't it be nice if this check instead looked up some variable >>> akin to electric-indent-functions-without-reindent, that can be more >>> easily customised? Yes, tho it probably wouldn't help much here: not only we'd still be comparing functions, but we'd also need for orgalist to go through the trouble of manually adding the closure dynamically created by `add-function` to this list. Stefan