From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Just a thought about comment-line Date: Sun, 31 May 2020 14:53:46 -0700 (PDT) Message-ID: <6b91b604-938b-4325-94bd-ba5fd36c02f5@default> References: <306c7cf5-6cfc-436e-a902-8ad4560b32d1@default> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="52363"; mail-complaints-to="usenet@ciao.gmane.io" Cc: PEDRO ANDRES ARANDA GUTIERREZ , emacs-devel@gnu.org, Yuri Khan To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 31 23:55:00 2020 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 1jfVv1-000DUl-VV for ged-emacs-devel@m.gmane-mx.org; Sun, 31 May 2020 23:55:00 +0200 Original-Received: from localhost ([::1]:47790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jfVv1-0007XR-07 for ged-emacs-devel@m.gmane-mx.org; Sun, 31 May 2020 17:54:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57384) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jfVu4-0006sa-8B for emacs-devel@gnu.org; Sun, 31 May 2020 17:54:00 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:50652) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jfVu2-0007g5-QJ for emacs-devel@gnu.org; Sun, 31 May 2020 17:53:59 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04VLq3uw154815; Sun, 31 May 2020 21:53:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=zvPGGxp5nu5pDHpeD/jM3ME7VLLD/KcXeNzx9zHc4AA=; b=QsgFuwVlCnODRRzYlPzn+0Pb0dXxNl3gV4TVnibmQn9w8gpgMe1nr4uik0Z2bOWMKDHm s/mSvb8/yVZwZPH8cD1RPuQr7Z7fozdgDGIZ5sTZM3A/JhIEnOBL3FuKhUJvY7h+4oY6 7p5Pm+ViGbSU++vT+XJEOk5WBo6glI0ueuBQl9hyXXiLQ4nYBkonID/h6h/2kI5EseoO W+N1vKJq4CghRHJsu250VjFKeE1faGuUGQqu7xnMxpIXHTYjILNUU3QScxyGe8SklEcd kqUVKhVkWfA1JS2MwD2vOl7x6T7CoN3On+OMQez9h8wAxxFfdIIIHriSka90YRC2Bhs7 4g== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 31bg4muxjq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 31 May 2020 21:53:54 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04VLrG65123284; Sun, 31 May 2020 21:53:53 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 31c12kgmy2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 31 May 2020 21:53:53 +0000 Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 04VLrpqA028021; Sun, 31 May 2020 21:53:52 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5005.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9638 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0 adultscore=0 suspectscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005310181 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9638 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 lowpriorityscore=0 malwarescore=0 phishscore=0 suspectscore=0 priorityscore=1501 adultscore=0 mlxlogscore=999 cotscore=-2147483648 bulkscore=0 mlxscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005310181 Received-SPF: pass client-ip=156.151.31.85; envelope-from=drew.adams@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/31 17:53:57 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:251699 Archived-At: > >> It automatically decides whether to comment or to uncomment, indeed. > > > > Precisely. It's a compromise, and not a > > great one (IMO). Better to have two > > commands, one for block commenting and the > > other for end-of-line commenting. >=20 > I have never seen someone comment a comment. > Do you have a use case for it? Commenting out some code, perhaps temporarily. Doing so regardless of whether some, or all, of it is already commented out. And maybe doing so again, with a larger scope. And then maybe uncommenting the outermost commenting level. And so on. But let me be clear that I'm expressing, first of all, my personal preference. I don't say that everyone has to, will, or should prefer it. That said, I do think that Emacs itself should provide such behavior, e.g. some such command, out of the box. Whether it gets a default binding, or the default binding, is a different story. (In fact, it has one, `comment-line', but it suffers from the problem raised in this thread.) There have been previous discussions here about the question.[1] And although I said the same then as now, it was others who raised the question in the first place. And other suggestions given were along the same lines as what I offered. The result of the last such discussion was the addition of command `comment-line' - again, to comment whole lines. It, however, suffers from the behavior complained about in this thread: it comments an extra line when the region ends at bol. Finally, if you think there's no use case for such comment nesting ("comment a comment", as you say), then maybe you can explain why Common Lisp was so foolish as to provide for such a non-use case - with a specific, separate comment syntax, no less. The use case is described this way by CLTL2 (I already gave the URL): The main purpose of this construct is to allow "commenting out" of blocks of code or data. The balancing rule allows such blocks to contain pieces already so commented out. In this respect the #|...|# syntax of Common Lisp differs from the /*...*/ comment syntax used by PL/I and C. `comment-dwim' gets you partway there. > > It's not just that it has to correctly guess > > what you mean. It's also that _you_ have to > > guess what it's guessing you mean. ;-) >=20 > That in nature of DWIM commands, yes. That's a general problem with DWIM, commands, yes. But this one, with 10 different behaviors, for 10 different conditional situations, suffers from it in spades. (IMHO.) Since I use `M-;' only for end-of-line comments I don't suffer from its congeries of behaviors. And if others are fine with the trade-offs it makes, that's fine too. I haven't suggested changing or removing `comment-dwim' - it doesn't bother me, the way I use it. > >> Right, as a general rule, the LF char belongs to the line that it > >> terminates, so a position at BOL is really "between lines". > >> Of course, that would require a special case when START=3DEND=3DBOL. > > > > That special case is what `comment-region-lines' > > handles. >=20 > At the detriment of the other case. How so? In what "other case" does it fall down? I don't claim it always does what every Mr. WXYZ wants. I say that its behavior is straightforward and useful, and it's easy to know what behavior you'll get. And I don't argue that Emacs should adopt the exact same code. `comment-line' could be fixed, for example, so that it doesn't suffer from the problem raised in this thread. And there are a couple other improvements that could be made to `comment-line' at the same time, which I suggested when it was added, 5 years ago.[2] > > It just does this: > > (comment-region BOL EOL PREFIX-ARG). >=20 > But that's what the OP complained about when you do >=20 > C-a C-SPC > C-n C-n M-x comment-region-lines RET >=20 > where it ends up commenting 3 lines, even though > there are only 2 lines enclosed in the region. No, it does not. With that recipe it comments only the two lines enclosed in the region. Full code: (defun comment-region-lines (beg end &optional arg) (interactive "*r\nP") (when (> beg end) (setq beg (prog1 end (setq end beg)))) (let ((bol (save-excursion (goto-char beg) (line-beginning-position))) (eol (save-excursion (goto-char end) (if (bolp) (point) (line-end-position))))) (comment-region bol eol arg))) ____ [1] https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00900.html [2] https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00491.html