vimprobable-users Mailing List for Vimprobable (Page 12)
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
Menu
▾
▴
vimprobable-users — Mailing list for Vimprobable users
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(77) |
Sep
(44) |
Oct
(43) |
Nov
(38) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(40) |
Feb
(18) |
Mar
(12) |
Apr
(25) |
May
(12) |
Jun
(13) |
Jul
(17) |
Aug
(3) |
Sep
(20) |
Oct
(42) |
Nov
(9) |
Dec
(2) |
| 2013 |
Jan
(9) |
Feb
(29) |
Mar
(9) |
Apr
(7) |
May
(38) |
Jun
|
Jul
(7) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(11) |
Dec
(1) |
| 2014 |
Jan
(16) |
Feb
(18) |
Mar
(11) |
Apr
(5) |
May
(13) |
Jun
(5) |
Jul
(5) |
Aug
(7) |
Sep
(30) |
Oct
|
Nov
|
Dec
(26) |
| 2015 |
Jan
(5) |
Feb
(19) |
Mar
(8) |
Apr
(15) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
(10) |
| 2016 |
Jan
|
Feb
(1) |
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Hannes S. <ha...@yl...> - 2013-05-17 12:30:26
|
Here we are, finally a new version! This merges many of the internal improvement patches sent to the mailing list since the last release and fixes a number of bugs which have been reported in the meantime. In particular: - Memory leaks fixes (Daniel Carl) - Global variables moved into structs (Daniel Carl) - Opening Webinspector in a pane of the current window (Daniel Carl) - Improved handling of local file parameters (Morgan Howe) - Image hinting fix (Hannes Schüller) - New zoom commands (Hannes Schüller) - Bugfix for definition of multiple colon command aliases (Hannes Schüller) As usual, thanks to all those who contributed code, gave suggestions and reported bugs! Hannes |
|
From: Hannes S. <ha...@yl...> - 2013-05-17 12:11:08
|
This is now merged as well. |
|
From: Hannes S. <ha...@yl...> - 2013-05-17 12:11:01
|
Adapted to the new client structure and merged |
|
From: Hannes S. <ha...@yl...> - 2013-05-17 12:10:15
|
Merged all patches from this thread |
|
From: Hannes S. <ha...@yl...> - 2013-05-11 10:41:48
|
Marcos Cruz <vim...@pr...> wrote: > Patched, compiled and solved! Thank you, Hannes. Great, I will merge this into the next release, then! (When it comes out...) Hannes |
|
From: Marcos C. <vim...@pr...> - 2013-05-11 10:33:42
|
En/Je/On 2013-05-11 10:09, Hannes Schüller escribió / skribis / wrote : > > I've just realized something new: only the last mapping in the list > > works, whatever it is. The rest of the maps cause the error "Not a > > browser command". > > Ah, I can see the problem now! Mapping multiple colon commands to other > colon commands, the memory storing the new alias is always > overwritten, so only the last one is correctly stored. Could you try the > attached patch and see if it solves your problem? Patched, compiled and solved! Thank you, Hannes. I find this kind of mappings very useful. They can be used to create mnemonic shortcuts to URLs that don't need parameters. Marcos -- http://programandala.net |
|
From: Hannes S. <ha...@yl...> - 2013-05-11 10:28:41
|
Marcos Cruz <vim...@pr...> wrote: > I'm surprised, I've tried colon mappings that begin with "_", "-" and > even ")" or ":", and they work; also non-english letters work: > > That's great. It seems there's no restriction, right? I would advise you to stay away from the NULL character, though :) Hannes |
|
From: Marcos C. <vim...@pr...> - 2013-05-11 10:11:48
|
I'm surprised, I've tried colon mappings that begin with "_", "-" and even ")" or ":", and they work; also non-english letters work: map :_try=:open http://domain.com map :-try=:open http://domain.com map :)try=:open http://domain.com map ::try=:open http://domain.com map :á-try=:open http://domain.com That's great. It seems there's no restriction, right? Marcos -- http://programandala.net |
|
From: Hannes S. <ha...@yl...> - 2013-05-11 08:10:10
|
Marcos Cruz <vim...@pr...> wrote: > En/Je/On 2013-05-10 21:58, Hannes Schüller escribió / skribis / > wrote : > > > Works for me. Can you quote *exactly* the lines you have in your > > config files which don't work? > > map :qpl=:open http://localhost/programandala.net > map :qp=:open http://programandala.net > map :qvl=:open http://localhost/vivirenbicicleta.info > map :qv=:open http://vivirenbicicleta.info > > Those are the first maps of this kind I've tried (I mean, mappings > that start with a semicolon and create a command). > > I've just realized something new: only the last mapping in the list > works, whatever it is. The rest of the maps cause the error "Not a > browser command". Ah, I can see the problem now! Mapping multiple colon commands to other colon commands, the memory storing the new alias is always overwritten, so only the last one is correctly stored. Could you try the attached patch and see if it solves your problem? Hannes |
|
From: Marcos C. <vim...@pr...> - 2013-05-11 00:38:38
|
En/Je/On 2013-05-10 21:58, Hannes Schüller escribió / skribis / wrote : > Works for me. Can you quote *exactly* the lines you have in your > config files which don't work? map :qpl=:open http://localhost/programandala.net map :qp=:open http://programandala.net map :qvl=:open http://localhost/vivirenbicicleta.info map :qv=:open http://vivirenbicicleta.info Those are the first maps of this kind I've tried (I mean, mappings that start with a semicolon and create a command). I've just realized something new: only the last mapping in the list works, whatever it is. The rest of the maps cause the error "Not a browser command". I've tried with 3, 4 and 5 of those maps in different orders, and only the last one defined in the config file is actually defined. Do all mappings work for you, in any order? > Also, does the handling of the config file in general work? I.e. do > you have any other settings in there which have the desired effect? My config file has more than 300 lines, including blank lines and comments. So far everything seemed to work fine. It seems everything works fine except these "semicolon mappings". Marcos -- http://programandala.net |
|
From: Hannes S. <ha...@yl...> - 2013-05-10 19:59:00
|
Hi Marcos! Marcos Cruz <vim...@pr...> wrote: > I tried these: > > map :qpl=:open http://localhost/programandala.net > map :qp=:open http://programandala.net > > They work -- but only if I create them with the command line. They do > nothing when defined in the config file. > > Is it a bug or I'm missing something? Works for me. Can you quote *exactly* the lines you have in your config files which don't work? Also, does the handling of the config file in general work? I.e. do you have any other settings in there which have the desired effect? Hannes |
|
From: Marcos C. <vim...@pr...> - 2013-05-10 19:19:21
|
Hi all, The vimprobablerc man page reads that new commands can be created this way: map :newcommand=:anycommand This feature can be useful to create mnemonic shortcuts. For example, I tried these: map :qpl=:open http://localhost/programandala.net map :qp=:open http://programandala.net They work -- but only if I create them with the command line. They do nothing when defined in the config file. Is it a bug or I'm missing something? Thanks. Marcos -- http://programandala.net |
|
From: Marcos C. <vim...@pr...> - 2013-05-07 12:24:07
|
En/Je/On 2013-05-06 15:41, Hannes Schüller escribió / skribis / wrote :
> Marcos Cruz <vim...@pr...> wrote:
> > > > { "zoomin", zoom,{ZoomIn | ZoomText} },
> > > > { "zoomout",zoom,{ZoomOut | ZoomText} },
> > > > { "zi",zoom,{ZoomIn | ZoomText} },
> > > > { "zo",zoom,{ZoomOut | ZoomText} }
>
> Thinking about this, I'd say it might be a good idea to have one
> command for zooming just text (as above) and one for zooming the
> complete page (i.e. including images) as well for full flexibility.
It's a good idea.
> Would it be clear enough (documented, of course) to have zi/zo zoom
> just the text and zoomin/zoomout to zoom the complete page?
If "zoomin"/"zi" and "zoomout"/"zo" were used that way, it would be
easy to forget which command does what, especially if they're not used
everyday.
I think "zoomin" and "zoomout" are clear enough for zooming the whole
page, since, by default, zooming means zooming everything. "zoominpage"
and "zoomoutpage" would be clearer forms, but unnecessary.
As for text, I suggest "zoomtextin" and "zoomtextout".
I think commands that are easier to remember and easier to understand in
the config file are more preferable than ambiguous abbreviations. The
commands' length is not a problem, thanks to tab completion and keyboard
mapping.
Marcos
--
http://programandala.net
|
|
From: Jason R. <jas...@gm...> - 2013-05-06 18:14:01
|
On 06/05/13 at 03:41pm, Hannes Schüller wrote:
> Marcos Cruz <vim...@pr...> wrote:
> > > > { "zoomin", zoom,{ZoomIn | ZoomText} },
> > > > { "zoomout",zoom,{ZoomOut | ZoomText} },
> > > > { "zi",zoom,{ZoomIn | ZoomText} },
> > > > { "zo",zoom,{ZoomOut | ZoomText} }
>
> Thinking about this, I'd say it might be a good idea to have one
> command for zooming just text (as above) and one for zooming the
> complete page (i.e. including images) as well for full flexibility.
> Would it be clear enough (documented, of course) to have zi/zo zoom
> just the text and zoomin/zoomout to zoom the complete page?
>
It would be clearer, at least to me, to use zi/zo and pgzin/pgzout (or something
like that—where there is more of a delineation) eg..
{ "pgzin", pagezoom,{PageZoomIn | ZoomPage}
{ "pgzout",pagezoom,{PageZoomOut | ZoomPage}
{ "zi",zoom,{ZoomIn | ZoomText} },
{ "zo",zoom,{ZoomOut | ZoomText} }
/J
http://jasonwryan.com/ [GnuPG Key: B1BD4E40]
|
|
From: Hannes S. <ha...@yl...> - 2013-05-06 13:41:17
|
Marcos Cruz <vim...@pr...> wrote:
> > > { "zoomin", zoom,{ZoomIn | ZoomText} },
> > > { "zoomout",zoom,{ZoomOut | ZoomText} },
> > > { "zi",zoom,{ZoomIn | ZoomText} },
> > > { "zo",zoom,{ZoomOut | ZoomText} }
Thinking about this, I'd say it might be a good idea to have one
command for zooming just text (as above) and one for zooming the
complete page (i.e. including images) as well for full flexibility.
Would it be clear enough (documented, of course) to have zi/zo zoom
just the text and zoomin/zoomout to zoom the complete page?
Hannes
|
|
From: matto f. <ma...@ma...> - 2013-05-04 15:57:09
|
Hi, On 2 May 2013 19:01, Hannes Schüller <ha...@yl...> wrote: > Just for the record, in case you didn't notice yet or in case someone > else is looking for help on this subject later. There are two settings > which might also be of help for these problems: > > - fontsize defines the default font size (surprise, surprise) to be > used for websites. I.e. this will be the base size for any website > which uses relative measures (like em or %). It will, unfortunately, > not help on websites which define their fonts in absolute sizes (like > px or pt). I can't think of any good reason to do that, but there are > many sites which do. > > - minimumfontsize lets you specify... you know what. This will also > override definitions made in absolute units - try it out! In the config.h file before compiling I usually change the monospace font into terminus. IMHO this increases the readability a lot. Do this for the urlboxfont, completionfont and statusfont. This is a matter of personal taste, offcourse :) Cheers, Matto |
|
From: Daniel C. <dan...@gm...> - 2013-05-04 12:05:58
|
Daniel Carl <dan...@gm...> wrote: > If only the font is to small, it might be enought to increase the 'fontsize' > or the 'minimumfontsize'. Oh, sorry! That's not new. I answered the mails in wrong order. Daniel |
|
From: Daniel C. <dan...@gm...> - 2013-05-04 12:02:46
|
Marcos Cruz <vim...@pr...> wrote: > Hi all, > > I miss Vimprobable's windows to open with a certain zoom level, because > usually I need a bigger font size. Keymaps let zoom in and out, and it's > possible to choose an alternative CSS too, but I miss a simpler > solution: zoom commands I could add to the config file (and beside, they > would let to config new keymaps for zooming, currently hardcoded). If only the font is to small, it might be enought to increase the 'fontsize' or the 'minimumfontsize'. Daniel |
|
From: Marcos C. <vim...@pr...> - 2013-05-02 18:54:16
|
En/Je/On 2013-05-02 19:01, Hannes Schüller escribió / skribis / wrote :
> > { "zoomin", zoom,{ZoomIn | ZoomText} },
> > { "zoomout",zoom,{ZoomOut | ZoomText} },
> > { "zi",zoom,{ZoomIn | ZoomText} },
> > { "zo",zoom,{ZoomOut | ZoomText} }
>
> I'm a but surprised to find "zi" and "zo" there, as the same
> combinations already exist as keybindings by default. What would be the
> benefit to define them for the command line as well?
Oops, you're right. I added them as shorter versions of the commands...
but there's no need to type them, because of the keybindings.
But would not be the same about "ba" and "fw" and other harcoded short
versions of some commands? I mean, they make it easier to type the
commands, but they have keybindings as well.
> Any opinions on which combination to make default?
I think "zoomin" and "zoomout" are clearer for the config file.
> - fontsize defines the default font size
> - minimumfontsize lets you specify... you know what.
Great, thank you! That is not in the vimprobablerc man page yet, and I
forgot to check the website. I will try them.
> Again, this does not invalidate the usefulness of what you're proposing.
But it's simpler to set the minimum font size than zooming in several
times. Beside, I realised the Vimprobable's start delays a bit (on my
Raspberry Pi) because of the four zoomin commands! The advantage of the
zoom commands is to let the user change its default keybindings.
Marcos
--
http://programandala.net
|
|
From: Hannes S. <ha...@yl...> - 2013-05-02 17:01:48
|
Hi Marcos!
Marcos Cruz <vim...@pr...> wrote:
> I miss Vimprobable's windows to open with a certain zoom level,
> because usually I need a bigger font size. Keymaps let zoom in and
> out, and it's possible to choose an alternative CSS too, but I miss a
> simpler solution: zoom commands I could add to the config file (and
> beside, they would let to config new keymaps for zooming, currently
> hardcoded).
>
> { "zoomin", zoom,{ZoomIn | ZoomText} },
> { "zoomout",zoom,{ZoomOut | ZoomText} },
> { "zi",zoom,{ZoomIn | ZoomText} },
> { "zo",zoom,{ZoomOut | ZoomText} }
I'm a but surprised to find "zi" and "zo" there, as the same
combinations already exist as keybindings by default. What would be the
benefit to define them for the command line as well? Apart
from /having/ any command for this, that is, but that is covered by
"zoomin" and "zoomout" already. I'd say either zoomin/zoomout *or*
zi/zo would be enough, because that would then enable any user to have
additional aliases in the config file.
Any opinions on which combination to make default?
> Do you find these commands useful enough to be included in a future
> version?
I'd say this cannot hurt!
Just for the record, in case you didn't notice yet or in case someone
else is looking for help on this subject later. There are two settings
which might also be of help for these problems:
- fontsize defines the default font size (surprise, surprise) to be
used for websites. I.e. this will be the base size for any website
which uses relative measures (like em or %). It will, unfortunately,
not help on websites which define their fonts in absolute sizes (like
px or pt). I can't think of any good reason to do that, but there are
many sites which do.
- minimumfontsize lets you specify... you know what. This will also
override definitions made in absolute units - try it out!
Again, this does not invalidate the usefulness of what you're proposing.
Hannes
|
|
From: Marcos C. <vim...@pr...> - 2013-05-02 14:13:54
|
Hi all,
I miss Vimprobable's windows to open with a certain zoom level, because
usually I need a bigger font size. Keymaps let zoom in and out, and it's
possible to choose an alternative CSS too, but I miss a simpler
solution: zoom commands I could add to the config file (and beside, they
would let to config new keymaps for zooming, currently hardcoded).
I've been tinkering with the code in order to understand how it works
and to make the desired changes -- and it worked. My C experience is
basic, so please check if I'm missing or breaking something, though the
changes are very simple:
In vimprobable.h, I increased COMMANDSIZE from 43 to 47:
----8<----------------------------------------------------------
#define COMMANDSIZE 47
----8<----------------------------------------------------------
In config.h, I added four new elements to the command mapping:
----8<----------------------------------------------------------
{ "scrolldown",scroll,{ScrollMove|DirectionBottom|UnitLine}},
{ "zoomin", zoom,{ZoomIn | ZoomText} },
{ "zoomout",zoom,{ZoomOut | ZoomText} },
{ "zi",zoom,{ZoomIn | ZoomText} },
{ "zo",zoom,{ZoomOut | ZoomText} }
----8<----------------------------------------------------------
Finally, I simply added as many commands as needed to my vimprobablerc
file:
----8<----------------------------------------------------------
zoomin
zoomin
zoomin
zoomin
----8<----------------------------------------------------------
I didn't investigated yet how to create a command to set the zoom level
to a certain value, say "zoom 120", but maybe I will.
Do you find these commands useful enough to be included in a future
version?
Marcos
--
http://programandala.net
|
|
From: Marcos C. <vim...@pr...> - 2013-05-02 11:53:49
|
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 |
|
From: Marcos C. <vim...@pr...> - 2013-05-02 11:44:22
|
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 |
|
From: Daniel C. <dan...@gm...> - 2013-04-29 15:20:30
|
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 |
|
From: Marcos C. <vim...@pr...> - 2013-04-26 10:08:01
|
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 |
2 messages has been excluded from this view by a project administrator.
