vimprobable-users — Mailing list for Vimprobable users

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

[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] Improve handling of file parameters

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

Morgan Howe <mt...@gm...> wrote:
> > Then it's ok for me to merge it. Personally, I would give
> > preference to always treat arguments as an URL when in doubt, but I
> > also do see the case of testing for local files first.  
> 
> I still don't see this having been merged. Is there something still
> holding it up or did it just get lost in the mix? :)

Yes, there is something, but it's not related to you. I simply cannot
access the code repository right now due to unforeseen personal
circumstances. Don't worry, though, the patch has been marked in my
queue so that I won't forget.

Hannes

Re: [Vimprobable-users] Improve handling of file parameters

[Morgan H. <mt...@gm...>]

Hey Hannes,

On Tue, Mar 5, 2013 at 2:36 AM, Hannes Schüller <ha...@yl...> wrote:

> Then it's ok for me to merge it. Personally, I would give preference to
> always treat arguments as an URL when in doubt, but I also do see the
> case of testing for local files first.


I still don't see this having been merged. Is there something still holding
it up or did it just get lost in the mix? :)

Thanks,
Morgan

Re: [Vimprobable-users] vimprobable crash on NetBSD

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

Hi Leo!

Leonardo Taccari <ia...@gm...> wrote:
> On Sat, Feb 02, 2013 at 12:27:09AM +0100, Leonardo Taccari wrote:
> > On Fri, Feb 01, 2013 at 09:12:27PM +0100, Hannes Sch__ller wrote:
> > > > On Tue, Jan 29, 2013 at 10:36:21PM +0100, Hannes Sch__ller wrote:
> > > So is there a changeset between the versions in pkgsrc-2012Q3 and
> > > pkgsrc-2012Q4? Also, is there somewhere I can see the changes
> > > from the vanilla source?
> > There is no change from the vanilla source and also the vimprobable2
> > package has not changed between 2012Q3 and 2012Q4 (only its
> > dependencies are changed).
> 
> I'm running vimprobable2-1.2.1 with webkit-gtk from pkgsrc-2012Q3 and
> everything works (I think that the problem was due webkit-gtk and not
> vimprobable2).
> I hope I will be able to provide further information after the release
> of pkgsrc-2013Q1.

Thanks for this update. Keep us informed how it goes!

Hannes
P.S. No need to keep me in CC personally. I read the list.

Re: [Vimprobable-users] Copy&Paste problems

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

I added both suggestions to the Wiki at
http://sourceforge.net/apps/trac/vimprobable/wiki/FAQ

If you find anything inaccurate, feel free to edit the information!

Hannes

Re: [Vimprobable-users] Copy&Paste problems

[Hut <hu...@la...>]

On Sun, Mar 24, 2013 at 06:07:29PM +0100, Andraž 'ruskie' Levstik wrote:
> :2013-03-24T17:42:Hannes Schüller:
> > I'd say many of your issues originate from non-synchronised clipboards.
> 
> Look into parcellite ever since this got suggested to me I had no issues
> at all with copy&paste other than the occasional delay.

Thanks for the suggestions, it was indeed all due to unsynchronized
clipboards.  I found autocutsel, a minimalistic program to synchronize
them.  Running this solves the problems of my use cases:

> autocutsel -fork
> autocutsel -fork -selection PRIMARY

Re: [Vimprobable-users] Copy&Paste problems

