Jump to content

tavor

Level 5*
  • Content Count

    703
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by tavor

  1. Please add your vote (up arrow next to thread title) and your voice here:
  2. @Jason Miller I don't think I ever got a clear understanding of where the font size issue stands. Is this in the queue for a fix? If so, maybe in the next beta? Surprised no one else is talking about this. It's been a real PITA to constantly edit font sizes or just live with a mix of 10pt (pre-v6.6) and 9pt (post-v6.6) in all the notes I've edited since updating to v6.6
  3. @Jason Miller can you weigh in on this? Is there a reason why the Purge option is not greyed out when On Demand Sync is disabled?
  4. Does this option have any effect if On Demand Sync is disabled? If not, it seems a bit strange that disabling On Demand Sync does NOT automatically disable the Purge option. In other words, the options are set up so that you can have On Demand Sync disabled and Purge enabled - what happens in that scenario?
  5. Paste and Match Style changed with EN v6.6 Some of the changes are obvious errors, but retaining header formatting seems to be by design per earlier comment in v6.6GA thread. No idea why EN thought this was a good idea, but hopefully they are getting the message loud and clear from the users.
  6. As others have explained, this isn't currently possible. Please upvote here if you would like to see full boolean search implemented:
  7. It's just one more option, so instead of having two paste options in the Edit menu, there would be three paste options, all of which have shortcuts. No need for a dialog box.
  8. The point of software is to meet consumer desires, not to satisfy some purist aesthetic. With that in mind, they could request user feedback on this - i.e., would users prefer Paste and Match Style work the way it used to or enhanced by retaining hyperlinks? My guess is the latter would win by a landslide. Or provide another option, i.e., Paste and Match Style (Retain Hyperlinks). That said, if the only options EN is willing to entertain are the old Paste and Match Style or this newfangled Paste and Match Style Except for Headers, then I'm in your camp. I'd rather manually insert hyperlinks than deal with manually stripping out header formatting.
  9. I'd like hyperlinks to be retained, but that's it. Hyperlinks are easier to remove than to add. All the formatting - font, font size, line spacing, indents, etc. should all be stripped out and match the style of the target EN note. Beats me why EN thought that users wanted Paste and Match Style to retain formatting if the source material is encoded as a header. All of the comments I've seen since this was introduced in v6.6 (per earlier comment in this thread, this seems to be intentional, as opposed to the Paste and Match Style bugs that v6.6 also introduced) have been opposed to this.
  10. Is the current plan to change this to remove header formatting when using Paste and Match Style, or is EN still planning on retaining the header formatting for a function that would more appropriately be named Paste and Kinda Sorta Match Style?
  11. You might want to upgrade to v6.6 GA release or v6.7 beta and see if the issue remains.
  12. Got it, thanks! I can see why this method depends on not changing the note title. But there are many reasons why you might want to subsequently change a note's title. I suppose to preserve the ability to manually recover note links, you have to do an intitle search for a note's title prior to changing the note's title (for all notes, unless you know for sure that the note in question is not a target for any other notes), so you know which pointer notes' content need to be updated with the target note's new title.
  13. I understood the rest of your post, but not understanding this part. Are you appending the titles of notes that link to a target note? Let's say target note is called "Target Note 1". So if I understand you correctly, if you have a note, "Pointer Note" that contains a link to Target Note 1, then your full title for this pointer note would be "Pointer Note note link Target Note 1"?
  14. OK, so if you're retrieving individual notes, then to preserve your note links, you should copy the content of the imported note into the existing note (this latter note is the one that the links point to). Is that correct?
  15. That was my understanding of how .enex import works. And if you have a new note, that means no note links to it until you create such links.
  16. I'm on v6.7 beta, and CTRL+SHIFT+R works fine. Can't recall if I tried it in v6.6.
  17. FYI, there are multiple ways to link notes - the copy/paste described in the OP, dragging a note from the main desktop app window into a note opened in its own window, and using the table of contents feature. There may be other ways as well, and maybe someone can chime in on that.
  18. +1 But beware that extensive note linking reduces the portability of your data because .enex files (what you would export notes to) do not preserve note links. I'd like to see the EN editor [finally] get outline functionality, which would reduce the number of note links for most users.
  19. From the many threads and posts complaining about the various notebook/nesting limits, it seems to me that most (with some rare exceptions) do not understand the full functionality potential of tags. And it's easy to see why that's the case because EN doesn't really delve deeply into this in their help materials. I only really started to appreciate tags as I learned about them from other users in this forum. And from then on, I only used notebooks to delineate notes based on access (synchronized, local, offline, shared), not based on content. So for those who have been pining for unlimited notebooks and nesting for years and are unwilling to move to competing products that embrace notebooks, I'd suggest taking an open-minded approach and learn more about what tags can do. If you have a specific use case where you feel EN's limited notebook functionality is constraining your workflow, just describe it and I'm sure one of us taggers can suggest how it can be accomplished using tags. You might be surprised, and you may just get converted. Of course the alternative is to continue complaining - we're only at page 39 of this thread and as far I know there is no post count limit for threads, so have at it.
  20. Please add your vote here so that EN can see that users would prefer narrower margins:
  21. Please add your vote by clicking the up arrow next to the thread title at the top of this page.
  22. On Android, by default, all notes are locked, and requires pressing an onscreen button to enter edit mode. In my opinion, this is the perfect solution for mobile devices, where the vast majority of note access is for reading, not editing. Desktop is a different story, where editing may be very common. But as @JMichaelTX mentioned earlier, multiple concurrent windows and multiple monitors are common these days. I have multiple monitors and more windows than I can count open at any time, including multiple EN note windows. There have been many times where I start typing thinking the desired window is active and it turns out some other window is the active window. Seems to me the optimal solution here is not to default to locked state for all notes (which would require an unlock step prior to editing every note - this could become very onerous very quickly for those who edit notes frequently - think about journals, task lists, etc.), but to give the user an option to lock notes. So notes are unlocked by default and editable. But the user has the option to put the note in a locked state, which requires an unlock step prior to editing (can be a simple one-click unlock). Users can then lock down all their reference notes and other notes they don't anticipate updating frequently.
  23. Great, thanks. I started the other thread so that this particular issue didn't get lost in general discussion of version releases, and also to raise awareness and solicit feedback from users who don't always keep EN updated to most recent beta or GA release, and would thus otherwise be unaware of the changes to this very basic feature.
  24. I suspect it's related to the font issue raised in the v6.6GA thread:
  25. Yes, the size of the fixed margins is a bit absurd. It reduces visible content.
×
×
  • Create New...