I understand all but the “nano” reference. To what (software?) are you referring? Inquiring minds want to know… 
Oh. A Windows editor. Nevermind.
Oh, so emacs?
ROFL!
But it does require you to mess with formatting after you’ve composed to an external output format, because Scrivener is not a full-fledged layout program (nor does it claim to be). But with “real styles”, that should actually get easier and more straightforward – the kind of hacks Mark does to get things working nicely with NDP should become easier to achieve with .DOC and .DOCX output, because instead of today’s presets just applying one-time formatting to the text in Scrivener, the style information can also be tossed along and matched up to the document template.
This would have been AWESOME for me writing the Exchange Server Cookbook – having Scrivener pour everything out to a DOC that contained embedded style names that I’d matched to the ORA Word template. I could just take Scrivener’s output DOC, attach the template, and have a ready-made document to pass on to the publisher for edits and reviews.
So I’m afraid I don’t see how “real styles” are going to make things worse. I see them as potentially reducing (in some cases, by quite a lot) the post-formatting fiddling one has to do by allowing the style information to be part of the output so that the layout program can slurp it in and do the needful. If other people who want to cheerlead for another program and don’t understand Scrivener want to think otherwise, well, their ignorance really isn’t my problem.
Yeah, this subject is beyond me now. Pleasantly waiting till someone starts speaking English again. 
I love playing with emacs. I do it every year for about 2 months. I start with it, because I prefer writing in vim, but orgmode, so I use vim in emacs, and for a while it’s brilliantly simple, efficient and effective, and then I start thinking about interacting with DTPO and Tinderbox and I have fun setting it all up and then…
… I realise I’ve had two months of great fun messing around learning and configuring the software and not really working, and that the small bits of friction that comes from getting emacs to link to the other programs add up to more irritation over the course of a week than just using the not-very-good OSX text input in the first place. So I go back to standard OSX.
This could all be avoided if we had vim-bindings in Scrivener.
Pretty please?
That would be nice, yes, although for me it would involve a (re)learning curve I’ve found myself longing for the “open in external editor” option so temptingly available in the Research folder-- then Scrivener could just hand off the file and not have to turn itself inside out with various editor bindings…
Sorry the conversation has devolved into UNIX. But when you mention bloatware, alas, you invite us techno geeks in 
and emacs is a bloated UNIX editor-- or was, at one time, an editor…
Back to the subject of bloat,
There are a few objective measures of bloat, and for me that comes back to the ability of the developer(s) to maintain the system. I may be offended by the presence of a feature I don’t use even if it never gets in my way. That’s subjective. If the mere presence of multiple features causes an out-of-memory crash in a generously provisioned system, that’s bloat. If the developers can’t keep up with the maintenance queue, and bugs get more numerous rather than fewer, that’s bloat. If my favourite feature gets deleted in removing bloat, I may be disappointed. Oh, well.
And remember, last decade’s bloat is today’s lean app.
Wait until you see what the system will be capable of doing for MMD and other various forms of plain-text writing. They needn’t in fact have anything to do with the formatting of text, in or beyond the editor. As with many features in Scrivener, multipurpose functions are a way of doing more with less bloat (to stay on topic).
Granted most people will use them to make their font different or whatever, and maybe that will tempt some people into just reverting back into old WYSIWYG working habits, I don’t know—but functionally we’ve always had a very similar system in Presets. At least in terms of the UI inviting one to use them “incorrectly”. For example default presets ship with title and heading formats among them—in a writing system that turns your outline into functional document structure. I don’t think calling the feature something else but basically presenting it in an identical fashion on the surface will make a huge difference in “mis-”usage of the software.
Styles for me will replace a labyrinth of regular expression-based Replacements, some post-compile scripting and other downright hacks of the feature set (like using inline annotations for syntax injection instead of… comments). It might be a new feature, and thus one more tick in the toward-bloatness quotient of the software, but in terms of usage, the workflow itself is less bloated, and isn’t that what really matters?
Inline annotations for syntax injection . . . why didn’t I think of that?
I’m wondering, philosophically speaking of course, could one argue that bloat, due to its relative nature, isn’t… really… any…thing…?
Nah, it’s a pejorative term for software that annoys the speaker by its large and increasing feature set, or in my case, perceived level of bugginess that doesn’t get smaller while the feature set gets larger. As such, it’s no more precise than than any other such term. When L&L say they want to avoid bloat, I suspect it’s that they’re avoiding including every user request as rightly they should to keep their product design focused to what they want to sell and support…
I mean, no one wants to try to make a living off OpenOffice…
So bloat-free is a euphemism for ‘we don’t listen to everyone’?
Oh boy — bring dat styling bloat baby ON!!! 
No. Listen is one thing, doing is something completely different.
Besides, not every user has wishes or demands new features. Some of us just happily use the software and focus on using it instead of procrastinating by trying to come up with requests for things the software currently can’t do.
Are they required to listen to ridiculous requests? If I say that I want Scrivener to have the capability to display all formats of ebooks that I might want to import into the Research folder, and L&L decides not to incorporate it, are they ignoring my desires, or did they realize that my request is silly? They can make whatever program they want, without any input from us. Just the fact that they actually do give us a voice and consider options that we suggest should indicate that they are not the type of company that ignores its users.
Bloat is stuff that slows down the user experience, either by negatively affecting the machine’s performance or by insinuating so many extraneous features that the user is unable to work as quickly for having to fight their way through the quagmire of menus and options.
This is me to a ‘T’. I’m still on 1.8.6 because it does what I need it to do. Honestly, I’d be perfectly happy to continue using it until I stop my writing career, unless something completely earth-changing is introduced into a future version. With the updates that have been put out so far, though, the earth hasn’t changed for me. None of the new “features” improve on my own process, so they’re really examples of updates for the sake of updating.
I’m sure that when 3.0 comes out, though, I’ll probably be blown away and take another plunge.
Agreed, but I’d add that that fundamental design standard is a reflection of their overall product standard. KB and company have been consistently clear on this, without contradiction :
literatureandlatte.com/about.php
That’s what I bought and hope will never change.
Hang on a second. You do want certain features WinScriv is lacking. You’ve said so yourself.