[Andraž 'r. L. <ru...@co...>]

:2013-03-24T17:42:Hannes Schüller:
> I'd say many of your issues originate from non-synchronised clipboards.

Look into parcellite ever since this got suggested to me I had no issues
at all with copy&paste other than the occasional delay.

-- 
Andraž 'ruskie' Levstik
Source Mage GNU/Linux mage
Re-Alpine Coordinator http://sourceforge.net/projects/re-alpine/
Geek/Hacker/Tinker

The delightful and ever-novel pleasure of a useless occupation.

Re: [Vimprobable-users] Copy&Paste problems

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

Hi!

I'd say many of your issues originate from non-synchronised clipboards.

Hut <hu...@la...> wrote:
> 1. I see an image in the browser.  I click the right mouse button,
> then click on "Copy Image Address".  I go back to the terminal and
> paste it with shift+insert. I expect the address of the image to be
> pasted, but apparently it had no effect at all. 

Same here, that simply does nothing.

> 2. Same as 1 for "Copy Link Location" on links.

That works for me! If it doesn't, I'd say this is one of those
clipboard inconsistencies. Remember that the whole right-click menu in
Vimprobable is based on GTK rather than X directly. So what you copy
there will go into the GTK clipboard which is not accessible with
Shift+Insert, but rather Crtl-v.

> 3. I mark something in the terminal, go to vimprobable2 and press
> Shift+Insert, nothing happens.  Same for Ctrl+V Ctrl+V.

Same problem, the other way around: You're trying to access the X
clipboard in a GTK target. Try a middle click to paste.

Hannes

[Vimprobable-users] Copy&Paste problems

[Hut <hu...@la...>]

Hi vimprobable users,

One thing that really breaks my workflow with vimprobable2 is the
handling of copying & pasting.  Some situations with unexpected results
are:

1. I see an image in the browser.  I click the right mouse button, then
click on "Copy Image Address".  I go back to the terminal and paste it
with shift+insert.  I expect the address of the image to be pasted, but
apparently it had no effect at all. So, instead, whatever I copied
before that is pasted now instead.

2. Same as 1 for "Copy Link Location" on links.

3. I mark something in the terminal, go to vimprobable2 and press
Shift+Insert, nothing happens.  Same for Ctrl+V Ctrl+V.

Does anyone have tips to improve the behaviour of copying/pasting, or
patches to fix these issues?

I know about ";y" to deal with 1. and it works most of the time, but
it's impractical for huge/complicated websites where link hints take 10
seconds to load.

hut

Re: [Vimprobable-users] [PATCH] Further refactoring

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

I found some coing issues in the hinting java script. The following two
patches fixes them.

By the way, the image hintings should not work in the current implementation,
because we do a click on the hinted image that will not open the image. We
should reads the source of the imagen and give it to the c-layer to open it.
At the moment the image hinting works only for those images that where embeded
into a a-tag that will be openened because we let the click event bobble up.

Daniel

Re: [Vimprobable-users] Improve handling of file parameters

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

Hi!

Morgan Howe <mt...@gm...> wrote:
> On Sat, Mar 2, 2013 at 2:16 AM, Hannes Schüller <ha...@yl...>
> wrote:
> >
> > For me, the question which is still open is whether this patch also
> > fixes the issue of
> >
> > vimprobable2 ./index.htm
> >
> > which some people seem to experience in the current stable version.
> > I cannot test it since I cannot reproduce the original issue. If it
> > is fixed, is it because of the use of realpath or due to the stat
> > call?  
> 
>  Yes, it fixes that issue.

Then it's ok for me to merge it. Personally, I would give preference to
always treat arguments as an URL when in doubt, but I also do see the
case of testing for local files first.

Hannes

Re: [Vimprobable-users] Improve handling of file parameters

[Morgan H. <mt...@gm...>]

Hey Hannes,

On Sat, Mar 2, 2013 at 2:16 AM, Hannes Schüller <ha...@yl...> wrote:
>
> For me, the question which is still open is whether this patch also
> fixes the issue of
>
> vimprobable2 ./index.htm
>
> which some people seem to experience in the current stable version. I
> cannot test it since I cannot reproduce the original issue. If it is
> fixed, is it because of the use of realpath or due to the stat call?


 Yes, it fixes that issue. I believe this is due to URIs involving relative
paths not always being supported, depending on the interpreter (which may
explain why some people observe this behavior and others do not). You can
take a look at this[1] Stack Overflow response for further explanation. The
realpath() call fixes this, since it will generate an absolute pathname,
expanding all symlinks or relative portions of the path. The stat call is
used to determine if something is a file in the case that no URI scheme is
provided. Note that as I mentioned previously, if no scheme is provided, it
checks for the existence of a file with the given name prior to treating it
as a URL, but this can always be overridden by specifying a proper scheme.

Regards,
Morgan

[1]
http://stackoverflow.com/questions/7857416/file-uri-scheme-and-relative-files

Re: [Vimprobable-users] Improve handling of file parameters

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

Hi!

Morgan Howe <mt...@gm...> wrote:
> On Tue, Feb 26, 2013 at 2:49 AM, Hannes Schüller <ha...@yl...>
> wrote:
> > Morgan Howe <mt...@gm...> wrote:
> > > 1) Check if it's a search engine
> > > 2) If not a search engine, look for "://", if found, trust the
> > > user. 3) Else, check if it's a file and if so, build the file://
> > > URI 4) Else, check (again) if it's a search engine
> > > 5) Else, prefix with "http://" and attempt to open.
> > >
> > > Due to the order of the evaluation, the issue you mentioned
> > > originally should not be a problem.
> >
> > Actually, this is exactly the main issue I tried explaining
> > initially: the policy change to give precedence to local files over
> > URLs.
> 
> So is this acceptable to be merged then? The only conflict case
> remaining is a local file, in the current directory, with the exact
> same name as the domain you'd potentially like to visit. In such
> case, 'vp2 http://www.example.com' rather than 'vp2 www.example.com'
> is an easy and obvious workaround. 

