Teie kommentaarid

Of course, it is totally up to you. But if I were in your shoes, I'd make scripting support TOP PRIORITY. That way, new features would be implemented *for* you, instead of *by* you. Not least, it's a position that will likely decrease the size of your task pipleline as well. ;-)
Well, how about providing a scripting engine in the form of a plugin then? I know a number of cool applications that do just that.

About your argument that scripting would bloat the app size: That is not really true. A Lua or JavaScript engine is generally leaner than a descent plugin system is. (Just look at Eclipse' plugin system, which is a "descent" one. ;-))

And if you count the size of plugins compared to the size of scripts, the scripts win hands down. This is a factor to consider, too. With an add-on system, the goal is to keep the core lightweight, but that also means that a real user would ultimately have to install a number of add-ons as well in order to gather up his desired functionality. (Again, look at Eclipse, or WordPress, or any other add-on-enabled application. They practically can't exist without their add-ons.) If the add-ons were scripts, each add-on would be only a fraction of the size of a plugin. The total program size a user has installed would be much less.

There is another aspect: PR!

If there was a scripting system in place right now, without the need to run (and probably install before) a full blown compiler suite / development environment, I would have already implemented the scripts for my most wanted extra functionality. And if there was an "add-on market", where I could upload those scripts, I would have done that, too. And I'm not an exception there for sure.

Reduce the hurdle to creating add-ons, make it easy to share them, and your code base and thus your application's value, as well as the buzz around it will explode. If you did that with C++-based plugins, you'd limit the user base who can contribute and slow down the whole process by a factor of at least 10. (In fact, I'm afraid it'd be more than 10, as I suspect the number of C++ developers is dramatically declining world-wide.)

How fast do you want your application to spread?
> I see it more as a "preview" and "read/edit" modes ;)
And what will be the difference there? Never mind. ;)

> But I don't really see that there's real usability difference between converting asterisk-prefixed lines to list items and selecting all list items and pressing a shortcut like Ctrl+L.

I understand that from a purely technical viewpoint there does not seem to be a big deal with either, but from a usability viewpoint there is a huge one. The first one (asterisk auto-converted to a bullet point) feels extremely natural. That's the way you would enter bullet points in pure text mode either. When you write on paper, you also enter a bullet point (or a dash) first, you don't write down all the lines and convert them later to bullet points. The "Zim way" (which BTW is also embraced by MS Word, OpenOffice and many others) preserves the natural flow of actions by interpreting and adapting to natural user input. Good user experience is created where the program adapts to the user, whereas your Ctrl+L alternative forces the user to adapt to the program and learn YET ANOTHER artificial shortcut. (How many shortcuts is a user able to memorize?)

The thing is, I can preach here whatever I want, usability can hardly be measured, or expressed in words, it must be experienced. You can come up with any logical argument about lines starting with '*' and whatnot, but user experience is not a matter of logic, but a matter of feeling. You can trust me on this.

BTW, lines starting with '*' are not a problem at all. Even if a human would want to start a sentence with '*' (other than intending a bullet point), he would just enter that in the most natural way:

* *some text

The program will, of course, only convert the *starting* asterisk to a bullet point.

Note also that - different than MS Word & co. - Zim adapts to user input immediately, not only after pressing ENTER. Immediate feedback also improves user experience (but only if it's unobtrusive).

You are right about the drop-down on "[note:" though. Just listing the note titles would probably be too little an information to choose from, because it would require carefully chosen titles, which not every note collection will have.

Let me also note that the drop-down content is not related to whether it is triggered by "[note:" or by hitting some keyboard shortcut. (In fact if you separate the trigger handling from the action you could flexibly implement both trigger policies. One trigger plugin for every taste, he :))

OK, I can probably imagine some good ways to accomplish the note selection for a link, but wouldn't sharing that make me at least a contributor of your project?
Hi Alex, glad you agree.

My main concern was to point out that even there are several request regarding different types of links, they should not be viewed as different features, but as one feature with different applications/facets.

As I see it, you already have separate "viewing" and "editing" modes, and there is nothing wrong with that. (I'm really happy with it, and I sure won't vote for in-place editing.) That does not mean though that you *have* to go with wiki syntax.

To my taste, Zim (http://zim-wiki.org/), combines both wiki-style and WYSIWYG input in a really impressive way. What they generally do is this: If you enter something in wiki syntax, like a star ('*') for bullet point, they automatically convert that to a bullet point *as you type*. But you only need to do that for the first bullet point. The editor adds bullet points upon enter just the way other WYSIWYG editors do. I think one can learn a lot about usability from Zim. (As I know there are WYSIWYG requests elsewhere, perhaps implementing them "the Zim way" would be great.)

However, when it comes to interlinking, CN does not lend itself well towards wiki-style. Different than wikis, in CN you won't go naming your notes like "SomeNote". Especially with the (really cool) clipping feature, I'd just keep the note title as it is, but it would be cumbersome to link to it that way.

I already mentioned two other ways of dealing with (internal) links: Copy/PasteLink, and auto-completion dropdown. Combining the latter with "the Zim way", the dropdown could show upon typing "[note:" or "[tag:", and auto-complete to "[note:<selected item>]" or "[tag:<selected item>]". A user setting could control whether the link text of internal links (say [note:foo]) is displayed as such, or automatically converted to just "foo" (possibly prefixed/suffixed with a cool little icon denoting the link type).

OK, that was just some quick brainstorming on this topic.