From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: C-x C-e with prefix arg Date: Tue, 7 May 2013 07:16:31 -0700 Message-ID: References: <4D5891EF34DF42D3A479CF83CAF1E43E@us.oracle.com><87zjw97qo7.fsf@mail.jurta.org><87zjw9z0fk.fsf@mail.jurta.org><88878C7DA62F4DC792EEEE03D46C115B@us.oracle.com><87ip2w1ory.fsf@mail.jurta.org><87ip2vlw8w.fsf@mail.jurta.org> <87bo8ngpjr.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1367936744 2943 80.91.229.3 (7 May 2013 14:25:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 May 2013 14:25:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 07 16:25:42 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UZipp-0007NZ-FQ for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 16:25:41 +0200 Original-Received: from localhost ([::1]:48562 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZipo-00081d-G5 for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 10:25:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZin1-0004Lm-69 for emacs-devel@gnu.org; Tue, 07 May 2013 10:22:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZimy-0007UK-B5 for emacs-devel@gnu.org; Tue, 07 May 2013 10:22:47 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZih4-0005UF-6c for emacs-devel@gnu.org; Tue, 07 May 2013 10:16:38 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r47EGZwi031130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 May 2013 14:16:36 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r47EGZZA003692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 May 2013 14:16:36 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r47EGZQK025284; Tue, 7 May 2013 14:16:35 GMT Original-Received: from dradamslap1 (/10.159.172.69) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 May 2013 07:16:35 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87bo8ngpjr.fsf@mail.jurta.org> Thread-Index: Ac5K/YPg8Ut5s6/HQwKPLnCU83WrQAALnPtQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159390 Archived-At: > > IMO, it is important that `C-x C-e' with a plain `C-u' > > (more generally, with a non-negative prefix arg) ignore > > those options altogether and print the > > full value. That was the _point_ of my suggestion, from > > the beginning. > > Isn't truncated output intended mostly for beginners > to not overwhelm them with long output? If yes, > then it should be used by default. For me, truncated output is useful for anyone who wants to see the overall picture and doesn't need the exact value. That is especially important for printing to the echo area. To me, it does not make sense as the default behavior for printing the value into the current buffer. Why? Because, as I said at the beginning, I think that most users do that in order to _do something_ with the value - something that requires the full value. Typically, I want to edit it or perhaps examine parts of it in detail. You don't have to be an expert to want to do such things. By your logic, `C-h v' should also print using elision. When I do `C-h v bookmark-alist' I really want to see the full alist. But maybe another user does not. We could imagine options governing printing there too. My point is that wanting to see the full value is not something limited to experts, and wanting to see only an executive overview of the value is not something limited to novices. A better distinction is wrt the buffer, minibuffer or other, and we can make a reasonable guess as to the need (full or partial view) for each kind of buffer. I've made my suggestion wrt such guessing: when users print the value to the current buffer, I think they usually want the full value. > > Most of the time when you want to print the value, you want > > the whole value, not an abbreviation. That's my claim. > > I agree that most of the time you want the whole value. > That's why I have in ~/.emacs ;-) > > (custom-set-variables > '(eval-expression-print-length nil) > '(eval-expression-print-level nil) > > But the question is what should be the default behavior. > It seems this feature for the elided display of long lists > was created with the intention to be used by default. Who knows what was behind the original design? Maybe someone just took the behavior that made sense for the minibuffer and continued it for the current buffer too. Maybe someone was too lazy to figure out another way to do things. Maybe someone, like you apparently, felt that giving users options to configure would give them enough control over the printing. IMO, users should have a quick way of getting the full value in the current buffer, _even if_ they generally prefer the partial value and have reflected that more general preference in the user options. If you really wanted to complicate things, you could make the option record a preference for the minibuffer and another one for the current buffer. But even then, maybe a user would want to sometimes choose another behavior on the fly (e.g., using a prefix arg).