jefito

Nested tags in Evernote are mainly for organizational purposes, and not for exposing semantic hierarchies. It's been that way since Evernote added the nesting capabilities, and was acknowledged by them at the time. And they understand the difference. That tag nesting exists doesn't make them non-useful; they are exactly as useful as before nesting came around, but now you can organize them, which makes them more manageable, so long as you don't fall into the trap of assuming that they behave hierarchically with respect to searching. Auto adding tag parents is problematic; in my opinion; it's coming at the problem from the wrong end. I think that enhancing search to allow for hierarchical functionality would be the way to go: i.e., the ability to search for notes labelled by a tag and any of its subtags would give users the ability to treat their tag trees as semantic hierarchies, which seems to be what some of them want.

Posting a request in forum serves as a feature request. As nearly as I can tell, Evernote folks do read every post, though they don't always reply.

This has been requested, possibly not in the scope of what Evernote is aiming to provide (but hey, you never know).

Erm... Syntax error, line 1: expected ';' before ')' Maybe you need syntax checking too...

That's fine, but working with tags is generally better supported in Evernote than is working with free text in titles. For example, in the Windows client, you have an easy way to tag multiple notes, which would be difficult to do with keywords in titles. You must be very disciplined.

Right -- just trying to illustrate that things that are easy to describe may not be the best choice.

Hmmm, bubble sort is easy to explain, and it's not hard to get a correct implementation of a bubble sort, but so what? Implementation is not usually the problem, it's choice of algorithm, and bubble sort is of course notoriously poor for anything but the most trivial uses. I think you're right -- there are probably fail cases in any algorithm that will be used to pick a thumbnail candidate out of a collection of images. I think that making a good guess is fine, but the best case for users would probably be to allow them to designate which image to use if the guess is not the one that they want.

OK, got it. I think anything else would have too many words, and "largest smallest" probably works because it's short and easy to remember (and apparently self-contradictory). Cool.

Oh. My. God. You really don't get it... I really do get that your feature request has merit. I just don't think that it's as important as you seem to believe, particularly since there's a workaround (i.e. cut'n'paste). It's still allowed for users to have differences of opinion, last time I checked. It'd be OK to keep the melodrama down to a dull roar...

I think that actually Evernote's note editor is actually pretty stripped-down; not that many bells and whistles. I just tried Microsoft Word 2010 (a program that has many bells & whistles, if ever there was one); that doesn't support the Shift+Alt+Arrow shortcut either. And you can always cut'n'paste. So I don't really see this as quite so "glaring". Sorry it doesn't match up with your needs, however; I don't mean to imply that it's a bad idea.

That's the official response -- Dave is the CTO of Evernote. It's by design, so maybe a bug by your definition, but...

If you're using a desktop client (Windows or Mac), you can set up notebooks as "local", meaning that they do not sync to the cloud. Caveats: * You mush choose whether they're local or synced at notebook creation time; there's no changing once they're created. * Notebooks that aren't synced are not backed up automatically. You'll need to do that yourself.

Nine worked beautifully, pasting from Visual Studio into the Win 4.3 version of Evernote. Didn't work so fine posting into the new web interface.

That is correct, there is no way to do this in the client that I use (Windows, the web).

Tags are nested by merely dragging and dropping in the tag tree. Drop a tag onto another tag, and the tag (and all of its children) will become nested under the second tag. Drop a tag on the "Tags" label (it's not a real tag) and the tag and its children will become top-level tags. Stacks are merely collections of notebooks; they're nice because they allow you to organize your notebook list (you have a max of 250 notebooks -- managing them as a flat list can be onerous) and certain operations, like search can be applied on a stack of notebooks. Notebooks are merely flat collections of notes.Notebooks and stacks appear in the Notebooks list. Stacks cannot be nested: if you drag a stack onto another stack, the notebooks will be moved from the first stack into the second stack, and the first stack will be deleted. Notebooks cannot be nested in other notebooks. However, notebooks and stacks coexist in the root of the Notebooks list; stacks are there to allow you to organize that list better. The Knowledge Base is a work in progress, and more topics are being added.

Nope. Each note in inside of exactly one notebook. Notebooks can be nested, to one level, inside a Stack, but you cannot nest a notebook inside another notebook. Stacks cannot be nested. Notes can be associated with tags, and tags can be organized in a hierarchical tree, but they are not themselves functionally hierarchical. There's plenty of discussion here on the forums on this topic, if you care to search.

No problem -- thanks for making the suggestion and presenting it well.

Except that you left out the actual UI work, before you pitched it over the wall to QA. Off the top of my head (and guessing at the behind-the-scenes machinery): * adding the right-click menu item for "Convert to LaTeX image", and its converse (but only when the alt text indicates it's a LaTeX image), and hooking up the handler code * fetching the LaTex conversion URL service from the preferences (and adding UI to set and maintain that in Options) * handling any errors from the HTTP GET operation (which itself can fail) and any appropriate user notification * converting the image to whatever internal format Evernote uses and storing it in the appropriate place * Making sure that the Undo's are handled correctly * Adding the unit tests (if they're used) * Handling undos if anything special needs to be done * Handle the converse of the convert-to-LaTeX operation: replace element (however its represented in Evernote) with its alt text string * Write up the test cases for the QA engineers * handle any other host of seemingly trivial but time-sucking tasks that need to be done Anyways, I know what you're saying. This is not in the realm of rocket science in terms of complexity. It would be an interesting addition. But the question always remains for the developers: is it worth whatever effort it takes for the expected benefit? That's a question that I usually step away from, because I'm not privy to any of Evernote's internal plans. So good luck...

I'm still not sure where you get the notion that this is all so easy for Evernote to implement.

That's not a problem at all, you've misunderstood my idea. The only thing needed is an option in the context menu that converts the selected text to an "existing web-friendly renderings like JPEG, GIF, PDF, etc." by using a web service that interprets the text as LateX (or MathML). That's everything! To be fair to Dave, your original proposal was automatic conversion of '$' delimited text into LaTex generated images. By changing the requirements to a right-click option after Dave replied to you is just moving the goalposts. BTW, I do think that a user-initiated approach is better in the context of Evernote.

Nope, it isn't XML: http://en.wikipedia.org/wiki/LaTeX

That's cute, jbenson. I'm certainly nerdy enough to get the joke. Even so, I'd rate this as an interesting idea rather than great, and I have some doubts as to how widespread demand for this would be. Not that it's wholly conclusive, but i founds only three threads in the forum from a search of 'latex', plus some google hits.

I guess a question would be how you would disambiguate between this use of '$' delimiters and other uses of '$' that don't designate LaTex, in a backward compatible way? I would think that this makes things not-so-simple. Probably means storing the original source into an 'alt' attribute, and then you need to interpret all of those for the special LaTeX delimiters too.

When you found problems, did you report them to baumgarr (the Nevernote developer)?