unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Davis Herring <herring@lanl.gov>
Cc: emacs-devel@gnu.org, Bric <bric@flight.us>, Le Wang <l26wang@gmail.com>
Subject: Re: awesome feature (yet to be added?)
Date: Tue, 06 May 2014 17:19:35 +0900	[thread overview]
Message-ID: <87lhufjp48.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <53684CB6.1050601@lanl.gov>

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!





  reply	other threads:[~2014-05-06  8:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-03 18:47 awesome feature (yet to be added?) Bric
2014-05-04  1:23 ` Bric
2014-05-04 11:12   ` Stephen Berman
2014-05-04 18:33   ` Andreas Röhler
2014-05-06  2:32 ` Le Wang
2014-05-06  2:45   ` Davis Herring
2014-05-06  8:19     ` Stephen J. Turnbull [this message]
2014-05-06 22:27     ` Robert Thorpe
2014-05-30 21:35     ` Thorsten Jolitz
2014-05-31  1:30       ` Stefan Monnier
2014-05-31 10:46         ` Thorsten Jolitz
2014-06-09 11:01         ` Thorsten Jolitz
2014-06-09 15:30           ` Stefan Monnier
2014-05-31  6:26       ` Andreas Röhler
2014-05-31 10:52         ` Thorsten Jolitz
2014-05-31 17:20           ` Andreas Röhler
2014-05-31 20:04             ` Thorsten Jolitz
2014-06-01  7:00               ` Andreas Röhler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lhufjp48.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=bric@flight.us \
    --cc=emacs-devel@gnu.org \
    --cc=herring@lanl.gov \
    --cc=l26wang@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).