For me, the question which is still open is whether this patch also
fixes the issue of

vimprobable2 ./index.htm

which some people seem to experience in the current stable version. I
cannot test it since I cannot reproduce the original issue. If it is
fixed, is it because of the use of realpath or due to the stat call?

Hannes

Re: [Vimprobable-users] Improve handling of file parameters

[Morgan H. <mt...@gm...>]

Hey Hannes,

Just wanted to follow up on this...

On Tue, Feb 26, 2013 at 2:49 AM, Hannes Schüller <ha...@yl...> wrote:

> Morgan Howe <mt...@gm...> wrote:
> > 1) Check if it's a search engine
> > 2) If not a search engine, look for "://", if found, trust the user.
> > 3) Else, check if it's a file and if so, build the file:// URI
> > 4) Else, check (again) if it's a search engine
> > 5) Else, prefix with "http://" and attempt to open.
> >
> > Due to the order of the evaluation, the issue you mentioned originally
> > should not be a problem.
>
> Actually, this is exactly the main issue I tried explaining initially:
> the policy change to give precedence to local files over URLs.


So is this acceptable to be merged then? The only conflict case remaining
is a local file, in the current directory, with the exact same name as the
domain you'd potentially like to visit. In such case, 'vp2
http://www.example.com' rather than 'vp2 www.example.com' is an easy and
obvious workaround. This seems like reasonable behavior, and I don't see
any other way of handling it short of what you said with actually probing
for a connection or checking DNS.

Regards,
Morgan

Re: [Vimprobable-users] install newbee problem

[Ludo B. <la...@gm...>]

Hi Hannes

I promise I won't make it a habit to go off topic, thanks for understanding.

> It would make sense to include the location in your $PATH environment
variable, though.

I'll do some searching for How To's on that :-)
Thanks also for the make vs makeinstall and the custom scripts explanation;
very clear.

> All that is printed on your terminal? Are you running some sort of
debugger? Is that the original source or some modified version? If so,
from where did you download it?

I downloaded from https://launchpad.net/~serge-hallyn/+archive/vimprobable
I choose "vimprobable2   1.2.0" if I remember correctly (I'm on LinuxMint13
btw).
I don't know the first thing about debuggers so I really wouldn't know.
Maybe it has to do with the -dev versions of the files mentioned in the
INSTALL that you suggested earlier?

Ludo

Re: [Vimprobable-users] install newbee problem

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

Hi Ludo,

most of your questions are not really Vimprobable specific. I will try
to answer them and I hope the other subscribers won't mind going
off-topic a little.

Ludo Beckers <la...@gm...> wrote:
> I'm not sure, can I simply move the directory to another place?

You can move the binary anywhere you like. It would make sense to
include the location in your $PATH environment variable, though. That
means it can be called from anywhere without specifying the full path.

