From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#31656: 26.1; `fill-paragraph' malformats in emacs-lisp-mode Date: Fri, 01 Jun 2018 18:10:24 +0300 Message-ID: <836032fspr.fsf@gnu.org> References: <83sh66g8wb.fsf@gnu.org> <87bmcuc0bo.fsf@gmail.com> <83lgbyfz3w.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1527865810 18694 195.159.176.226 (1 Jun 2018 15:10:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Jun 2018 15:10:10 +0000 (UTC) Cc: 31656@debbugs.gnu.org, npostavs@gmail.com To: Stefan Guath Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 01 17:10:06 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1fOlgr-0004ky-VW for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Jun 2018 17:10:06 +0200 Original-Received: from localhost ([::1]:56176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOliz-0003Jh-0c for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Jun 2018 11:12:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOlhq-0002qD-0z for bug-gnu-emacs@gnu.org; Fri, 01 Jun 2018 11:11:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOlhm-0003rZ-Qo for bug-gnu-emacs@gnu.org; Fri, 01 Jun 2018 11:11:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50236) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fOlhm-0003rH-MW for bug-gnu-emacs@gnu.org; Fri, 01 Jun 2018 11:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fOlhm-0002rj-E7 for bug-gnu-emacs@gnu.org; Fri, 01 Jun 2018 11:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Jun 2018 15:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31656 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31656-submit@debbugs.gnu.org id=B31656.152786583610980 (code B ref 31656); Fri, 01 Jun 2018 15:11:02 +0000 Original-Received: (at 31656) by debbugs.gnu.org; 1 Jun 2018 15:10:36 +0000 Original-Received: from localhost ([127.0.0.1]:58133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOlhL-0002r2-SC for submit@debbugs.gnu.org; Fri, 01 Jun 2018 11:10:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOlhK-0002ql-Kk for 31656@debbugs.gnu.org; Fri, 01 Jun 2018 11:10:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOlhC-0003UO-5k for 31656@debbugs.gnu.org; Fri, 01 Jun 2018 11:10:29 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOlhB-0003U8-VN; Fri, 01 Jun 2018 11:10:26 -0400 Original-Received: from [176.228.60.248] (port=4689 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fOlhB-0000JE-6L; Fri, 01 Jun 2018 11:10:25 -0400 In-reply-to: (message from Stefan Guath on Fri, 1 Jun 2018 16:34:31 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:146831 Archived-At: > From: Stefan Guath > Date: Fri, 1 Jun 2018 16:34:31 +0200 > Cc: npostavs@gmail.com, 31656@debbugs.gnu.org > > > The very idea of shadowing the global `fill-column' in the first place breaks the Principle Of Least > > Astonishment > > If that is so, then we should have gobs of astonished users since 1995. > > Yes, the streets are flooded with them! But Emacs users are a tough crowd that don't complain :) I guess so. > >From my POV, the answer is clear: it allows users to have different > customizable defaults for fill-column in Emacs Lisp and elsewhere. > > If that was the only intention, that functionality was already present (I guess way long before 1995) by just > doing: > (add-hook 'emacs-lisp-mode-hook (lambda () (setq fill-column 80))) ;fill-column is buffer-local Sure, but then everyone would need to write a mode hook, don't you think? With a separate option, things "just work". > E.g., in text modes, it is customary to enlarge the default to 79 or > thereabouts, but in Emacs Lisp we generally say that good style is to > make lines in doc strings no wider than 60 characters (see the ELisp > manual). > > Doc strings, sure. But outside doc string, as it behaves now? Nah. Maybe we should simply advise against using M-q outside of doc strings and comments? I agree with Noam that M-q elsewhere makes very little sense. > But even if that was the case, then just use > the buffer local fill-column in a hook (as above). No need to introduce redundant mechanisms. It isn't redundant, because with the additional option we can set up things so that Emacs does TRT by default out of the box, and in most cases no customization by users is necessary. > Ok, I'll take a stab at the easy way out and just update the docs. When looking at the implementation in the > function lisp-fill-paragraph, the outer or-clause seems to separate two cases: 1) if in a comment use > fill-column, else 2) bind fill-column to emacs-lisp-docstring-fill-column and call fill-paragraph. Does that seem > to be correct? Yes, I think so. > In that case the current doc could be changed from "Value of `fill-column' to use when filling a > docstring..." to "Value of `fill-column' to use in emacs-elisp-mode except in comments". Sounds good, but I think we should also advise against using this except inside doc strings (and perhaps any other strings). > But I still think the original intent of emacs-lisp-docstring-fill-column (as described in its current doc) is useful, > and would of course prefer if we rather could update the implementation to reflect that functionality instead. I'm > just not knowledgeable enough to do a PR. Would it be difficult? You mean, make it work only inside a doc string? I guess that would be possible, yes. > BTW, as a side note, I just wanted to add that this bug report is of course a very small detail. Also, if my > language sounds a bit harsh, its just because I'm in a hurry. I'm really grateful to you and the community for > putting in all the hard work so that people like me can use such a superior tool - thanks a million! No need to apologize, there's nothing wrong with your language. Thanks.