From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thibaut Verron Newsgroups: gmane.emacs.help Subject: Re: more issues with setq-local Date: Tue, 20 Apr 2021 17:48:11 +0200 Message-ID: <0a15a03d-25a6-0092-164b-92a849394570@gmail.com> References: <878s5dkn5c.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25789"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 20 17:58:34 2021 Return-path: Envelope-to: geh-help-gnu-emacs@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 1lYsll-0006Zu-Um for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 20 Apr 2021 17:58:33 +0200 Original-Received: from localhost ([::1]:52104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYsll-0001Hg-1l for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 20 Apr 2021 11:58:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYsbp-0002B8-HU for help-gnu-emacs@gnu.org; Tue, 20 Apr 2021 11:48:17 -0400 Original-Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:45684) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYsbn-0003dj-M2 for help-gnu-emacs@gnu.org; Tue, 20 Apr 2021 11:48:17 -0400 Original-Received: by mail-ed1-x535.google.com with SMTP id bx20so44544488edb.12 for ; Tue, 20 Apr 2021 08:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=rOCbG1n5yT5hYastCw4zsWH61KQfa7HaCE9fOZ+3ewQ=; b=Uu5I+d7VzfTeeYa23lZin+00Om0EmF3nLe5vcq91GgfCNH0ef50Ty4Cy+XN8NKdRQN 1Rz79I6Ja6740ZvfcGMQP2dEFNHXDXRFIcbIzyz4SSuRUkSJ6FO0MdJRrbV3jtEupVoG yA3MPihynkvTtURaiLOwQjGJ9XEJNkNtPKlC4Hq5b+TN/bd7IbmQPNpQa6CsH62wqsZb i9vJbJ9YwLJbLwd8MGAeKXak+7NSQDc5vYDCIoafTLnphPmKTEE3qO2ict1EEBA1ehrS Mh7Fl1LWCw21eOKEs33ocvLnFFHAJXv7ZBXvQi4r1tAOhXgsXRpQbiSq/0E5ikRgXk0V GoVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=rOCbG1n5yT5hYastCw4zsWH61KQfa7HaCE9fOZ+3ewQ=; b=QWhNnKnG+QMgwmqLiqrlI2YKniusxzR//xUpgDNjpa6U/ZVvvdpCw1aoYUgs5yT04f DHwRTCga0k6MI/VmVkYNbY96CZEBoa5ZvX3wnyOs1rTlC2/voSBMMzFizmXYanuiq1zV wh+9h563kMix6Wrk+P+h5KFuiZNdWHtz5VJHzhmOWDwswV7/0kAlUQ5F+V9IrUiPUE6k 3xduODolDTvmAUwqlQrTvOWn3pQkRPRrA0XglwFMC+jrtzn0almeMkvZ7JQlbl+WFAnj aJXHNA0ISQt2noBzNgPZvLoz6OjH8n630o3PHvH52ReRg1vFZfwQRcML4VbnIz5IcIzw Yv1A== X-Gm-Message-State: AOAM533WO89TXz+raH7Xfu5NRsr+PuSpsNwpHZ8JOcgbXi12GIsLwiXJ Z2AErB6kl1diXgDq1SJ+q4mt8vvV6xHWpVX40Ig= X-Google-Smtp-Source: ABdhPJybhrTP64VRMHW0fFPUS8EatTV2VM4vVj1IjlLEHEIlQeISOsbiAkNqVu2gFvZzoAilS6XN2Q== X-Received: by 2002:a05:6402:368:: with SMTP id s8mr27591295edw.183.1618933692878; Tue, 20 Apr 2021 08:48:12 -0700 (PDT) Original-Received: from [192.168.2.103] (dslb-088-066-248-118.088.066.pools.vodafone-ip.de. [88.66.248.118]) by smtp.googlemail.com with ESMTPSA id z14sm1974914edc.62.2021.04.20.08.48.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Apr 2021 08:48:12 -0700 (PDT) In-Reply-To: <878s5dkn5c.fsf@zoho.eu> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::535; envelope-from=thibaut.verron@gmail.com; helo=mail-ed1-x535.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:129095 Archived-At: On 2021-04-20 5:10 p.m., Emanuel Berg via Users list for the GNU Emacs text editor wrote: > So, how do you do set `fill-column' to 62 everywhere in Emacs? > > `setq' sets it buffer-locally. > > And `setq-default' sets it where it isn't set! > > But do I set it where it is set? I am to hunt down these > buffers manually? You could write a loop going over all buffers and doing setq in each of them, if that's really what you want. But if all you want is to use the default value everywhere, isn't it easier not to set it locally in the first place? > Observe the below [last] Elisp. We see/understand that > fill-column isn't of the "buffer instance metadata" use case. > It is just normal data. Which might need to be different in different buffers. The alternative, as you say, is a global variable which users would make local when necessary. I think that the current setting is less destructively dangerous. Imagine for instance someone with a before-save-hook function using fill-column, and accidentally changing the global value... > If one wants that different in > different parts of Emacs, why don't you do as `message-mode' > and get your own variable? What do you mean? I strongly suspect that what message-mode does is (setq fill-column message-fill-column) at mode initialization. The variable message-fill-column is given for convenience, ie, so that you can set the fill column for *Messages* by just setting that variable (instead of using, say, a hook). But internally, a buffer-local version of fill-column is created for the *Messages* buffer. If that's what you mean by "it is set", that some mode is setting the variable, then yes, I suspect that you have no choice but to investigate how to bypass that setting for each mode which gets an incorrect value (or override it manually with a hook).