> I've also included the output of the "make install", just in case it
> means more:
> 
> ludo@ludo-IXLs ~/Downloads/tarballs/vimprobable2 $ sudo make install
> [sudo] password for ludo:
> [ -e '///usr/local/bin' ] || mkdir -p '///usr/local/bin' && chmod 0755
> '///usr/local/bin'
> cp -f 'vimprobable2' '///usr/local/bin/vimprobable2'
> strip -s '///usr/local/bin/vimprobable2'
> chmod 0755 '///usr/local/bin/vimprobable2'
> [ -e '///usr/local/share/man/man1' ] || mkdir -p
> '///usr/local/share/man/man1' && chmod 0755
> '///usr/local/share/man/man1' cp -f 'vimprobable2.1'
> '///usr/local/share/man/man1/vimprobable2.1' chmod 0644
> '///usr/local/share/man/man1/vimprobable2.1' [ -e
> '///usr/local/share/man/man5' ] || mkdir -p
> '///usr/local/share/man/man5' && chmod 0755
> '///usr/local/share/man/man5' cp -f 'vimprobablerc.5'
> '///usr/local/share/man/man5/vimprobablerc.5' chmod 0644
> '///usr/local/share/man/man5/vimprobablerc.5' 

You have to understand what "make install" does. While "make" triggers
the actual compilation/building of the application, "make install" is
nothing but a copying process: the application itself and the manual
are copied to default, system-wide accessible locations. These
locations are specified in the Makefile (hence the first step of
modifying it as described in the INSTALL file). The default is to put
custom applications with the prefix /usr/local, i.e. the binary
into /usr/local/bin and the manual in /usr/local/share/man. Those steps
are printed for your convenience above. Meaning: By doing "make
install", you have already moved the application away from your
downloads directory.

> ludo@ludo-IXLs
> ~/Downloads/tarballs/vimprobable2 $ cd ludo@ludo-IXLs ~ $
> vimprobable2 Cannot open /home/ludo/.config//vimprobable/scripts.js:
> file not found 

This simply means that you do not have custom scripts defined to be run
inside the browser. This is just a feature which you don't need to use
obviously (personally, I don't use it, either). If you simply want to
get rid of this harmless message, I would suggest creating an empty
file in the specified location (using the touch command).

> No bp log location saved, using default. [000:000]
> Browser XEmbed support present: 1 [000:000] Browser toolkit is Gtk2.
> [000:000] Using Gtk2 toolkit
> [000:008] Warning(optionsfile.cc:47): Load: Could not open file, err=2
> [000:008] No bp log location saved, using default.
> [000:008] Browser XEmbed support present: 1
> [000:008] Browser toolkit is
> Gtk2.
> 
> [000:008] Using Gtk2
> toolkit
> 
> java version
> "1.7.0_15"
> 
> OpenJDK Runtime Environment (IcedTea7 2.3.7)
> (7u15-2.3.7-0ubuntu1~12.04)
> 
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed
> mode)

All that is printed on your terminal? Are you running some sort of
debugger? Is that the original source or some modified version? If so,
from where did you download it?

Hannes

Re: [Vimprobable-users] Improve handling of file parameters

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

Hi Morgan!

Morgan Howe <mt...@gm...> wrote:
> 1) Check if it's a search engine
> 2) If not a search engine, look for "://", if found, trust the user.
> 3) Else, check if it's a file and if so, build the file:// URI
> 4) Else, check (again) if it's a search engine
> 5) Else, prefix with "http://" and attempt to open.
> 
> Due to the order of the evaluation, the issue you mentioned originally
> should not be a problem.

Actually, this is exactly the main issue I tried explaining initially:
the policy change to give precedence to local files over URLs.

> Now the only other case would be a file named "http://www.example.com"
> which on any of the systems I have available is not a legal filename
> anyway. That would be the one case where the user would need to then
> properly specify the file:// prefix, though like I said, I'm not sure
> this scenario is even possible.

I think we can safely disregard this freak case :)

Hannes

Re: [Vimprobable-users] install newbee problem

[Ludo B. <la...@gm...>]

Hannes, I wasn't attentive enough when I did this and accidentally first
did "make install" instead of first clicking the executable.
I don't know if it matters?
Anyhow, vimprobable is working now!

