From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: awesome feature (yet to be added?) Date: Tue, 06 May 2014 17:19:35 +0900 Message-ID: <87lhufjp48.fsf@uwakimon.sk.tsukuba.ac.jp> References: <112075085.1028629.1399142864865.open-xchange@email.1and1.com> <53684CB6.1050601@lanl.gov> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1399413852 27036 80.91.229.3 (6 May 2014 22:04:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 May 2014 22:04:12 +0000 (UTC) Cc: emacs-devel@gnu.org, Bric , Le Wang To: Davis Herring Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 07 00:04:05 2014 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 1WhnQn-0002FQ-9h for ged-emacs-devel@m.gmane.org; Wed, 07 May 2014 00:01:45 +0200 Original-Received: from localhost ([::1]:33613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhacY-0001LX-D2 for ged-emacs-devel@m.gmane.org; Tue, 06 May 2014 04:21:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhacO-0001KW-SB for emacs-devel@gnu.org; Tue, 06 May 2014 04:21:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhacH-0003Mo-6d for emacs-devel@gnu.org; Tue, 06 May 2014 04:20:52 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:38040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhacG-0002WA-Jw for emacs-devel@gnu.org; Tue, 06 May 2014 04:20:45 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 08356970AD9; Tue, 6 May 2014 17:19:36 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id EB0D11A3389; Tue, 6 May 2014 17:19:35 +0900 (JST) In-Reply-To: <53684CB6.1050601@lanl.gov> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:171708 Archived-At: Davis Herring writes: > Le or Bric wrote: >> Judging by the uptake. We are the only two to think this is >> useful. :) There is an ancient solution with ancient support: use #ifdef, not comments, to control the language translator, and use hideif to control your Emacs display if you like. hideif wouldn't take much work to "grey out" instead of completely hide the "inactive" code, now that everybody has GUI displays capable of that. > I thought about implementing `invert-comment' a few years ago, but > I wasn't sure what to do about code like this: [omitted] > Your idea of markers likely works out better than "toggle the > comments" because of cases like these. I don't see why it would. The markers would need to be user- maintained to handle the cases you presented. And therefore, highly problematic[1], even if you provide high-level helper commands. Finally, there's another case you didn't mention: overlapping "togglable" comment regions. If one really wants to use comments for such cases (whether because of personal preference or because of a style guide that doesn't allow or strongly discourages random #ifdefs, or a language that doesn't have them[2]), (1) you could use C++ and be consistent about which comment convention is for comments and which for poor-man's ifdefs, or (2) you could hack up VC support (ie, each toggleable comment configuration would be a separate branch). Solution (2) probably requires insane amounts of branching and merging (combinatorial explosion of "#ifdef branches" since each local alternative would require a pair of branches on top of each existing #ifdef branch-pair -- could be lazy, but still...), so only git could really support it, and you'd need to have substantial automatic support for picking the right branches when switching for the same reason (especially if "lazy", you'd need to merge on-the-fly). Footnotes: [1] I wonder if such development techniques weren't involved in the recent embarrassing gnutls and openssl authentication bugs. [2] Although all languages should support a conditional statement that could be used the same way with some decrease in runtime performance!