vimprobable-users

[Vimprobable-users] two ideas to improve the quickmarks

[Marcos C. <vim...@pr...>]

== First idea

It would be nice to use any (ASCII?) letter as quickmark (even better,
optionally, case sensitive).  Digits are more difficult to remember.

I think the changes in the code would not be big.

== Second idea

Quickmarks of any length would let hierarchical and easier to remember
shortcuts, the same way keyboard-driven environments (e.g.  GNU Screen
and Ratpoison) can be configured.  Example:

    Qmark  -- Meaning
    -----------------
    ss -- [S]earch-engine [S]tartPage
    sd -- [S]earch-engine [D]uckDuckGo
    sg -- [S]earch-engine [G]oogle
    nx -- [N]ewspaper [X]
    ny -- [N]ewspaper [Y]
    nzi -- [N]ewspaper [Z] [I]nternational section
    nzn -- [N]ewspaper [Z] [N]ational section
    nzc -- [N]ewspaper [Z] [C]ultural section

That would mean a whole rewrite of the quickmarks' code, but I think
there's an easier alternative: The current searchengines feature is
already very similar and it could be easily modifed into an alternative
generic shortcuts system: Simply the search string (%s) should be
optional: no %s defined in the shortcut, no parameter expected.
Currently %s is mandatory and a searchengine shortcut without its string
parameter is not recognized, but passed as search string to the default
search engine.

This change would be backward compatible, no current config would be
affected  (though an alternative name for "searchengine" would be
desirable, for example "shortcut").

The Elinks text browser uses two kinds of configurable URI rewriting:

    Dumb prefixes - simple URI abbreviations which can be written to the
    Goto URL dialog instead of actual URIs - i.e. if you write 'elinks'
    there, you are directed to http://elinks.cz/.                                        
    Smart prefixes - URI templates triggered by writing given
    abbreviation to the Goto URL dialog followed by a    list of
    arguments from which the actual URI is composed -  i.e. 'gg:search
    keywords' or 'gn search keywords for news'.

Smart prefixes accept several parameters, what is very versatile:

    Replacement URI for this smartprefix:                    
    %c in the string means the current URL                   
    %s in the string means the whole argument to smartprefix 
    %0,%1,...,%9 means argument 0, 1, ..., 9                 
    %% in the string means '%'                               

My suggestion for Vimprobable is a similar system, but a bit simpler for
the user: one single list of configured shortcuts for URI rewriting,
with optional parameter(s) (if several parameters are implemented, a
good choice for the parameter separator is the first char found in the
command line after the shortcut).

Marcos

-- 
http://programandala.net

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Hannes S. <ha...@yl...>]

Hi Marcos!

Marcos Cruz <vim...@pr...> wrote:
> == First idea
> 
> It would be nice to use any (ASCII?) letter as quickmark (even better,
> optionally, case sensitive).  Digits are more difficult to remember.
> 
> I think the changes in the code would not be big.

I fear you're underestimating the necessary changes for this; the
current quickmark is not that flexible. Check out keymap.h - all
shortcuts are hardcoded there.

> == Second idea
> 
> [...]
>
> That would mean a whole rewrite of the quickmarks' code, but I think
> there's an easier alternative: The current searchengines feature is
> already very similar and it could be easily modifed into an
> alternative generic shortcuts system: Simply the search string (%s)
> should be optional: no %s defined in the shortcut, no parameter
> expected. Currently %s is mandatory and a searchengine shortcut
> without its string parameter is not recognized, but passed as search
> string to the default search engine.

I like this very much! In fact, I'd say this would be fairly easy to do
if we just go for making %s optional. The whole thing about other
parameters, I'm not sure what we'd need them for. Could you sketch some
basic scenarios when they would prove useful?

Hannes

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Marcos C. <vim...@pr...>]

En/Je/On 2013-04-25 11:27, Hannes Schüller escribió / skribis / wrote :

> > It would be nice to use any (ASCII?) letter as quickmark 
> 
> I fear you're underestimating the necessary changes for this; the
> current quickmark is not that flexible. Check out keymap.h

I had searched main.c for the quickmarks functions, just to get a little
idea how the thing works, but of course you're right, I see it's not so
simple.

Anyway, keep the idea for the future; alphanumeric quickmarks would be
more ergonomic.

> The whole thing about other parameters, I'm not sure what we'd need
> them for. Could you sketch some basic scenarios when they would prove
> useful?

I've never needed more than one parameter with Elinks' shortcuts, but I
think the feature is useful in certain cases. Examples:

	shortcut arlbn http://areallylongblogname.com/%0/%1/