I'm not sure, can I simply move the directory to another place?
I thought of making a "bin" directory in home and put it there instead of
leaving it in my "Downloads" folder.
Like I said, I'm used to install stuff via Synaptic mainly - so sorry for
the newbee ignorance and thanks for your patience :-)

There were some warning and error messages when starting vimprobable from
terminal.
I've also included the output of the "make install", just in case it means
more:

ludo@ludo-IXLs ~/Downloads/tarballs/vimprobable2 $ sudo make install
[sudo] password for ludo:
[ -e '///usr/local/bin' ] || mkdir -p '///usr/local/bin' && chmod 0755
'///usr/local/bin'
cp -f 'vimprobable2' '///usr/local/bin/vimprobable2'
strip -s '///usr/local/bin/vimprobable2'
chmod 0755 '///usr/local/bin/vimprobable2'
[ -e '///usr/local/share/man/man1' ] || mkdir -p
'///usr/local/share/man/man1' && chmod 0755 '///usr/local/share/man/man1'
cp -f 'vimprobable2.1' '///usr/local/share/man/man1/vimprobable2.1'
chmod 0644 '///usr/local/share/man/man1/vimprobable2.1'
[ -e '///usr/local/share/man/man5' ] || mkdir -p
'///usr/local/share/man/man5' && chmod 0755 '///usr/local/share/man/man5'
cp -f 'vimprobablerc.5' '///usr/local/share/man/man5/vimprobablerc.5'
chmod 0644 '///usr/local/share/man/man5/vimprobablerc.5'
ludo@ludo-IXLs ~/Downloads/tarballs/vimprobable2 $ cd
ludo@ludo-IXLs ~ $ vimprobable2
Cannot open /home/ludo/.config//vimprobable/scripts.js: file not found
No bp log location saved, using default.
[000:000] Browser XEmbed support present: 1
[000:000] Browser toolkit is Gtk2.
[000:000] Using Gtk2 toolkit
[000:008] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:008] No bp log location saved, using default.
[000:008] Browser XEmbed support present: 1
[000:008] Browser toolkit is
Gtk2.

[000:008] Using Gtk2
toolkit

java version
"1.7.0_15"

OpenJDK Runtime Environment (IcedTea7 2.3.7)
(7u15-2.3.7-0ubuntu1~12.04)

OpenJDK 64-Bit Server VM (build 23.7-b01, mixed
mode)

** Message: console message: undefined @0: ReferenceError: Can't find
variable: pageTracker

>
> Date: Sun, 24 Feb 2013 21:46:34 +0100
> From: Hannes Sch?ller <ha...@yl...>
> Subject: Re: [Vimprobable-users] install newbee problem
> To: vim...@li...
> Message-ID: <20130224214634.7a6a0559@workstation>
> Content-Type: text/plain; charset=US-ASCII
>
> Ludo Beckers <la...@gm...> wrote:
> > I guess the "deprecated" mention is still problematic?
>
> No. You should have a working vimprobable2 binary in your
> working directory now. Try running it. If it works, make install.
>
> The warning comes from building against GTK3 instead of GTK2.
> Deprecation simply means that a future version of the library *might*
> drop support for the function.
>
> Hannes
>
>
>

Re: [Vimprobable-users] Improve handling of file parameters

[Morgan H. <mt...@gm...>]

On Mon, Feb 25, 2013 at 5:08 PM, Morgan Howe <mt...@gm...> wrote:

> vp2 www.example.com
> Check for file, if it exists, build the URI as in my patch, otherwise fall
> back to URL.
>
> vp2 http://www.example.com
> Properly formed URI, use it.
>
> Now the only other case would be a file named "http://www.example.com"
> which on any of the systems I have available is not a legal filename
> anyway. That would be the one case where the user would need to then
> properly specify the file:// prefix, though like I said, I'm not sure this
> scenario is even possible. Either way, at least with this behavior, there
> is always a reasonable workaround. Better suggestions are welcome. :)
>
> Which, actually, should be the current behavior now that I review the code
(my patch did not have enough context lines to show the full logic). The
current steps are:

1) Check if it's a search engine
2) If not a search engine, look for "://", if found, trust the user.
3) Else, check if it's a file and if so, build the file:// URI
4) Else, check (again) if it's a search engine
5) Else, prefix with "http://" and attempt to open.

