Jump to content

Klaus

Level 2
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

2 Neutral

About Klaus

Profile Information

  • Subscription
    BASIC
  1. Sadly, they haven't. Some basic hotkeys (like Ctrl+B) are available, but there doesn't seem to be any documentation on which ones are.
  2. When hovering the mouse over a GUI element, the associated hotkey should be displayed. This approach would allow "learning by doing" of work processes, without the need to repeatedly read documentation for basic interactions, and has become a defacto standard for desktop software, and is even available here in the Forum editor. Otherwise, it would already help to have a list of hotkeys available. On the long run, it would also help a lot to have configurable hotkeys, since the Evernote team cannot possibly predict all keyboards people are going to use. As an example, GMail has had for years hotkeys such as "Ctrl+Alt+[" which cannot be triggered on a German keyboard. Only "modifier keys plus default 26 latin letters" is safe for even Western keyboard layouts, with "Modifier keys plus number" already potentially failing to be registered correctly across keyboards, depending on the detection method.
  3. Sadly those solutions wouldn't fulfill the "new note visible as a browser tab" constraint :(
  4. Is there any other option to quickly add new notes? I usually need to create notes, that are subsequently open as browser tabs. Support for the web-client has recently grown more important for me, as I am given a Linux-PC at work. My workflow usually is: Create new note. Push evernote URL to another device (e.g. home-pc) with Pushbullet. This works reasonably well with Google Keep, but that solution suffers from how easy it is to accidentially close a note and from Google Keep not updating tab titles. It works less well with evernote, where the crucial "create new note" step isn't quite as fast.
  5. Rather, support for transparency in graphics is needed. I've seen the problem with Kindle ebooks too, where chapter headings, that are displayed a graphic, look badly off with any background color other than white. A solution may be tricky though for the devs. It is obviously appropriate to invert the colors of an equation in dark mode, as it would be for black&white graphics in Kindle apps, but there is no reliable way to distinguish such a graphic from a grayscale photo. Or when embedding equations as pre-rendered raster graphics, some software may inappropriately bake in sub-pixel rendering. This gets even worse, when taking into account the possibility of having colored subexpressions in equations. A possibility may be to use a basic heuristic: If the image consists predominantly of two grayscale values / a dark gray scale value on transparent background (e.g. black and white, dark gray and white, or black on transparent background) it is probably appropriate to adjust or invert the color in dark mode. The user would however need the ability to explicitly flag images for inversion / not inversion, when the heuristic decides wrong.
  6. Hello! I love the ability to clip a simplified version of articles. Sadly, this mode doesn't give an option to expand what is being clipped. As a consequence, the feature is virtually useless for Q&A sites like the stackexchange network or answers.microsoft.com, where it clips only the question, but not the answer. It would be nice, if this feature would allow to either select what is to be clipped like normal article clipping, or respect the selection.
  7. That was just me finding only "Formats > Blocks > Pre". I didn't expect it under "Text box", since I usually associate the term with free-floating elements in Office software.
  8. While certainly powerful, the "webclient only" restriction is a big "if". The Chrome extensions lacks feedback about available hotkeys compared to the official client (). Even the code-block feature itself isn't really solved. All the Chrome extension is, is provide direct access to the "<pre>" tag in all contexts, but it doesn't assign it backgrounds or borders; At this point one might as well just apply a monospaced font. An officially supported solution in the official deskotp client would be very much appreciated.
  9. Could you try pasting some source code from a non-rich-text environment to a code block? If nothing else is available, pasting some source code to notepad and then copying it from there should strip the information. (In real world usage it would be something like Emacs or TeXStudio). For me, when pasting such code into a code block, Evernote would display it as a not-monospaced font, and I would have to apply a monospaced hand over and over again manually. Your explanation seems to be basically the reason, why applying the Monaco font worked, despite it not actually being available. As for why it wasn't applied when pasting plain-text, that seems to be a more fundamental bug that goes beyond the choice of the default font.
  10. By installing it system-wide. (Worked on Windows). Full agreement actually. It is just, that (at least on Windows), Evernote uses Monaco as the default font for code blocks and doesn't make it user-configurable. As a consequence, code blocks exhibit broken behaviour out of the box. And even if they make the font user-configurable, the default one should actually be available on the system without further user interaction.
  11. I wanted to express my support for this feature request. Currently code blocks are just limited. In my case, I usually run into the issue when trying to use paragraph intentation to create "description list" style structuring of a note. In Summary the code bloch feature fails to provide useful behavior in these cases (pasted from evernote).
  12. I strongly support the suggestion of switching fonts or installing Monaco when Evernote is installed. The lack of the Monaco font prevents pasting code into code blocks, without subsequently reapplying a monospaced font, which sort of defeats the point of the feature; I rarely write the code in Evernote itself. Workaround: Monaco can be downloaded for free from various sources. *edit* By installing it as a system-wide font, the broken behaviour of Evernote code blocks can be fixed, but it really should work out of the box. Tested only on Windows 10.
  13. TL;DR Recently the webclipper fails to find notes, even when the search phrase appears verbatim in their title. DETAILS The webclipper "related notes" feature is to me one of the biggest advantages of Evernote. Recently however, it usually fails to find anything. As mentioned in [this older thread], it will not show up at all if it cannot find anything, which caused me to think the feature were broken entirely. The suggested solution of using a different search-URL didn't help. REPRODUCIBLE EXAMPLE (POSSIBLY) For example, I have a note called “Rust vs Go / Golang”. If I search Google for “Rust vs Go”, no results are shown. If I search Google for “Rust vs Go / Golang”, the note shows up as expected. Plus some additional results, where “rust” and “go” but not “golang” or “vs” appear in the body of the note, but have no relation to the programming languages – which is funny, since the search for “Rust vs Go” would have matched these notes better than the search for “Rust vs Go / Golang”. For reference, I first had titled the note “Rust vs Go/GoLang” (no spaces around slash) and then renamed it “Rust vs Go / GoLang”, thinking that maybe the search-algorithm fails to treat “Go/GoLang” as two words. This change had no impact at all on the behaviour.
  14. Same situation here: Trying to use evernote to take notes about a physics conference. Pinch to zoom would also allow automatic brightness adjustment and border-recognition to work better (seen when using camera scannner apps, after being fed up with the additional steps needed in evernote). Rule of thumb for me with notes: If I can't do it live during the talk, I won't do it at all (see e.g. the idea of taking photos in bulk and adding them later), let alone that the slide-photos normally require some annotation, which needs to be done inside evernote, while I still remember the context. Currently, taking a photo and then cropping it as "document" sort of works, but it takes significantly too long for live note-taking.
  15. On iOS, apparently there is no font-fallback for unicode characters. In my specific case I use unicode characters to get some super/subscripting in Note titles, e.g. "SiₙGeₙ" (see attached screenshot).
×
×
  • Create New...