Then you can access any year and month of the blog archives:

	:open arlbn 2013 07
	:open arlbn 2009 01

Or say a multilingual dictionary, where the searched language is a
subdomain or a directory. Then you can use two parameters as well: the
language and the term:

	shortcut adic http://%0.anydictionary.com/?term=%1
	
	:open adic en englisword
	:open adic eo esperantoword

Or say a library with several sections:

	shortcut lib http://mylibrary.com/?section=%0&subsection?=%1&lang=%2
	:open lib history europe french

But probably in most cases one single parameter can be used instead
without drawback:

	shortcut arlbn http://areallylongblogname.com/%0/
	:open arlbn 2013/07
	:open arlbn 2009/01

	shortcut adicen http://en.anydictionary.com/?term=%0
	shortcut adiceo http://eo.anydictionary.com/?term=%0
	:open adicen englisword
	:open adiceo esperantoword

(I have not used %s as first parameter in the examples because %0..%9
seems a better option.)

I think one optional parameter is enough in most cases; and it's easier
to implement.  More parameters could be implemented later, if they are
found useful enough.

Marcos

-- 
http://programandala.net

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Daniel C. <dan...@gm...>]

Hi Marco!

The idea, to make the search-engine feature miore flexible to a generic
shortcut syste is great!

But we must keep the in mind to have the ability to use all parametes for the
shortcuts together, to not break the search-engine feature. I suggest to use
%0 as placeholder for all parameters, and %1-%9 as placeholder for single
parameters. So the searchengines could be revamped to the shortcut feature and
behave the save as before, but we have also the ability to us single
parameters in the way you proposed.

My second concern goes to the placeholder format. Does Elinks use the '%'-Char
to mark placeholders? I think it isn't easy to distinguisch %x from url
entities like (%20 for a space). Maybe we should change the placeholder to
something else $0 or so.

Daniel

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Marcos C. <vim...@pr...>]

En/Je/On 2013-04-29 17:20, Daniel Carl escribió / skribis / wrote :

> But we must keep the in mind to have the ability to use all parametes
> for the shortcuts together, to not break the search-engine feature.  I
> suggest to use %0 as placeholder for all parameters, and %1-%9 as
> placeholder for single parameters. 

You're right. But if several parameters were finally implemented, and
the space were used as parameter separator, then one single placeholder
(the one for the first parameter, %s, %0 or %1 or whatever) in the
config command would be enough, meaning just "everything till the end of
line".  Of course a specific placeholder for every parameter would be
more versatile. Using %0 for the whole string lets the system to be
expanded in the future to accept individual params with %1-%9.

> My second concern goes to the placeholder format. Does Elinks use the '%'-Char
> to mark placeholders?

Yes it does:

	%c in the string means the current URL
	%s in the string means the whole argument to smartprefix
	%0,%1,...,%9 means argument 0, 1, ..., 9
	%% in the string means '%'

> I think it isn't easy to distinguisch %x from url entities like (%20
> for a space). Maybe we should change the placeholder to something else
> $0 or so.

Good point.  I suppose any hex encoded char (format %[0-9A-F][0-9A-F])
is skipped by Elinks, but I didn't try. I think ambiguous cases must be
unusual... a parameter before a hex digit... Something like this, where
"%1" represents the decade's digit, "%2" the month and "%3" the day:

	http://domain.com/archive/20%10/%2/%3

"%1" before the "0" char is confusing, but AFAIK "%10" (16 decimal) is
not a valid char in a URL.
	
This is worst, "%2"+0 can be interpreted as "%20" (32 decimal, space):

	http://domain.com/archive/user_%1/20%20/%3/%4

Some investigation is required.

Marcos

-- 
http://programandala.net

[Vimprobable-users] Surfraw (Re: two ideas to improve the quickmarks)

[Marcos C. <vim...@pr...>]

En/Je/On 2013-04-24 23:06, Marcos Cruz escribió / skribis / wrote :

> The current searchengines feature (...) could be easily modifed into
> an alternative generic shortcuts system: Simply the search string (%s)
> should be optional: 

By the way, I forgot to mention that there's a versatile tool that
provides a generic URL shortcut system with any parameters, and can be
used with any browser. I use it at times. Maybe many of you already know
it:

	https://en.wikipedia.org/wiki/Surfraw

Marcos

-- 
http://programandala.net

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Hannes S. <ha...@yl...>]

Marcos Cruz <vim...@pr...> wrote:
> I think one optional parameter is enough in most cases; and it's
> easier to implement. 