Due to the order of the evaluation, the issue you mentioned originally
should not be a problem.

Regards,
Morgan

Re: [Vimprobable-users] Improve handling of file parameters

[Morgan H. <mt...@gm...>]

On Mon, Feb 25, 2013 at 4:30 PM, Hannes Schüller <ha...@yl...> wrote:

> Has it occured to you that it might be much more convenient for
> everyone involved to simply... subscribe? It's not like this list will
> send tons of traffic to your inbox. As you can see, there have been a
> couple of other responses to this thread and it's virtually impossible
> that everybody will remember to keep the CC in all of them.
>

Alright, you've sold me. Subscribed.


>
> > > on your command line. Your solution would make it impossible to call
> > > URLs from a directory which has a file or subdirectory with the same
> > > name as the URL. E.g. if your file system looks like this:
> > > .
> > > ..
> > > http://www.example.org
> > > and you call
> > > vimprobable http://www.example.org
> > > it will call the local directory instead of the URL. No workaround
> > > possible. Before someone argues that this is a rather academic
> > > example, I would like to point out that such a directory structure
> > > is not so uncommon on machines used for web development.
> > >
> >
> > Yeah, I considered this, though I was thinking that would be a rare
> > situation. Not being a web developer personally, that may have been a
> > bit presumptuous. Perhaps it may be better to check if the parameter
> > is already a URI first, before checking if it is a file? At least
> > that way, there would always be a workaround in case of name
> > conflicts.
>
> And how would you detect if something is a URL? The only reliable way I
> can think of would be sending a skeleton HTTP request out to see if
> there is a response. Which would involve potential failure sources like
> DNS which are completely outside the scope of the browser itself.
>
>
No, I would rather not do that and I agree that overly complicate things
and potentially slow down the initial opening of the browser which is
obviously not something we'd want. I was thinking something more along the
lines of just verifying that the parameter is a properly formed URI, and if
it is, we trust the user and explicitly do what they ask. I'm not entirely
versed in the details of RFC 3986 [1], but to refer back to your example, I
was thinking something along these lines:

vp2 www.example.com
Check for file, if it exists, build the URI as in my patch, otherwise fall
back to URL.

vp2 http://www.example.com
Properly formed URI, use it.

Now the only other case would be a file named "http://www.example.com"
which on any of the systems I have available is not a legal filename
anyway. That would be the one case where the user would need to then
properly specify the file:// prefix, though like I said, I'm not sure this
scenario is even possible. Either way, at least with this behavior, there
is always a reasonable workaround. Better suggestions are welcome. :)

Regards,
Morgan

[1] http://www.ietf.org/rfc/rfc3986.txt

Re: [Vimprobable-users] Improve handling of file parameters

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

Hi!

Morgan Howe <mt...@gm...> wrote:
> Apologies for the odd means of responding - I'm not on the list,
> please CC me in the future. :)

Has it occured to you that it might be much more convenient for
everyone involved to simply... subscribe? It's not like this list will
send tons of traffic to your inbox. As you can see, there have been a
couple of other responses to this thread and it's virtually impossible
that everybody will remember to keep the CC in all of them.

> > on your command line. Your solution would make it impossible to call
> > URLs from a directory which has a file or subdirectory with the same
> > name as the URL. E.g. if your file system looks like this:
> > .
> > ..
> > http://www.example.org
> > and you call
> > vimprobable http://www.example.org
> > it will call the local directory instead of the URL. No workaround
> > possible. Before someone argues that this is a rather academic
> > example, I would like to point out that such a directory structure
> > is not so uncommon on machines used for web development.
> >
> 
> Yeah, I considered this, though I was thinking that would be a rare
> situation. Not being a web developer personally, that may have been a
> bit presumptuous. Perhaps it may be better to check if the parameter
> is already a URI first, before checking if it is a file? At least
> that way, there would always be a workaround in case of name
> conflicts.

And how would you detect if something is a URL? The only reliable way I
can think of would be sending a skeleton HTTP request out to see if
there is a response. Which would involve potential failure sources like
DNS which are completely outside the scope of the browser itself.

