From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: visual-line-mode and line wrapping Date: Mon, 24 May 2010 22:52:21 -0400 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1274755954 6489 80.91.229.12 (25 May 2010 02:52:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 25 May 2010 02:52:34 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 25 04:52:33 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OGkFs-0001Tm-3C for ged-emacs-devel@m.gmane.org; Tue, 25 May 2010 04:52:32 +0200 Original-Received: from localhost ([127.0.0.1]:40245 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGkFr-0002q7-Ja for ged-emacs-devel@m.gmane.org; Mon, 24 May 2010 22:52:31 -0400 Original-Received: from [140.186.70.92] (port=37785 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGkFl-0002oC-1h for emacs-devel@gnu.org; Mon, 24 May 2010 22:52:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGkFi-0001OL-VC for emacs-devel@gnu.org; Mon, 24 May 2010 22:52:24 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:35732) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGkFi-0001O5-SH for emacs-devel@gnu.org; Mon, 24 May 2010 22:52:22 -0400 Original-Received: by gwb19 with SMTP id 19so1141223gwb.0 for ; Mon, 24 May 2010 19:52:21 -0700 (PDT) Original-Received: by 10.151.18.10 with SMTP id v10mr7238834ybi.51.1274755941421; Mon, 24 May 2010 19:52:21 -0700 (PDT) Original-Received: by 10.151.143.21 with HTTP; Mon, 24 May 2010 19:52:21 -0700 (PDT) X-Google-Sender-Auth: Zd1X3TDDSaPFrptxSTu-mQpBkAg X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125222 Archived-At: > You're preaching to the choir here (why do you think we have an "80 > columns max" limit on C and Elisp code?). This limit has really been on my mind lately. FTMP I agree with the rationale, its benefits, and am (in general) a strong advocate. However, something I find really disconcerting (and biased) is that there is a fundamental difference between (E)lisp code and C code, and the 80 col limit is far more C centric. Moreover, the convention is not particularly friendly to code that employs features from the CL package. Likewise, in the absence of _real_ namespacing third party fncns must extend by at least two extra tokens for each def* in order not to step on Emacs' core fncns. In the aggregate these factors can make it particularly difficult for third party code to meet with the 80 col rule. Following are examples of moderately sized lambda lists (with IMHO unreasonably truncated arg names): A conventional Elisp fncn from Emacs' lisp/* directory: (defun elisp-fun (arg1 arg2 &optional arg3 &rest arg4) ^^^^^!^^^^^^^^^!^^^^^!^^^^!^^^^^^^^^^^^^^!^^^^^^^^^^^! 5 15 21 26 41 53 Same Elisp fncn from Emacs' lisp/* directory with CL features: (defun* elisp-fun (arg1 arg2 &optional (arg3 arg3-dflt) &rest arg4) ^^^^^^!^^^^^^^^^!^^^^^!^^^^!^^^^^^^^^^^^^^^!^^^^^^^^^^!^^^^^^^^^^^! 6 16 22 27 44 54 66 Same(ish) but w/ CL packages keywords feature: (defun* elisp-fun (arg1 arg2 &rest arg4 &key arg3 arg3-alt) ^^^^^^!^^^^^^^^^!^^^^^!^^^^!^^^^^^^^^^!^^^^^^^^^!^^^^^^^^^! 6 16 22 27 38 47 58 User function with four token textual namespace: (defun usr-elisp-fun (arg1 arg2 &optional arg3 &rest arg4) ^^^^^!^^^^^^^^^^^^^!^^^^^!^^^^!^^^^^^^^^^^^^^!^^^^^^^^^^^! 5 15 25 30 45 57 It would be an interesting exercise to do a count of the number of defun, defsubst,, defmacro forms in lisp/* which have their parameter list split over two or more lines to accommodate the 80 limit. -- /s_P\