Jump to content

Insert link in EN-10.50 (Ctrl-Alt-K, Cmd-Opt-K)


Recommended Posts

You know, I'm a Legacy-fan - but to be honest: Ctrl-Alt-K is a really nice feature of V10 👍.
 
To summarize what I've learned in some other discussions around this (mostly off-topic in these other threads), I start this new one to concentrate on this.
 
Here is what I like:
  • Within my >9k notes database it opens immediately and shows all top-level notebook stacks and notebooks (no notes - and this is OK). 🙂
  • If I type simple words every single keystroke fires an internal search cycle that narrows down the result list of notes below the input field 😀
  • Without other options, only note headlines are searched - but in a somewhat intelligent mode: similar words (with some spelling difference or german "Umlaut"s like ÄÖÜäöüß are recognized in parallel to exact matches.👌
  • If I'm looking for exact matches (to ignore EN's intelligence), I've to in insert "intitle:" before the word to search for (i.e. "intitle:buch" finds only notes with "buch" in title - an not "buck") 👍
  • If I'm looking for notes that are tagged, I can insert "tag:" just before my tag name I'm looking for (i.e. "tag:=rechnung" finds only notes tagged with tag "=rechnung" (the german word for a bill 😉)
  • All these things can be combined like "bol tag:=rechnung" (which means "list all notes with something that sounds like 'bol' and are tagged with '=rechnung") 👋
 
But there are (as everytime) some things that should be enhanced in future:
 
  • If I use any search options like "intitle:" or "tag:" as tokes before normal words, EN searches text bodies of notes for the normal words.
    • These is awesome and seems like a unintended or not fully implemented feature 🤔
    • EN should offer a search option like "body:" to force full text searches...
       
  • If I type <TAB> to select a specific (found) note as a result of my search, the arrow-buttons (<UP> and <DOWN>) will scroll the whole result list up and down. 👎
    • I expect <UP> and <DOWN> to move the cursor within the list up and down to be able to select a specific note with <ENTER>
    • EN should change the keyboard mapping within the dialog to follow common standards (use <PG-UP> and <PG-DOWN> to scroll and <UP> and <DOWN> to move the cursor)
  • Like 3
  • Thanks 1
Link to comment
15 minutes ago, AlbertR said:

If I use any search options like "intitle:" or "tag:" as tokes before normal words, EN searches text bodies of notes for the normal words.

Thats not my expereince. I have a tag called "English". A normal search for English brings up many many possible notes. tag:English brings up only the 7 tagged with English.

16 minutes ago, AlbertR said:

If I type <TAB> to select a specific (found) note as a result of my search, the arrow-buttons (<UP> and <DOWN>) will scroll the whole result list up and down.

The behaviour of the arrow keys and PgUp and PgDn does seem to be strange. If I < tab> to get into the list, I find that I can move down through the list using <tab> again and <shift><tab> to come up

Link to comment
14 minutes ago, Mike P said:

I have a tag called "English". A normal search for English brings up many many possible notes. tag:English brings up only the 7 tagged with English.

OK, if there is no space between "tag:" and "English", you really specify "only tagged with English". This works as intended.

But if you use any token with "tag:..." or "intitle:..." before the word "English" (i.e. "intitle:* English), EN will search "English" in all note bodies. I assume this will find much more notes in your case 😉

14 minutes ago, Mike P said:

If I < tab> to get into the list, I find that I can move down through the list using <tab> again and <shift><tab> to come up

Yep, strange... A <TAB> should move the input cursors from one input field to the next field. A list of lines is a field, so <TAB> should move the focus to the fields below the list (and <SHIFT><TAB> should lead back to the input field).

Link to comment

I've never found the * character to give me the results I expect and I'm not sure it is part fo the search syntax. If I search for 

tag:*English

I get no results

I also get no results for 

tag:*mar

ie it doesn't find the tag called grammar

As soon as you put in  a space you add a new search  term. So 

tag:English English

will search for those notes containing the tag English which also contain the word English.

As far as I can see, the search seems to be working exactly as the normal search works which is what I would hope and expect.

Link to comment
1 hour ago, Mike P said:

I've never found the * character to give me the results I expect and I'm not sure it is part fo the search syntax. If I search for 

tag:*English

I get no results

I also get no results for 

tag:*mar

ie it doesn't find the tag called grammar

As soon as you put in  a space you add a new search  term. So 

tag:English English

will search for those notes containing the tag English which also contain the word English.

As far as I can see, the search seems to be working exactly as the normal search works which is what I would hope and expect.

the search differs at some points, for instance:

tag:* returns all notes in the normal search and only a few notes in the 'link search' . Also the normal search looks in the whole note, the 'link  search' in the title only.

About your example tag:*mar  :  a wildcard isn't supported in front of the string, only at the end like this  :   tag:gramm*   This works even if the tag has spaces in the name.

 

 

  • Like 1
Link to comment
56 minutes ago, eric99 said:

Also the normal search looks in the whole note, the 'link  search' in the title only.

I agree, as long as you put a single search term in the search field. However combining with a tag search or adding the search term in inverted commas gives results where the search word is in the body of the note.

image.png.f0afbb225fa78960abf2969f735f3bff.png

image.png.b5d9f14da6f314ceabee9089fcd2f73c.png

 

I guess we will find strategies that work for us to find the note we are looking for.

  • Like 1
Link to comment
1 hour ago, eric99 said:

tag:* returns all notes in the normal search and only a few notes in the 'link search'

I think there must be a limit to how many are displayed. Interestingly 

-tag:*

brings up all of the small number of my notes that don't have tags but it doesn't seem to work if I add extra search words.

It would be nice if this "new" search method was either identical to the normal search grammar or at the very least documented properly!

  • Like 1
Link to comment

Just to note that you can use a tag search with intitle if you want to revert to the title only behaviour of a simple text search. So this is my current understanding:

plot                        | will search for notes with plot in the title
"plot"                      | will search for notes with plot in the title or the body of the note
tag:ggplot plot             | will search for notes tagged with ggplot and with plot in the title or the body of the note
tag:ggplot intitle:plot     | will search for notes tagged with ggplot and with plot in the title 

t's possible that in example  2 and 3 it is only searching the main body of the note and not the title, but without creating some artificial notes it is difficult to test, as notes normally contain words from the title in the main text.

  • Thanks 2
Link to comment
21 hours ago, Mike P said:

It would be nice if this "new" search method was either identical to the normal search grammar or at the very least documented properly!

"new" search method is the same as already known with the exception of the default "intitle:" search. This might be a good idea - but not the tricky "inbody:" mode for tokens after a "tag:" or explicit "intitle:" phrases at the beginning of the search term.

Even "-tag:*" is an already known construct to find notes without any tags 😉

23 hours ago, Mike P said:
tag:*mar

doesn't find the tag called grammar

This is and was true all the time and has a technical reason: Search operations that are based on internal index tables normally cannot  support wildcards at the beginning of a token because calculation an index for any word starts with the first character. Even Google didn't support this for a long time - until they found a better solution for this problem (don't know how - too high for me 🤔

Link to comment
On 10/12/2022 at 11:13, AlbertR dijo:
You know, I'm a Legacy-fan - but to be honest: Ctrl-Alt-K is a really nice feature of V10 👍.

You lost me in here, i have the 10.49.4 version of evernote for windows. However, the Ctrlk-Alt-k feature does not function for me....and I really miss /need that keystroke.

 

What can I do to fix it?

Link to comment
50 minutes ago, copdeb said:

You lost me in here, i have the 10.49.4 version of evernote for windows. However, the Ctrlk-Alt-k feature does not function for me....and I really miss /need that keystroke.

 

What can I do to fix it?

update to 10.50 🙂

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...