Exchange "-" with "_" and vice versa

[tsalo]

Stems from https://github.com/INCF/pybids/issues/18.

Currently a filename in BIDS would look like: sub-03_ses-audio_run-08bold.nii.gz. The delimiters are such that separates categories and - separates category from its value.

When debugging it is often desirable to scroll fast and systematically through chunks of text at a time instead of hitting the left arrow key and having to scroll through each letter. On my mac I use option+arrow_key.

The issue that I want to raise is that the way mac keyboards parse text is it jumps through _ and stops at the -. For that reason I'd like to propose a change to the standard.

from: sub-03_ses-audio_run-08_bold.nii.gz to: sub_03-ses_audio-run_08-bold.nii

This makes scrolling through filenames and paths more attuned to the way keyboards parse text when scrolling and therefore easier to select copy paste chunks that belong together.

Original authors: @andrebeu

[tsalo]

@thomasbeaudry wrote:

I disagree with this. we have been programmed to associate underscores with new words, It would require relearning how to parse information

[tsalo]

@chrisgorgo wrote:

Yes - in fact there is a current proposal for doing this withing BIDS 1.x Hava a looka najoin in at https://groups.google.com/forum/#!topic/bids-discussion/ABOJ57ObXGM

[tsalo]

@TheChymera wrote:

I also disagree with this suggestion. It's a big change and the rationale is really insubstantial.

[TheChymera]

@andrebeu I would like to re-state my opposition to this and elaborate. Really this sounds more like an issue with mac or whatever shell implementation you are using. Tweaking a standard to fit to one particular UX design I think is a mistake likely to cause a lot more problems in the future. Manual debugging workflows know no bounds in their variety, and a standard cannot be formulated to accommodate them all. But UX choices can be made to allow you to deal with any standard. Perhaps you can tweak your shell (or if impossible, switch to a more hackable shell like zsh) to make your usage of this and any other format easier.

@thomasbeaudry 's remark I think is correct, and in addition, even in the absence of such a convention, the broader width of the underscore and its lower position compared to the minus make it a visually more substantial delimiter.

[tsalo]

@TheChymera To clarify- I'm also opposed to the change. I just copied over existing conversations from the BIDS 2.0 Google Doc.

[TheChymera]

@tsalo sorry, from the phrasing of the text I thought you were the original author. corrected ^

[yarikoptic]

I think this is a clear wontfix so I will just close it