Jump to content

luckman212

Level 5
  • Content Count

    637
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by luckman212

  1. I opened a ticket for this #2648805. in case anyone else wants to file & reference it.
  2. Thanks @DTLow So, a bug then... sigh EN Staff (are you here?) should we file a ticket for this or is this post enough?
  3. Here's an almost-2-year-old bug. It's a cosmetic one, but hoping since EN seems to be trying to fix bugs these days, maybe it can be surfaced and closed. This has existed since at least ver 6.9 and is still there in 7.5 beta 2. BUG: If the keyboard shortcuts are disabled (I don't want them) then the Clipper window shows up with the text "Press (null)(null) anytime to show this window": Links to two old related posts: https://discussion.evernote.com/topic/100661-version-692-on-macos-1012-typing-a-works-as-paste-to-evernote/?do=findComment&comment=436732 https://discussion.evernote.com/topic/100319-692-important-bug-with-hotkeys/
  4. No, it's not customizable on Mac. Please bring back the old toolbar to save us from wasted clicks. Or at least tuck this into the [...] menu where it belongs.
  5. Performance is bad. I have 9,160 notes on a 16GB core i7 mac with an SSD. Just doing a simple search gives me a beachball for about 3-4 seconds, and then a weird subset of results is shown in the note list. I have to wait an additional 3 seconds for the window to refresh again with the "real" results. I have gotten used to this but it is such a time sink. It's faster sometimes to open a browser and search google than to search my local database, which is really sad.
  6. Is it "normal" that when moving notes to a shared notebook, the original (non-shared) note gets deleted (moved to Trash)? This is what I am seeing. EN 7.5 beta 2 on Mac. If that's the expected behavior, a little note in the popup saying "the original will be moved to the trash" would be helpful to make it clear what is happening. I thought this was a bug when it first happened- and I was going to file a bug for it, but it seems this may be the actual intended behavior?
  7. I opened a support ticket (#2639285). Suggest all others affected do the same to try to raise the priority on this. I don't think the forums are monitored that much by anyone who can actually fix this.
  8. Really frustrating bug: When viewing a note on iOS (EN 8.15.1) if you click somewhere and try to edit, it always scrolls you all the way to the bottom of the note and puts the cursor there. It's really difficult to position the cursor anywhere else in the note if you are trying to edit something in the middle. I've found on long notes or notes with tables, it's basically impossible to edit so I end up just stuffing text at the end and having to go to the desktop app later to clean it up. This used to work much better, please fix!
  9. That's pretty cool and everything but honestly it's a bit embarrassing that EN still doesn't have its own built in style editor.
  10. Too bad... Ok hopefully 7.3.1
  11. 7.3 seems to be shaping up to be a really solid release. Thank you. Any chance this window sizing bug will make the cut?
  12. Great, with the bug fixing sprint that's going on, I hope it somehow gets fixed before 7.3 goes final!
  13. I upgraded 2 machines to this Beta today. So far no major issues, but one bug that has been lingering since 7.x or maybe even earlier, is that EN always slightly downsizes its Window size every time the main window is closed and then re-opened from the Dock. I have 2 screens, positioned one on top of the other (vertical orientation) ___________ | | | 2 | |___________| ___________ | | | 1 | |___________| I always keep EN on monitor #2, stretched to fill the screen. When the window is closed and then re-opened, the height shrinks by about 40 pixels leaving a blank space at the bottom of the screen. It's annoying as I always want the window to fill the screen. It's like EN is mis-calculating my resolution or leaving space for a dock (which doesn't exist) or something. By the way, this also happens if I position the EN window on monitor#1 and close / reopen it. Same 40 pixels are shaved off. Can this be fixed?
  14. I am just speechless at this point. People must be running for the exits at Evernote HQ. The "QA" (hah) team simply throws stuff over a wall at us (paying users) and is never heard from again. Bug reports are farting into the wind, peeing into the ocean, whatever. Years of issues left unresolved. Each "release" brings no useful features, just more bugs, toolbars moving around, features silently changed or removed. The core features of the app (note taking + sync) are BROKEN for months with no acknowledgement or announcement of when fixes are coming. I have zero confidence that the outsourced dev team has a clue how to manage this spaghetti code base that's been dropped on them. I am done. Life must go on and I simply can't waste any more time debugging this program. It's sad. EN was once a shining example of form & function, but it's been neglected and allowed to slowly deteriorate for years. Goodbye Evernote.
  15. Great. Now how about making that part work at least.
  16. Here's another bug to add to the code block list. I come across this one a lot. Some text in the block gets mysteriously turned into a blue URL link: I don't want this, so I select it and choose ⌘⇧K (Remove link) — here's what happens, the font becomes Arial.
  17. Thanks. Hope to see some of these fixes hitting before 6.13 GA.
  18. Wow, the QA Lead! What happened to Chantal? Maybe now some bugs will be fixed. I'm sad but not at all surprised that the ones I've been reporting for months seem to all still be there. Here they are again: Tables Code Block Blank note list Simplify Formatting File Links ...And here's another one
  19. Code blocks are still a complete mess on iOS. Pfft.
  20. The last GA release was 6.12.3. All of the bugs I have reported are present in that version. Huh?? pricing below... https://evernote.com/get-started
  21. I sure don't! I'd love it if this worked like it should. We pay to use the software. Not to test & debug it. The software should generally work. When it breaks, we should be able to report issues and get them handled in an efficient manner. Before new features are released, they should be heavily tested internally and pushed to the public after they are deemed stable instead of an outsourced development team tossing stuff over a wall and breaking things badly. This costs people time, energy, or worse—data loss. The whole process is extremely broken and has been for some time, probably since before Libin left. I realize most EN users are "free" users. I understand EN has to pander to the lowest common denominator and cut corners because there isn't enough revenue to support a proper dev & QA cycle. That is a business problem and one that I cannot solve nor have an answer for. What I do know is that if EN wants to continue to operate as a business, it must be addressed at some point or things are just going to get worse. Right now the alternative (using the ancient 6.11 version which has even more problems on newer OS'es) is worse. Damned if you do, damned if you don't.
  22. Have any of the bugs I've reported been worked on? In each release post you say some variant of "Let us know if you spot any issues" but then proceed to ignore the bugreports being sent by myself and others. It's like a trip to the insane asylum! There are bugs that go all the way back to 6.12GA that have not been addressed. This is the 8th release in the bug-ridden 6.12/6.13 series. 6.12 6.12.2 6.12.3beta 6.12.3 6.13beta1 6.13beta2 6.13beta3 And now this. Why start a new thread for each one? The idea of using a forum for collecting beta feedback and bug reports is not wise. Either make a public bugtracking system so people can view the status of the fixes & not post duplicates of the same bug --OR-- just do away with the feedback forum altogether and stop pretending to care what the public thinks. The current system is maddening.
  23. Code Blocks- it's not just the overly-aggressive URL creation. There are issues with the cursor jumping around within the codeblock, with extra HTML entities (gremlins) getting created (hurts copy & paste), fonts getting mysteriously styled within a block (shrinking font size, or text reverting to "Times New Roman"), the list goes on. There are dozens of little bugs and glitches with the codeblock handling. Anyone who actually uses them for more than a few minutes will notice them immediately, which is why I wish the EN devs would dogfood their own product instead of handing us c.rap and using paying customers as beta testers. Simplify Formatting- "Simplify" vs "Remove". If you guys are treating Simplify Formatting as Remove Formatting then name it Remove Formatting and get rid of the duplicate "Make Plain Text" menu item which I guess serves no purpose. My "use case" is that in a note with mixed content (some text of varying sizes, some code blocks, some highlighted parts) it is extremely tedious to have to go and select each individual block of text to re-format it. But sometimes you have to copy+paste something from the web that has all kinds of nightmarish formatting in it. That's what Simplify Formatting was supposed to solve. Here's a simple example: Why does it have to strip away the code blocks, mess up the table, remove the highlight? I can understand changing all the Fonts to my default Font Face + Size (good) but everything else is just wrong. The way I get around this now is I make a NEW note, paste my formtted stuff in, run Simplify, and then copy it again, paste it into the actual note I wanted to add it to, then finally delete the temporary note. It's all very cumbersome. If I wanted everything turned into plain text, I would select that option.
×
×
  • Create New...