It is very common to allow the same action with double click and drag as works with click and drag, but it selects whole words. I continually find myself trying to do this with PDF documents only to find I’ve only selected a single word and the drag does nothing.
Why not work like the majority of programs and support double click and drag? It would make using Sumatra much more like the rest of the world and not make the user think about Sumatra differently.
I will say I am very happy with Sumatra. It’s a great program and I’m glad it was developed. It just has a very few nits that I don’t care for.
Unfortunately there are a few conflicting issues here
Double click has since the days of TeX Enhancement equalled triggering reverse/inverse search (and is desirable for that function, albeit by a significant minority of users)
Touch screen selection was never developed beyond some experimental phases.
Multi word text selection has AFAIK always been possible when using the mouse by single click and drag, in the same way as variable image area selection is triggered by using control with single click and drag
I don’t know what to think. Every editor like tool I use and every browser, etc. all respond to a double click and drag by selecting multiple words. This is so much easier than trying to find that 1 pixel wide spot between the letter and a period or whatever else is next to it that I don’t even give it a second thought, I go for the word selection and drag to select phrases.
I guess I’m not geek enough to appreciate concepts that I can’t even really read… from the Github discussion…
Double click PDF in
Acrobat=word only (same drag as SumatraPDF)
Okular=word only (same drag as SumatraPDF)
Thus no issue since SumatraPDF behaves similar to its peer applications
The two fofou links don’t even work.
I guess I think like a user and not a developer.
Ok, I give up. Either use Sumatra as is or don’t. Don’t bother pointing out ways it can be improved.
Unfortunately the second link seems to have been lost.
In any case you can clearly see the comment I was referring to:
It seems clear that the code change made to fix the touch issue resulted in this unfortunate loss of functionality.
Let me make it clear that till date you have not received a single response from the developer, so you can’t come to the conclusion that your request has been rejected.
FWIW I think your request has merit and ought to be fixed if possible, especially given that it’s a useful feature and apparently did work once upon a time. Hopefully the developer @kjk can look into it when he has some free time.
Also, all suggestions for improvement are appreciated, although like the rest of us non-coders you’ll just have to give them and then wait (sometimes for years) till they are implemented, if at all. There’s only a single developer working gratis on his FOSS app in his free time, so… it is what it is.
AFAIK double click with a pdfsync or synctex file present since the early days (after adding DDE) selected the current line number (or co-ordinates) and runs the -inverse-search command.
“Enter the command-line to invoke when you double-click on the PDF document:”
Without synctex it always selected the current word (exactly the same .pdf behaviour as up to at least Acrobat 9)
The time quoted above would have probably been version 2.0 to 2.5.2 and the behaviour was exactly the same in both those versions then as now.
It is format specific
There IS a difference using ChmUI since that respects HTML selection methods so in a .chm using Chm engine double click and drag selects start to finish.
In a CBX double click selects the whole page in DjVu file it will select the whole line or image only and in epubUI nothing happens NO selection !
According to boon’s comment it seems something changed “in the latest prerelease” back in early 2014. Perhaps in zeniko’s prerelease versions it behaved differently? Not sure, and don’t have the time or inclination to track it down to check. In any case it’s up to kjk if he wants to change this or close the issue once and for all.