vimprobable-users Mailing List for Vimprobable (Page 16)
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...> - 2012-10-15 18:52:21
|
"Matthew Carter" <je...@gm...> wrote: > Right now script updates are locked down by IP address, so at this > point no one can update the three scripts I put on unless they spoof > my ip. I'm sure you are aware that the source address in IP is just a text field, so that is not really an authentication. > I realize this may lock some out of their own scripts if ip changes, Also, most people use dynamic IP addresses anyway. Anyway, I don't think any of this is really a problem right now, because I doubt that the Vimprobable user base, which would probably notice quickly enough, is really a worthwhile attack target. I just want to make sure that everybody is aware of the potential risks. Looking forward to see how this develops! Hannes |
|
From: Jason R. <jas...@gm...> - 2012-10-15 02:00:04
|
Re-reading the man page after 1.2.0 was released, I cam across a couple of small typos/fixes… Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Matthew C. <je...@gm...> - 2012-10-14 11:54:28
|
Hi Hannes, Right now script updates are locked down by IP address, so at this point no one can update the three scripts I put on unless they spoof my ip. I realize this may lock some out of their own scripts if ip changes, I plan to add an auth system to this and let user store a usrname/key to pass to server to validate their script edit access. I'll probably include a rating system and vote to remove system also. Thanks, Matt Sent from my Palm Pre on AT&T On Oct 14, 2012 3:59, Hannes Schüller <ha...@yl...> wrote: Hello Matthew, this sounds great and I think it would be very useful if you could document all of this in the wiki as well so that people not on the mailing list can discover about it as well. Personally, I'm a bit worried about this, though: > If you want to add a script to the server, just use: > > ./ahungry_scripter.sh push ./yourscript.js > > and it'll be merged into the tar.gz within the next minute. So if I push some malicious script, it will be merged into the 'repo' automatically. OK, you could argue that people should check the code before using the script, fair enough. How is versioning handled, though. I.e. what if I (being an evil attacker) push a file with the same name you're using for your popular script? Will it then be overwritten and distributed to all the happy users of your script? Hannes ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Vimprobable-users mailing list Vim...@li... https://lists.sourceforge.net/lists/listinfo/vimprobable-users |
|
From: Hannes S. <ha...@yl...> - 2012-10-14 07:59:25
|
Hello Matthew, this sounds great and I think it would be very useful if you could document all of this in the wiki as well so that people not on the mailing list can discover about it as well. Personally, I'm a bit worried about this, though: > If you want to add a script to the server, just use: > > ./ahungry_scripter.sh push ./yourscript.js > > and it'll be merged into the tar.gz within the next minute. So if I push some malicious script, it will be merged into the 'repo' automatically. OK, you could argue that people should check the code before using the script, fair enough. How is versioning handled, though. I.e. what if I (being an evil attacker) push a file with the same name you're using for your popular script? Will it then be overwritten and distributed to all the happy users of your script? Hannes |
|
From: Matthew C. <je...@gm...> - 2012-10-14 03:27:11
|
Hi all, I have made an interactive interface (similar to CPAN or any other CLI installation utility) to allow users to share and use each other's user scripts. Code is all done via bash, it requires wget/grep/curl to be installed. I'd say it is a beta version still, you can download the latest version at: http://ahungry.com/vp2_scripter/ahungry_scripter.sh (or grab this email's attachment) If you run it with -h, help, or about commands you can see how to use it. It should probably be placed in and run from ~/.config/vimprobable, unless your vimprobable config directory is elsewhere (really it just needs to be in the same directory as your scripts.js file is expected to be in). The script makes 3 directories: scripts.{available,enabled,constant} The scripts.available consists of all user submitted userscripts, while any you want to use but not share should be stored in scripts.constant. If you want to add a script to the server, just use: ./ahungry_scripter.sh push ./yourscript.js and it'll be merged into the tar.gz within the next minute. The main purpose of the script (other than pushing and pulling files) is to merge multiple javascript files into the single scripts.js file that vimprobable2 reads. If you run in wizard mode you can see comments for files as you choose to include or leave out of your own scripts.js file (if you submit your own file use @ahungry to have the script print your comment during the wizard). To start with, I have included the following userscripts: flashblock user script auto scroller (written by me, moves page based on mouse position) password auto filler (I sent this to the mailing list awhile ago as a patch to hinting.js, now it gets its own spot - requiers some user config so copy it to scripts.constant and add your own passwords, do NOT push your password containing file to my server or add any super sensitive passwords here as they are plaintext) Please let me know if you like this little utility. If desired I can send out the server side code (its not much) and this can be run from the main vimprobable servers instead of my own. Thanks, -Matt On Sat, Oct 13, 2012 at 11:17:00AM +0200, Hannes Schüller wrote: > Patch merged, the example script should probably be added to the wiki > (with the appropriate credit). > > Hannes > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users -- Matthew Carter je...@gm... |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 17:57:29
|
Marcos Cruz <vim...@pr...> wrote: > Is there any way to unmap? Currently, the only way to unmap is to remove the offending line from keymap.h and recompile. > Is an "unmap" command planned? You're the first one to bring this up, so no, there are no plans. It sounds useful, though, so I would assume it would be a good candidate to enter into the bug tracker as a feature request. Hannes |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 17:54:41
|
Marcos Cruz <vim...@pr...> wrote: > KEYBOARD BINDINGS > The default keyboard bindings are explained in > this section. These keybindings can be changed - > either at runtime by altering vimprobablerc or > editing keymap.h in the source directory (in > which case you will need to recompile to see > changes take effect). > > I think "runtime" makes people think that any change in vimprobablerc > takes effect at the very moment. I've found out the changes take > effect on new windows, so I suggest a clearer explanation Your observation is correct, vimprobablerc is only read once (when the browser instance is initiated). It should be made clearer in the man page, I will remember this suggestion for the next release. Hannes |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 17:51:55
|
Marcos Cruz <vim...@pr...> wrote: > The vimprobablerc man page lists the commands 'navigationback' and > 'navigationforward', but the vimprobable man page lists them as 'back' > and 'forward'. > > It seems both versions work. Is there any difference between them? > Are 'navigationback' 'navigationforward' deprecated? There is no difference between them, none is deprecated, all are safe to use. These symbols are defined in config.h (struct "commands"), so you can look their exact meaning up at any time. Hannes |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 17:48:48
|
Hi Marcos! Marcos Cruz <vim...@pr...> wrote: > I miss an option to generate an open command with the current URL > (what the ";O" binding does with links). Elinks, my favourite console > browser, provides such command (goto-url-current) and I find it very > useful. > > I've read the man pages and I think it's impossible to do this with > Vimprobable yet, isn't it? It is possible, just use O or T (if you want to open a new window based on the current one's URL). If that's not on the man page, it is an oversight. > An option to generate an open command with the URL from clipboard > would be interesting too. That indeed does not exist as a direct keybinding, but it is possible using the regular commands: Type 'o', then Ctrl-v (GTK standard) to paste from the clipboard. Hannes |
|
From: Marcos C. <vim...@pr...> - 2012-10-13 17:18:54
|
Hi all, Sometimes it's useful not only to create alternative keyboard bindings, but also to remove the old ones. Is there any way to unmap? I tried simply "map d" but it's not accepted. Is an "unmap" command planned? Thank you. Marcos -- http://programandala.net |
|
From: Marcos C. <vim...@pr...> - 2012-10-13 17:17:46
|
Hi all,
The vimprobable manpage reads:
KEYBOARD BINDINGS
The default keyboard bindings are explained in
this section. These keybindings can be changed -
either at runtime by altering vimprobablerc or
editing keymap.h in the source directory (in
which case you will need to recompile to see
changes take effect).
I think "runtime" makes people think that any change in vimprobablerc
takes effect at the very moment. I've found out the changes take effect
on new windows, so I suggest a clearer explanation
(please correct my English):
KEYBOARD BINDINGS
The default keyboard bindings are explained in
this section. These keybindings can be changed -
either by the map command
(what will take effect at the very moment),
by altering vimprobablerc
(what will take effect on any new open window) or
by editing keymap.h in the source directory
(in
which case you will need to recompile to see
changes take effect).
Regards,
Marcos
--
http://programandala.net
|
|
From: Marcos C. <vim...@pr...> - 2012-10-13 17:17:42
|
Hi all, (I'm using Vimprobable2 1.2.0 on Debian armel). The vimprobablerc man page lists the commands 'navigationback' and 'navigationforward', but the vimprobable man page lists them as 'back' and 'forward'. It seems both versions work. Is there any difference between them? Are 'navigationback' 'navigationforward' deprecated? Thank you. Marcos -- http://programandala.net |
|
From: Marcos C. <vim...@pr...> - 2012-10-13 17:17:33
|
Hi all, I'm trying Vimprobable2 1.2.0 on Debian armel. My system is keyboard-only (Ratpoison + GNU screen + keynav) and Vim is my main working tool, so I find Vimprobable great. Congratulations to the developers! I miss an option to generate an open command with the current URL (what the ";O" binding does with links). Elinks, my favourite console browser, provides such command (goto-url-current) and I find it very useful. I've read the man pages and I think it's impossible to do this with Vimprobable yet, isn't it? An option to generate an open command with the URL from clipboard would be interesting too. Thank you. Marcos -- http://programandala.net |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 10:03:30
|
Hi, both versions are now available on the website and the code repository. As a reminder why we seem to be 'out of sync': Since version 1.0, new features are not ported back to the Vimprobable1 branch anymore. Hence, it received the bugfixes only. New features (Vimprobable2): - Decreased COMMANDSIZE resulting in a smaller binary (Daniel Carl) - Added inspect command to open inspector (Daniel Carl) - Added function to echo messages of different types (Daniel Carl) - Added feature to run userland javascripts on every page load (Daniel Carl) - Added support for editing text areas using an external editor (ticket #9; Markus Demleitner) Note of caution: If you have used a previous incarnation of this patch (as posted on the mailing list), you will now need to add a colon to your definition of vimprobableedit! So, for example, in your vimprobablerc, the following is now correct: handler vimprobableedit: foo -bar %s Bug fixes (both versions): - Re-enable display of error messages by removing focus from input box (Daniel Carl) - Fixed wrong keybinding for cancel load in manpage (Daniel Carl) - Avoid memory corruption when opening a new window by right-click (ticket #10; Hannes Schueller) - Correcting DuckDuckGo search URLs (Hannes Schueller) Thanks to Daniel & Markus for making this release possible! Hannes |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 09:21:15
|
Merged (but set to 43 now, of course) |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 09:17:03
|
Patch merged, the example script should probably be added to the wiki (with the appropriate credit). Hannes |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 09:14:35
|
Merged |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 09:13:07
|
Merged |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 09:06:45
|
Merged |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 08:58:45
|
Latest incarnation merged |
|
From: Hannes S. <ha...@yl...> - 2012-10-13 08:57:05
|
Merged |
|
From: Matthew C. <je...@gm...> - 2012-10-08 13:50:30
|
Hi all, I would prefer: xterm -e vim Over: vim -gf For the default. Thanks, -Matt On Mon, Oct 08, 2012 at 11:18:17AM +0200, Hannes Schüller wrote: > Hi! > > Markus Demleitner <msd...@ar...> wrote: > > On Sun, Oct 07, 2012 at 08:04:05PM +0200, Hannes Schüller wrote: > > > Markus Demleitner <msd...@ar...> wrote: > > > > (talking about > > > > which: If I'd like to get this stuff into the upstream git, what > > > > would I do?) > > > > > > As announced on IRC last week, I'm planning to merge the mature > > > patches (like yours) in a week or so and make a new release. > > > > Ah -- are the requests in PATCHES still up-to-date, i.e., do you/does > > anyone want individual patches for the commits on the list? For the > > external editor, that's five patches (the first one is a huge mess of > > Hannes' initial changes and some additional hacking on it by yours > > truly, but the others are, I think, fairly reasonable) -- or should I > > push the stuff somewhere? Would you, Hannes, rather pull from > > somewhere? > > I would certainly appreciate if you could wrap the final patches up in > a canonical way again and send them to the list. The main reason being > that the first patch in this thread (the one "based on HEAD") seems to > be reversed. That would save us some back and forth history. > > Also, there seems to be a bit of a mixture between spaces and tabs > indentation in the patches. > > > Also, I've used the "goto error_exit" style in _resume_from_editor > > since I had to heavily edit the code anyway. Since I've not seen > > that anywhere else in vimprobable, I thought I'd ask whether anyone > > has large issues with this. I happen to believe this is usually > > preferable and more maintainable, but I'll change it to "local" > > resource management if someone doesn't agree. > > OK with me - anyone else? > > > Then, there should be some documentation on this, viz, > > > > * Key bindings: ^t opens an external editor > > * use "handler vimprobableedit <your editor> %s" to configure which > > external editor you'd like to use > > * the editor must open an X11 window and not fork from the parent; > > vim -gf does that, as does xterm -e vi > > > > I'm not quite sure where to put the last two points; > > The basic description should go in vimprobable2.1, I'd say, just like > the external URI handlers description. The handler setting (:set and rc > file) should go in vimprobablerc.5. > > > Finally, should there be a default on the vimprobableedit handler > > (vim -gf comes to mind)? If so, what would be a good place to set > > it? > > I would think launching regular vim in a terminal editor would suit > most users better, but please set me right, folks! > > Hannes > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users -- Matthew Carter je...@gm... |
|
From: Hannes S. <ha...@yl...> - 2012-10-08 09:18:58
|
Hi! Markus Demleitner <msd...@ar...> wrote: > On Sun, Oct 07, 2012 at 08:04:05PM +0200, Hannes Schüller wrote: > > Markus Demleitner <msd...@ar...> wrote: > > > (talking about > > > which: If I'd like to get this stuff into the upstream git, what > > > would I do?) > > > > As announced on IRC last week, I'm planning to merge the mature > > patches (like yours) in a week or so and make a new release. > > Ah -- are the requests in PATCHES still up-to-date, i.e., do you/does > anyone want individual patches for the commits on the list? For the > external editor, that's five patches (the first one is a huge mess of > Hannes' initial changes and some additional hacking on it by yours > truly, but the others are, I think, fairly reasonable) -- or should I > push the stuff somewhere? Would you, Hannes, rather pull from > somewhere? I would certainly appreciate if you could wrap the final patches up in a canonical way again and send them to the list. The main reason being that the first patch in this thread (the one "based on HEAD") seems to be reversed. That would save us some back and forth history. Also, there seems to be a bit of a mixture between spaces and tabs indentation in the patches. > Also, I've used the "goto error_exit" style in _resume_from_editor > since I had to heavily edit the code anyway. Since I've not seen > that anywhere else in vimprobable, I thought I'd ask whether anyone > has large issues with this. I happen to believe this is usually > preferable and more maintainable, but I'll change it to "local" > resource management if someone doesn't agree. OK with me - anyone else? > Then, there should be some documentation on this, viz, > > * Key bindings: ^t opens an external editor > * use "handler vimprobableedit <your editor> %s" to configure which > external editor you'd like to use > * the editor must open an X11 window and not fork from the parent; > vim -gf does that, as does xterm -e vi > > I'm not quite sure where to put the last two points; The basic description should go in vimprobable2.1, I'd say, just like the external URI handlers description. The handler setting (:set and rc file) should go in vimprobablerc.5. > Finally, should there be a default on the vimprobableedit handler > (vim -gf comes to mind)? If so, what would be a good place to set > it? I would think launching regular vim in a terminal editor would suit most users better, but please set me right, folks! Hannes |
|
From: Markus D. <msd...@ar...> - 2012-10-08 08:57:00
|
Hi,
On Sun, Oct 07, 2012 at 08:04:05PM +0200, Hannes Schüller wrote:
> Markus Demleitner <msd...@ar...> wrote:
> > (talking about
> > which: If I'd like to get this stuff into the upstream git, what
> > would I do?)
>
> As announced on IRC last week, I'm planning to merge the mature patches
> (like yours) in a week or so and make a new release.
Ah -- are the requests in PATCHES still up-to-date, i.e., do you/does
anyone want individual patches for the commits on the list? For the
external editor, that's five patches (the first one is a huge mess of
Hannes' initial changes and some additional hacking on it by yours
truly, but the others are, I think, fairly reasonable) -- or should I
push the stuff somewhere? Would you, Hannes, rather pull from
somewhere?
Also, I've used the "goto error_exit" style in _resume_from_editor
since I had to heavily edit the code anyway. Since I've not seen
that anywhere else in vimprobable, I thought I'd ask whether anyone
has large issues with this. I happen to believe this is usually
preferable and more maintainable, but I'll change it to "local"
resource management if someone doesn't agree.
Then, there should be some documentation on this, viz,
* Key bindings: ^t opens an external editor
* use "handler vimprobableedit <your editor> %s" to configure which
external editor you'd like to use
* the editor must open an X11 window and not fork from the parent;
vim -gf does that, as does xterm -e vi
I'm not quite sure where to put the last two points; I'd appreciate
if someone else could add some appropriate prose to... erm...
whereever it belongs (the tempdir setting I've already mentioned in
vimprobablerc.5 -- is everyone fine with the name?).
Finally, should there be a default on the vimprobableedit handler
(vim -gf comes to mind)? If so, what would be a good place to set
it?
Cheers,
Markus
|
|
From: Serge E. H. <se...@ha...> - 2012-10-07 19:05:31
|
Quoting Markus Demleitner (msd...@ar...):
> Hi list,
>
> On Sat, Oct 06, 2012 at 12:07:08PM +0200, Alexander Foremny wrote:
> > Possibly one could introduce an option in vimprobablerc which
> > overrides the environment if it is specified? This seems to be common
> > in other UNIX applications.
> Well, I'm not sure if all that configurability is not a bit of an
> overkill for something like that, but it's not much code, so here's a
> patch that
>
> (a) evaluates TMPDIR, if set, and
> (b) lets you set a variable tempdir in .vimprobablerc (or
> interactively)
Thanks - this suffices for me. I could see it being backward for some
people where inherited env gives them a TMPDIR, but mine is unset by
default.
Indeed since I run vimprobable through tabbed, setting a vimprobable-
specific TMPDIR would be more convoluted than setting it in the
vimprobablerc, so this is perfect.
> The patch applies on top of last week's editor patch (talking about
> which: If I'd like to get this stuff into the upstream git, what
> would I do?)
>
> Cheers,
>
> Markus
> diff --git a/config.h b/config.h
> index 45957c4..860a0fc 100644
> --- a/config.h
> +++ b/config.h
> @@ -20,6 +20,7 @@ static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */
> static const gboolean enableJava = TRUE; /* FALSE disables Java applets */
> static const gboolean enablePagecache = FALSE; /* TRUE turns on the page cache. */
> static gboolean escape_input_on_load = TRUE; /* TRUE will disable automatic focusing of input fields via Javascript*/
> +char temp_dir[MAX_SETTING_SIZE] = "/tmp"; /* location of temporary files, default will be overridden if TEMPDIR is set */
>
> /* appearance */
> char statusbgcolor[MAX_SETTING_SIZE] = "#000000"; /* background color for status bar */
> @@ -209,4 +210,5 @@ static Setting browsersettings[] = {
> { "escapeinput", NULL, "", FALSE, TRUE, FALSE, FALSE },
> { "strictssl", NULL, "", FALSE, TRUE, FALSE, FALSE },
> { "cabundle", ca_bundle, "", FALSE, FALSE, FALSE, FALSE },
> + { "tempdir", temp_dir, "", FALSE, FALSE, FALSE, FALSE },
> };
> diff --git a/main.c b/main.c
> index 36e0edb..f82c2cb 100644
> --- a/main.c
> +++ b/main.c
> @@ -1837,7 +1837,8 @@ open_editor(const Arg *arg) {
> gboolean success;
> GPid child_pid;
> gchar *value = NULL, *message = NULL, *tag = NULL, *edit_url = NULL;
> - gchar *temp_file_name = g_strdup("/tmp/vimprobableeditXXXXXX");
> + gchar *temp_file_name = g_strdup_printf("%s/vimprobableeditXXXXXX",
> + temp_dir);
> int temp_file_handle = -1;
>
> /* check if active element is suitable for text editing */
> @@ -2797,6 +2798,11 @@ main(int argc, char *argv[]) {
> return EXIT_SUCCESS;
> }
>
> + if (getenv("TMPDIR")) {
> + strncpy(temp_dir, getenv("TMPDIR"), MAX_SETTING_SIZE);
> + temp_dir[MAX_SETTING_SIZE-1] = 0;
> + }
> +
> if( getenv("XDG_CONFIG_HOME") )
> config_base = g_strdup_printf("%s", getenv("XDG_CONFIG_HOME"));
> else
> diff --git a/vimprobablerc.5 b/vimprobablerc.5
> index f69dda9..2964b20 100644
> --- a/vimprobablerc.5
> +++ b/vimprobablerc.5
> @@ -159,6 +159,9 @@ Reject or accept unverified certificates (default: true)
> .IP cabundle=/path/to/file
> Where CA certificates are stored (default: /etc/ssl/certs/ca-certificates.crt)
>
> +.IP tempdir=/path/without/slash
> +A path to a directory for temporary files (default: $TMPDIR or /tmp)
> +
> .SH MAPPINGS
>
> Keys can be mapped to the following functions:
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Vimprobable-users mailing list
> Vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimprobable-users
|
2 messages has been excluded from this view by a project administrator.
