From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: on adding a function call to a s-exp Date: Wed, 13 Jun 2018 07:39:17 -0700 (PDT) Message-ID: References: <864libzkem.fsf@gmail.com> <86zi026stt.fsf@gmail.com> <86wov55r33.fsf@gmail.com> <87o9ggdolh.fsf@telefonica.net> <53126606-4d8c-46d3-aa9f-f27879885b02@default> <87k1r33r0q.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1528900689 5675 195.159.176.226 (13 Jun 2018 14:38:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2018 14:38:09 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jun 13 16:38:05 2018 Return-path: Envelope-to: geh-help-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 1fT6uT-0001Og-94 for geh-help-gnu-emacs@m.gmane.org; Wed, 13 Jun 2018 16:38:05 +0200 Original-Received: from localhost ([::1]:34823 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fT6wX-0007F7-Iq for geh-help-gnu-emacs@m.gmane.org; Wed, 13 Jun 2018 10:40:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fT6vk-0007Ct-Ve for help-gnu-emacs@gnu.org; Wed, 13 Jun 2018 10:39:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fT6vh-0001wg-JY for help-gnu-emacs@gnu.org; Wed, 13 Jun 2018 10:39:25 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:42956) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fT6vh-0001tV-9e for help-gnu-emacs@gnu.org; Wed, 13 Jun 2018 10:39:21 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w5DEd7Ao184464; Wed, 13 Jun 2018 14:39:19 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-2017-10-26; bh=pHReyyMoIW8OgYWobwi/Una6WXpk4+jwj/AbcjCRNEw=; b=Ic+B6tYbpwAb21p+ki9hS2GJlCheRidTLHvhWnXYc3M6sZoqxT2DW5r7LJLJERWYiNK/ xIDtwLTbFgudwJ5rI5myJhxL/a9ZtHubwigI3UMqlTgmhl/Wy8dVzkoxoRdCw7Nkgyy2 IfeeWhfysR6a9hjVFQOh0++fe83c4553X5TQwysroniCX4Bx+7PvEP24D5YWlyeEyVZE VJsNd1g7Bpj85TwN0UlfgRApJPRJ/Aswf4KeuWBgoMXdZUaxtkpasVU7ZAK4kkKvrksl EOfFnk0fA8edtS386ne18RVgZzVAv3hETxkYQoGx0GueST3YoQ94YlfFgiWYUhwDxXK7 Rw== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2jk0xrh0w2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Jun 2018 14:39:19 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w5DEdIfg009846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Jun 2018 14:39:18 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w5DEdIG3012381; Wed, 13 Jun 2018 14:39:18 GMT In-Reply-To: <87k1r33r0q.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4690.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8922 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806130157 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:117128 Archived-At: > > FWIW (he ducks), I work with a Lispy language, Elisp ;-). And I > > don't use any "structured-editing" feature (crutch / ball-&-chain) > > such as `paredit' or `electric-pair-mode'. I'm non-electric all > > the way. > > > > To me, having an editor automatically insert a closing delimiter > > each time I type an opening delimiter is a bother, not an aid. >=20 > For the sake of improving electric-pair-mode, can you explain exactly > when/under what conditions it is a bother? A bother _to me_. People are different. People use Emacs differently. To me, it's a bother to care about the inserted closing delimiters and where they might currently be - they just get in my way. I think that if you go the route of using such delimiter-balancing "aids" you need to do it whole-hog. The ability to have things automatically closed for you _necessitates_ slurping, barfing, etc. What you see as convenience, I see as workaround hacks, needed only because you've turned on automatically closing delimiters. If things are pre-closed then, yes, of course you need commands to pull stuff inside the closings and push stuff outside the closings. You want to add a list element? OK, now you have to insert it before the proper closing paren. I don't want Emacs to assume where/when I want to close a list, vector, string, etc. I'll close it where/when I want. With Emacs it's _trivial_ to see which closing delimiter corresponds to which opening delimiter. If this were not easy to see then, sure, maybe there would be a stronger case for automatically inserting closing delimiters. In Emacs it's almost impossible to accidentally leave something unclosed or to close something in the wrong place. Automatic closing? YAGNI. > I'm asking because that's precisely what electric-pair-mode attempts: It > *doesn't* insert a closing delimiter "each time", only when it guesses > that it will not bother you. If it is mis-guessing some situation I > would very much like to know about it. FWIW: DWIM too often really means _not_ "Do what I mean" but "Do what some programmer thought would be cool to guess I might mean." I don't want Mr. Electric trying to second-guess where/when I want to close something. I don't need that kind of "help". It's easier for me to know whether a paren is escaped or inside a string or whatever than it is for some "smart" code. I know my intentions. DWIM code can only guess my intentions. And when it guesses wrong I need to go behind it an sweep up the droppings. But as I say, everyone's different. It's _good_, not bad, that such electric-delimiter modes exist. I don't argue against them. With Emacs, anyone can get what s?he wants.