The attached patch should do this. It makes the %s in search engine
definitions in the rc file optional. So you can now use zero or one
parameters. Intended behaviour:

- If parameter given, but none expected, ignore them and open the
  shortcut.
- If no parameter given, but one was expected, open the shortcut with
  blank string as parameter.

Testing highly appreciated!

Hannes

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Hannes S. <ha...@yl...>]

Patch merged.

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Marcos C. <vim...@pr...>]

En/Je/On 2013-05-17 15:07, Hannes Schüller escribió / skribis / wrote :

> The attached patch should do this. It makes the %s in search engine
> definitions in the rc file optional. So you can now use zero or one
> parameters.

Patched to 1.3.0.

> - If parameter given, but none expected, ignore them and open the
>   shortcut.
> - If no parameter given, but one was expected, open the shortcut with
>   blank string as parameter.

It works as you say. Thank you. It's very useful to create general
mnemonic shortcuts.

Why didn't you include it in 1.3.0? Still not tested enough? Do you
consider changing "searchengine" to "shortcut" or similar, when finally
included in a future version?

Marcos

-- 
http://programandala.net

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Hannes S. <ha...@yl...>]

Marcos Cruz <vim...@pr...> wrote:
> En/Je/On 2013-05-17 15:07, Hannes Schüller escribió / skribis /
> wrote :
> > - If parameter given, but none expected, ignore them and open the
> >   shortcut.
> > - If no parameter given, but one was expected, open the shortcut
> > with blank string as parameter.
> 
> It works as you say. Thank you. It's very useful to create general
> mnemonic shortcuts.
> 
> Why didn't you include it in 1.3.0? Still not tested enough?

The new version was long overdue, I didn't want to delay it any further.

> Do you
> consider changing "searchengine" to "shortcut" or similar, when
> finally included in a future version?

I would consider that, yes (keeping "searchengine" as a deprecated
legacy alias).

Hannes

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Hannes S. <ha...@yl...>]

On Sat, 18 May 2013 20:46:08 +0200, Hannes Schüller <ha...@yl...>
wrote:
> > Why didn't you include it in 1.3.0? Still not tested enough?  
> 
> The new version was long overdue, I didn't want to delay it any
> further.

I'm curious; has anyone tested this patch in the time which has passed?

Hannes

Re: [Vimprobable-users] two ideas to improve the quickmarks

[Marcos C. <vim...@pr...>]

En/Je/On 2013-09-09 15:10, Hannes Schüller escribió / skribis / wrote :
> I'm curious; has anyone tested this patch in the time which has passed?

Do you mean the shortcuts with optional parameter? I use it everyday
since you posted the patch. Examples from my config:

::::::::::::::::::::::::::::::::::::::::::::::::
: Shortcuts

:...............................................
: Secure web search engines:

: DuckDuckGo (HTML version)
searchengine dd https://duckduckgo.com/html/?q=%s&t=vimprobable
: DuckDuckGo (Javascript version)
searchengine ddj https://duckduckgo.com/?q=%s&t=vimprobable

: Other
searchengine sp https://startpage.com/do/search?cat=web&cmd=process_search&language=espanol&engine0=v1all&query=%s&x=0&y=0
searchengine dp http://www.dogpile.com/info.dogpl.t6.2/search/web?fcoid=417&fcop=topnav&fpid=27&q=%s&ql=
searchengine ix https://ixquick.com/do/search?cat=web&cmd=process_search&language=espanol&engine0=v1all&query=%s&x=0&y=0
searchengine ixm http://ixquick.com/do/metasearch.pl?query=%s

: Web archive:
searchengine wa http://web.archive.org/web/*/%s

:...............................................
: Dictionaries

: Wikipedia in Spanish, Esperanto and English:
searchengine wpes http://es.wikipedia.org/wiki/%s
searchengine wpeo http://eo.wikipedia.org/wiki/%s
searchengine wpen http://en.wikipedia.org/wiki/%s

: The Free Dictionary:
searchengine tfd http://thefreedictionary.com/%s

: Spanish Language Royal Academy:
searchengine rae http://lema.rae.es/drae/?val=%s
searchengine drae http://lema.rae.es/drae/?val=%s
searchengine dpd http://lema.rae.es/dpd/?key=%s

: Word Reference, English to Spanish:
searchengine wrenes http://www.wordreference.com/es/translation.asp?tranword=%s
: Word Reference, Spanish to English:
searchengine wresen http://www.wordreference.com/es/en/translation.asp?spen=%s

-- 
http://programandala.net