/* */ comment), the cell no longer collapses, and the pin icon is missing.Steps to reproduce:
// Comment line 1
// Comment line 2
Workaround: Append or prepend a JS value (e.g. "") to the comment block.
This is the intended behavior.
May I ask why?
My use case is to uncomment large chunks of code that would otherwise report as error, and that I want to get out of the way. With the current behavior I need to apply above workaround.
If the only reason is that the cell would produce no output and thus be almost invisible, perhaps a better solution would be to have it produce undefined, which can be picked up and displayed by the Inspector?
When you create a new cell, itâs in the same state as a cell with no code in it (not counting comments and whitespace as code); we know the output will always be undefined. Weâd rather show new cells like this:
undefined output appear when you first shift-return. But this doesnât work with multiplayer editing because the new cell appears immediately (and is evaluated) upon creation on other editorsâ windows, too.
We have a couple of related, competing improvements planned.
First, weâre considering deferring saving a new cell until you commit some code to it, rather than saving it (empty) immediately upon creation. This would avoid the problem of the empty cell with undefined output appearing with multiplayer, and perhaps then we would only hide the cell output when a cell is not yet evaluated, not when itâs empty.
Second, weâd like to synchronize cell evaluations independently of edits so that we can synchronize and potentially save edits in realtime (per key stroke) with collaborative editing. This isnât trivial because it will mean that the output of a cell can be âstaleâ (reflecting an older version of code), even when you arenât the person who edited the code. We need to design that state carefully. And weâd then want the empty cell appearing immediately upon creation, so that we can see a remote editor typing into the new cell.
I hope itâs clear there are a lot of subtle considerations in play here.
If you donât mind me asking, why do you want the error to âget out of the wayâ? Why is showing undefined better than showing the error message? Are you essentially keeping track of which cells need fixing when something is broken, and using commenting to focus on one broken cell at a time? Something we could do, potentially, is to offer a âdisabledâ state for cells, where we donât run the code. Then you wouldnât have to comment out all the code to prevent it from running.
Wouldnât it suffice to check if the cell has content, as opposed to executable code?
Absolutely. The only consideration that I had taken into account was the unexpected change in cell behavior.
In this particular instance the cell contained broken code that resulted in a syntax error. I wanted to hide the error so that I could focus on other cells first, but scrolling past the cell I had to mentally âfilterâ the error message every time. undefined on the other hand is less visually intrusive and can be ignored more easily.
For me personally an undefined output also equals âtodoâ, as I almost never have cells that return it.
This would be preferable to commenting the code. If Iâm not mistaken someone else had also requested this in another topic.
The âdisabledâ state would be useful. Recently I accidentally evaluated a cell that stole the focus in an infinite loop so I wasnât able to click in the source to comment it out. I ended up deleting the cell from the cell menu (I also could have fixed it in safe mode, of course).
Sure, and I think we might have even done this at first, but then it felt weird that a cell with just a space in it behaved differently than an empty cell. It was a slippery slope from there to using the parser. 
Iâve filed a feature request for disabling cells.
Hereâs an alternate heuristic:
code.trim() === ""
Instead of commenting out the cell, let me recommend as a workaround just putting a syntax error at the top. e.g. turn:
foo = { ... }
into
x foo = { ... }
The cell already contained syntax errors. The point was to get rid of the error message. 
By the way, thereâs a simple pattern to âtoggleâ comment blocks. Wrap code in:
/**/
const foo = bar
/**/
Remove the first asterisk to comment the whole section:
/*/
const foo = bar
/**/
This version is a pain. Instead select all and press command-slash.
How so?
That doesnât work with a german keyboard layout.
My condolences. Trying to write code on many European keyboard layouts is pretty horrendous unpleasant, since programming languages were designed with something more or less like the US layout in mind (I know several European programmers who use US-ANSI keyboards for that reason).
I would recommend looking into your operating systemâs facilities for key remapping. 
[For anyone who uses a Mac, let me recommend buying hardware with the Japanese keyboard and remapping the keys to match your preferences; the Japanese keyboard has two useful additional thumb keys.]
No worries, I can write code perfectly fine (unless itâs a Windows layout or, worse, the Spectre x360 with its switched keys). And while Iâm almost sure that you were joking, Iâd rather write a desktop client for Observable than remap my keys.
No, not joking. You donât need to completely replace the keyboard layout, just give yourself an easier way to type the most common ASCII symbols used in code.
If I search the web for âgerman keyboard programmingâ most of the first page of search results are Germans talking about trying to learn the US layout because QWERTZ is so unpleasant for coding.
That may be true for the Windows layout, but Apple did a decent job with the Mac layout.
Thatâs really not a practical advice:
Do whatever works for you. Personally I am glad to be able to re-map my keyboard in a way that helps me better access the symbols and actions I need, and would recommend other people try doing the same, as it can make using the computer more enjoyable and efficient. I believe this advice to be eminently âpracticalâ.
But if you prefer to stick to a stock European keyboard layout nobody is going to stop you.
But anyway, for those on keyboard layouts with an accessible slash key, let me recommend command-slash as a way to comment out selected blocks of code. This was a TextMate shortcut that was copied by the TextMate clone Sublime Text, worked its way through other derivative editors, and now has been adopted in Observableâs editor view. As a long-time TextMate user I find it very convenient.
For people who donât have and donât want to have an accessible slash key, I donât know what to tell you. I guess petition the developers here to make the keyboard shortcuts more customizable so you can use something more accessible than command-slash.