Worked with beta 1 for 3 hours last night and had no crashes or obvious bugs, AND I love all the changes and new features. Nonetheless, here are some inconsistencies — not really bugs, more like pests—that I have had on a first run through RC b1 [apologies if others have mentioned these already — had to choose whether to play with Scrivener or read all the new forum entries]:
1 Text panel in prefs says it will replace a hyphen between words with an m-dash but it doesn’t work-as shown here – unless you put a space before the dash. It also looks to me as if this is an n-dash (–) and not an m-dash (—).
2 needs a hotkey for ‘Show ruler’
3 can import rtf files by drag/drop but can’t export that way
4 Doesn’t remember screen position wne you jump between text docs
5 Would be useful to have docs that are not incl in export marked differently in the binder
6 I’d rather have a a button or toolbar on inspector to toggle between Supporting Materials and Metadata
7 How about control click to delete annotations? And maybe a delete option when you view all annotations, and a delete all annotations option
8 I prefer the usual open/save dialog box when creating a new project as I create projects within separate folders for each project, and I use Default Folder which doesn’t work with Scrivener
9 When I delete an item out of a numbered list, the list does not renumber immediately
10 Can’t tell if a picture is selected in Notes
11 Outliner, annotation and corkboard icons should change to show that you are in those modes and thus indicate that clicking on them will return you to your doc or to regular text, in the case of annotations

Hi Bob, thanks for the feedback. To address them:

This is normal behaviour, and exactly how it has always worked. Generally, you only want a longer dash when there are spaces around it, as in: “Look – there!” When you are hyphenating words, you want the short dash: “Hot-darn!” So, the longer dash is only created when a space is typed after it. Also, note that the hyphens in the default Courier font are a little bit funky; the ones that should be longer actually look shorter, if I recall correctly. Try it out in a different font. If you need to change hyphen type quickly, select just the hyphen and hit the hyphen key - it will toggle between hyphen types (the same works for quotation marks).

Somebody already pointed this out and its fixed for beta 2.

This is intended behaviour and won’t be changing any time soon. Use Export Files… if you want to export individual files (or all of them). In SG, it could just drag files contained inside the file wrapper directly to the Finder as a copy, but because of the change of file format, this is no longer possible (there is a difference between the names the documents are given internally and the ones they display in Scrivener now, so that you can have duplicate names if you so wish). It is a lot more complicated to drag files into the Finder that don’t actually exist yet, which is why everything is done via Export Files… instead.

Sorry, could you explain this one? I don’t understand what you mean.

Hmm… Interesting. In what way. The only thing I can think of is to fade them out a little, but this is used as a visual indicator for files that are in the trash, so that wouldn’t make sense. Not sure about this. No one ever suggested this for SG, which worked just the same.

This is something I thought long and hard about. The trouble is that the bottom bar on the right is where the window resizing knob is, so it has to be subtle and allow the resizer to stand out. One solution would be a tab view, but then you would have a glaring blue area in the bottom corner to indicate selection. I implemented keyboard shortcuts so that it shouldn’t seem to awkward switching between views - Cmd-3 and Cmd-4 will get you between those views very quickly.

Not sure about this one, as you could delete all annotations by mistake. Shouldn’t annotations be something that you look through carefully? I think this is one for discussion post-1.0.

Scrivener’s file format isn’t “usual”, sorry. :slight_smile: There are certain files that Scrivener needs to create before it can even open a project window and let you start editing - hence the “Create Project” assistant. This is standard for a lot of applications like this (see Copywrite, Xcode etc). Not sure what you mean by “Default Folder”…

Sorry, but you’ll have to write to Apple about that one. :slight_smile: The bullet points and numbered lists are part of the Cocoa text system that comes free for any program that uses it. Go check out TextEdit and you’ll see that it behaves the same way.

See 9. :slight_smile: This is normal when selecting images in Cocoa text views. Not much I can do about that, I’m afraid.

This one has been discussed. In brief: I considered this. But these are toggle buttons. Toggle buttons in toolbars very rarely change to show their state. Consider the Inspector button. No one has suggested that that should change state to show that the inspector is visible, because people are used to that behaviour from other applications. And yet the corkboard and outliner icons act in the exact same way. The reason toggle buttons like this don’t change to show their state is that it is very obvious from the window itself what state the view is in. If you have a big corkboard with index cards pinned to it staring out at you, you can be sure that you are in corkboard view. :slight_smile:

Again, thanks for the feedback!

Hmmm, not sure how this works in your neck of the woods, but an em-dash has many uses in mine and never has spaces around it. The most common use for an em-dash is to indicate a sudden change in thought or an added or digressive element that you want to introduce within a sentence, which is how I use them—and I use them often. :slight_smile: The way I have it here is exactly the way it should be. There is no space around the dash on either side. In fact, if I saw spaces, I’d immediately take them out (which might explain why I’d occasionally see them that way in my days as an editor).

Right now I have Typinator make this change for me, but I’d love to have it built into the program, since it’s the only thing I use Typinator for at all (I use TypeIt4Me for everything else).


There is no way that Scrivener can tell whether what you want is an em-dash or a hyphen, though; besides which, in my neck of the woods an em-dash does have spaces around it. Although that might just be me. :slight_smile:

Regardless of questions of style, as I say, Scrivener cannot decide for you. In most cases, a dash between two words without spaces will be a hyphen, as in wot’s-'is-name. Given that this is the most common case, it would be highly annoying if Scrivener changed a hyphen into an e-dash every time it encountered one. If you want an em-dash without spaces around it, just type your hyphen, hit shift and the back arrow, and hit the hyphen key again. Toggle until you get your em-dash, hit the forward arrow, and carry on typing. This is quicker than the usual way of getting an em-dash.

