🏠 back to Observable

Bug: Cannot collapse cells without active code

  • If a cell contains nothing but comments (e.g. because the whole cell body has been wrapped in a /* */ comment), the cell no longer collapses, and the pin icon is missing.
  • Pinning/unpinning via the keyboard shortcut increases the revision count, but has no visible effect.

Steps to reproduce:

  1. Create a new notebook
  2. Add a cell and insert the following content:
    // Comment line 1
    // Comment line 2
    

Workaround: Append or prepend a JS value (e.g. "") to the comment block.

This is the intended behavior.

2 Likes

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:


than like this:


We could special-case new cells as “not yet evaluated”, and have the 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.

4 Likes

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.

1 Like

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. :slight_smile:

I’ve filed a feature request for disabling cells.

3 Likes

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. :wink:

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
/**/
1 Like

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. :slight_smile:

[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. :wink:

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:

  • For starters, please stop believing that one can’t productively write code on a German keyboard.
  • Secondly, remapping only works if you never touch another computer again. It’s annoying enough to mentally switch between Mac and Windows. If I’d also have to remember different virtual layouts, I’d probably just stop programming instead.
  • Lastly, recommending someone to remap their keys is almost never a valid solution. It’s a last resort if a piece of software is unsupported or you end up with a stubborn software author and no alternatives. And even then you’d tailor the mapping to a particular application. But Observable is a web app, and changes would apply to all web pages.

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.

1 Like