What would be the behaviour if the user intends to call a URL, but name
resolution temporarily fails? Will the URL string then be passed to
local file handling? So that means that if it cannot be found locally
either, the error thrown at the user will be 'file not found' instead
of 'host name not found' which would be quite confusing.

Hannes

Re: [Vimprobable-users] Improve handling of file parameters

[Morgan H. <mt...@gm...>]

Apologies for the odd means of responding - I'm not on the list, please CC
me in the future. :)


> Hi!
> Morgan Howe <mthowe@...> wrote:
> > I look at a lot of test generated html output and the like, so I
> > frequently hit problems with file paths. Because of the URI, things
> > would only open properly if I provided a full path, or something that
> > would be expanded by the shell into a full path such as
> > ~/html/index.html. Modified to use realpath() to fix this issue. It
> > would also fail to detect file parameters without a "/" in the path
> > (e.g. "index.html"), so changed to use stat() instead of looking for
> > "/" or "./" when determining if an argument is a file. This takes care
> > of any issues I have run into with using vimprobable to view local
> > files.
> Hmm... well, this seems to work as advertised, but I'd like to hear
> some opinions. As far as I can see, your problem boils down to
> a) relative paths not being recognised (e.g. ../dir/file.htm).
> b) you assuming that . should be in the search path (e.g. index.htm).
> The second one, I don't really consider a problem, to be honest. You
> could easily just write
> vimprobable ./index.htm
>

Agreed, the second case wasn't really a big issue, but the way I changed
the code fixed it for both cases.


> on your command line. Your solution would make it impossible to call
> URLs from a directory which has a file or subdirectory with the same
> name as the URL. E.g. if your file system looks like this:
> .
> ..
> http://www.example.org
> and you call
> vimprobable http://www.example.org
> it will call the local directory instead of the URL. No workaround
> possible. Before someone argues that this is a rather academic example,
> I would like to point out that such a directory structure is not so
> uncommon on machines used for web development.
>

Yeah, I considered this, though I was thinking that would be a rare
situation. Not being a web developer personally, that may have been a bit
presumptuous. Perhaps it may be better to check if the parameter is already
a URI first, before checking if it is a file? At least that way, there
would always be a workaround in case of name conflicts.

Regards,
Morgan

Re: [Vimprobable-users] install newbee problem

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

Ludo Beckers <la...@gm...> wrote:
> I guess the "deprecated" mention is still problematic?

No. You should have a working vimprobable2 binary in your
working directory now. Try running it. If it works, make install.

The warning comes from building against GTK3 instead of GTK2.
Deprecation simply means that a future version of the library *might*
drop support for the function.

Hannes

Re: [Vimprobable-users] install newbee problem

[Ludo B. <la...@gm...>]

Thanks Hannes, ok, I'm getting closer, but there's no cigar yet ;-)

Synaptic didn't find any libgtk+... so I took libgtk-3-dev, which did
mention something about "+" in the description.
After downloading the other 2 necessary files, here's how far I got:

ludo@ludo-IXLs ~/Downloads/tarballs/vimprobable2 $ make
cc -MMD -c `pkg-config --cflags gtk+-2.0 webkit-1.0 libsoup-2.4`
-D_XOPEN_SOURCE=500 callbacks.c -o callbacks.o
perl ./js-merge-helper.pl
cc -MMD -c `pkg-config --cflags gtk+-2.0 webkit-1.0 libsoup-2.4`
-D_XOPEN_SOURCE=500 main.c -o main.o
cc -MMD -c `pkg-config --cflags gtk+-2.0 webkit-1.0 libsoup-2.4`
-D_XOPEN_SOURCE=500 utilities.c -o utilities.o
utilities.c: In functie ‘complete_list’:
utilities.c:567:17: let op: ‘g_strdown’ is deprecated (declared at
/usr/include/glib-2.0/glib/gstrfuncs.h:179) [-Wdeprecated-declarations]
cc callbacks.o main.o utilities.o `pkg-config --libs gtk+-2.0 webkit-1.0
libsoup-2.4` -lX11 -lXext -o vimprobable2

I guess the "deprecated" mention is still problematic?
Ludo