And if you don’t like this system - well, just turn it off through the Preferences to get Scrivener to act just like TextEdit or any other Cocoa text editor.

All the best,

The spaces or no spaces bit is a regional/demographic style issue. It even differs within North America. In Canada we use spaces. Informal USA uses spaces, formal USA does not use spaces, such as the Chicago Manual of Style. So there is no “right,” on this one.

Anyway! How about adding detection of a double-hyphen as a trigger? Using a double is a pretty old standard that goes back to the typewriter days, and definitely survived through the ASCII days of computing. That way you can em-dash without spaces–like so–and it is clear what is going on.

Yes, of course, this is right. A single hyphen should stay that way, and an em-dash is normally indicated by a double-hyphen. I just took for granted that ‘replace hyphens’ meant double-hypens. Sorry. You are quite right, of course, that this is a regional thing. But in U.S. academic world, which is where I’ve been doing a good deal of my recent writing and editing (for academic presses mostly—usually Chicago or MLA style), em-dashes don’t have spaces.

In any case, if this could be a preference as AmberV put it, where the double-hyphen becomes an em-dash, that would be great. If not, then I’ll just use Typinator as usual and no worries!


I like it. It’s on the ever-growing list. :wink:

Thanks for the thoughtful responses. My apologies for not providing more details, so here is a little more clarification on some of my suggestions:

DASHES: some others have addressed this already and it’s clear now that there is variation in the way m-dashes are displayed wrt spacing. Nonetheless, Scrivener produces an n-dash (option-hyphen) when your space-hyphen not an m-dash (shift-option-hyphen), independent of font. It’s my understanding that an m-dash is what is needed here, and I like the suggestion of replacing – with — and letting the user decide on spacing. Here are the dashes in order of hyphen, n-dash, and m-dash: -, –, —.

SCREEN POSITION: I meant to say cursor position. But note, also, that if you scroll to the middle of a long text file and switch to another file (any kind) and back, your are returned to the screen position where the cursor previously was, but the cursor is not ‘live’, and you cannot tell where the cursor was. This is frustrating when I am editing and jumping back and forth between files.

EXPORT INDICATOR: OK on this as the list is shown when you are exporting and is possible to see which files are included in export in outline view.

TOGGLE META-DATA: how about a default to show Supporting Materials in the Inspector instead of Meta-data (which I use less often)

ANNOTATION: to delete an annotation it looks like I have to select it and delete it. In SG it was possible to scroll through the annotations and delete them individually. I would like to see that implemented again, but it would also be useful to be able to dontrol-click on an annotation and have a pop-up menu give the option to delete the whole thing, and maybe even here or a menu command to delete all annotations

OPEN/SAVE: OK, understood. Default Folder is a pref pane that enhances open/save dialog boxes and it does work with Scrivener after all, you just don’t see it till you Choose a new place to create a new project

NUMBERED LISTS: Interesting, but I do not see that problem in Nisus, which I assume uses the same Cocoa text system. In Scrivener the numbers do not change until I add a new item to the bottom of the list.

I hope this makes things clearer.

If this were implemented at all, I’d rather see something that selected the annotation. Then you could either delete it with a single keystroke, or turn it back into regular text with another.

On numbered lists, I bet Nisus uses their own list engine like many other word processors do, rather than using the freebie Apple version.

yes, you’re right. his would be ideal.

Hi again Bob, hopefully I should be able to address all of these issues here:

You are right. I checked this and it was inserting an en-dash after all. Anyway, I have changed this as per the suggestions. The toggling behaviour is still there, but now, if you type two hyphens, it is replaced with an em-dash (definitely an em-dash :slight_smile: ).

Right. Cursor position is actually saved; the only problem is that you have to cilck back in the text view to get the focus. Obvously the text view can’t automatically grab the focus, or this would make navigating in the binder impossible. However, today I implemented AmberV’s suggestion of keyboard shortcuts between views. So from now on, if you are in the binder, you can hit Cmd-Alt-Shift-L and it will move the focus to the right, to the text view you want, with the cursor where it was. So you just have to get used to the new view navigation shortcuts available in beta 2, and this should be solved for you (I hope).

EXPORT INDICATOR: OK on this as the list is shown when you are exporting and is possible to see which files are included in export in outline view.

I think it makes sense as-is. You might use Supporting Materials more often, but you are likely to use Meta-data first. Given that the which one is selected is remembered between sessions, I don’t think it makes much difference either way, anyway, as you just choose the one you want to use and it will stay like that between project launches until you change it.

And from AmberV:

Is there any reason you can’t use Annotation Finder (available in the Find menu) for this? This finds the next or previous annotation in the project and selects it. I have just realised that it doesn’t scroll this range to visible, so I’ve fixed this. I’ve also just made the panel a utility panel so that is always front, and made it so that it makes your text view with the annotation key, so from now on, whenever it finds an annotation, you can just hit delete and the annotation will be gone if you so wish. I strongly recommend you try out Annotation Finder - it is useful.

As AmberV has pointed out, Nisus uses its own text system. So does Mellel and Word and the big word processors. For glitches like this, check TextEdit - that is the showcase Cocoa text editor. If the glitch exists there, too, you know it’s an Apple/Cocoa bug and beyond my reach. Given that bulleted lists were only introduced in Tiger, it could be Leopard makes some big improvements on this score…

All the best,

Oh sure, I was just saying, if you implemented some sort of direct annotation editing that it would be more flexible if it just selected the range. But, with the annotation finder, which is indeed a useful tool for some things, it is a bit of an overkill for selecting just one annotation you may already have your cursor/mouse in, especially if it is in a cluster of them that would require a lot of scrolling about. Just a thought.