vimprobable-users — Mailing list for Vimprobable users

[Vimprobable-users] RFC: Added support for buffers

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

This patch adds basic support for handling multiple buffers. New
commands are ":buf[fer], :badd, and :bdelete". Buffers are given a
unique constant buffer id starting at 1 in the same manner as vim.

The :badd command takes an optional url argument which it will open
when creating the buffer. If none is provided, it will open a new,
blank buffer.

The :buf[fer] command allows changing to another buffer in the buffer
list and supports tab completion.

The :bdelete command also supports tab completion and takes an
optional buffer argument and deletes it. If no argument is provided,
the current buffer is deleted.

I tried to as closely as possible follow the behavior in vim so that
it would be familiar to use and have been using it for several months
now. The buffer naming used in the tab completion is kind of clunky
but it works well enough. Other than that, I haven't had any serious
problems or complaints.

Please discuss if this is even something we think is worth adding, if
we should make it a compile time conditional feature, if you have
better suggestions for the implementation or tab completion, etc. I'd
appreciate any feedback. And of course please try it out. :)

*NOTE: This patch builds upon my previous patch just submitted to the
list regarding the commands list and COMMANDSIZE variable. These 2
patches are obviously conflicting, so you'll need to apply that one
first to test the buffer support. These changes are also in my
for-next branch on SF.

Regards,
Morgan

[Vimprobable-users] Move commands to main.c, get rid of COMMANDSIZE

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

This patch moves the commands out of the header file and into main.c
and makes the COMMANDSIZE a compile time calculated const value. This
makes it so we don't need to remember to update that value each time a
new command is added, reduces likelihood of merge conflicts when
adding new commands, and should make things a bit more flexible in the
future (user defined colon commands?).

Regards,
Morgan

Re: [Vimprobable-users] Cannot log in to google+

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

On Wed, Feb 18, 2015 at 8:19 AM, Jason Ryan <jas...@gm...> wrote:
> On 18/02/15 at 01:05am, Valentin Rusu wrote:
>>
>> Hello list,
>>
>> Trying to switch to vimprobable2, which I find really kool, I'm now
>> visiting my usual websites. And there's a problem when trying to log-in
>> to plus.google.com

Putting "set cookies=true" in your vimprobablerc fixes the issue for
me (the default is no_third).

> I get a “Your browser is no longer supported” message.

I still get a similar warning in gmail (even though it works) so you
might have to fiddle with your useragent string to get rid of that.

Morgan

Re: [Vimprobable-users] Cannot log in to google+

[Jason R. <jas...@gm...>]

On 18/02/15 at 01:05am, Valentin Rusu wrote:
>Hello list,
>
>Trying to switch to vimprobable2, which I find really kool, I'm now
>visiting my usual websites. And there's a problem when trying to log-in
>to plus.google.com

I get a “Your browser is no longer supported” message.

This suggests two things, both patently false:
1. That the googleplex did once in fact support my browser, and
2. That downloading one of the recommended options (Chrome, IE, Firefox or
Safari) would constitute an “upgrade”.

Google. Meh.

/J

-- 

http://jasonwryan.com/  [GnuPG Key: B1BD4E40]

[Vimprobable-users] Cannot log in to google+

[Valentin R. <sou...@ru...>]

Hello list,

Trying to switch to vimprobable2, which I find really kool, I'm now
visiting my usual websites. And there's a problem when trying to log-in
to plus.google.com

I have two factor login activated on my account. The password-screen
works, but after entering the confirmation code it redirects me to this
page:
https://support.google.com/accounts/answer/32050?hl=en&ctx=ch_CheckCookie&p=oz

This page instructs me to clear the cookies on my system. I already
removed these directories:
~/.cache/webkit
~/.local/webkit

I'm using Archlinux and I compiled vimprobable2 from the latest sources.

What should I do to get it working with google services?

Thanks,

-- 
Valentin Rusu
IRC: valir

Re: [Vimprobable-users] Download bugs

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

Fixed in master branch (hopefully).

Re: [Vimprobable-users] Possible patch/fix for g_thread_init warning

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

Hi Matthew,

thanks for this! As Morgan has said, a similar fix was part of another
patch which I had simply neglected to merge. Sorry. It's now in the
master branch.

Hannes

Re: [Vimprobable-users] Possible patch/fix for g_thread_init warning

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

And of course I forgot to include the link for my footnote:

[1] https://sourceforge.net/p/vimprobable/mailman/message/33186735/

On Sat, Feb 14, 2015 at 4:26 PM, Morgan Howe <mt...@gm...> wrote:
> Hey Matthew,
>
> Since no one has said anything I figured I would respond so at least
> you didn't think you were being ignored. :) I took care of this in
> another patch in December[1], which still has not made it into the
> main tree. I think Hannes is a bit behind schedule after the Christmas
> break, so there's still quite a few patches waiting to get merged.
>
> I think my fix is a bit more comprehensive, but I also had the same
> issue as you, in that I don't have any systems with an old enough glib
> to actually verify the fix. :D Anyway, thanks for your patch and I
> don't care if it's yours or mine as long as we can get rid of the
> annoying build warning!
>
> Regards,
> Morgan
>
> On Fri, Feb 6, 2015 at 2:39 PM, Matthew Carter <m...@ah...> wrote:
>> Hi all,
>>
>> As some of you who use a recent version of glib may know, g_thread_init
>> has been deprecated (and every 'make' comes with a nice warning about
>> this).
>>
>> This patch fixes that on newer glib versions (such as what I use on Arch
>> Linux), but I'm not sure if it breaks on older glib versions.
>>
>> Does anyone who uses an old enough version of glib to actually need
>> g_thread_init have time to test the patch and make sure it doesn't break
>> their compilation?
>>
>>
>>
>>
>> --
>> Matthew Carter (m...@ah...)
>> http://ahungry.com
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Vimprobable-users mailing list
>> Vim...@li...
>> https://lists.sourceforge.net/lists/listinfo/vimprobable-users
>>

Re: [Vimprobable-users] Possible patch/fix for g_thread_init warning

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

Hey Matthew,

Since no one has said anything I figured I would respond so at least
you didn't think you were being ignored. :) I took care of this in
another patch in December[1], which still has not made it into the
main tree. I think Hannes is a bit behind schedule after the Christmas
break, so there's still quite a few patches waiting to get merged.

I think my fix is a bit more comprehensive, but I also had the same
issue as you, in that I don't have any systems with an old enough glib
to actually verify the fix. :D Anyway, thanks for your patch and I
don't care if it's yours or mine as long as we can get rid of the
annoying build warning!

Regards,
Morgan

On Fri, Feb 6, 2015 at 2:39 PM, Matthew Carter <m...@ah...> wrote:
> Hi all,
>
> As some of you who use a recent version of glib may know, g_thread_init
> has been deprecated (and every 'make' comes with a nice warning about
> this).
>
> This patch fixes that on newer glib versions (such as what I use on Arch
> Linux), but I'm not sure if it breaks on older glib versions.
>
> Does anyone who uses an old enough version of glib to actually need
> g_thread_init have time to test the patch and make sure it doesn't break
> their compilation?
>
>
>
>
> --
> Matthew Carter (m...@ah...)
> http://ahungry.com
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Vimprobable-users mailing list
> Vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimprobable-users
>

[Vimprobable-users] Possible patch/fix for g_thread_init warning

[Matthew C. <m...@ah...>]

Hi all,

As some of you who use a recent version of glib may know, g_thread_init
has been deprecated (and every 'make' comes with a nice warning about
this).

This patch fixes that on newer glib versions (such as what I use on Arch
Linux), but I'm not sure if it breaks on older glib versions.

Does anyone who uses an old enough version of glib to actually need
g_thread_init have time to test the patch and make sure it doesn't break
their compilation?

Re: [Vimprobable-users] Preserving hint numbering in different hint modes

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

Morgan Howe <mt...@gm...> wrote:
> PS. I have 3 small patches sent to the list while you were away, but
> sourceforge was acting up and there haven't been any comments on them.
> Let me know if they're in your queue or rejected, or if I should
> resend.

I've got command history length, GLib warning and :clear. All look fine.

Hannes

Re: [Vimprobable-users] Preserving hint numbering in different hint modes

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

En/Je/On 2015-01-22 16:55, Morgan Howe escribió / skribis / wrote :

> I found it a bit irritating that hints are numbered differently in
> open mode as compared with yank or show modes, so this patch fixes
> that issue.

I agree, I think it's an improvement. Thank you.

-- 
Marcos Cruz
http://programandala.net

Re: [Vimprobable-users] Preserving hint numbering in different hint modes

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

Hey Hannes,

Here's a v2 of the patch that I actually prefer. This one achieves the
same thing, but filters out in javascript those elements that are not
valid for yank or show. This helps reduce the screen clutter so that
it looks the same as it did originally while still keeping the hint
numbers consistent. It also gets rid of the ugly "undefined" checks in
the C code.

I tried to recreate the same checks as the original xpath, but as per
my usual disclaimer, I'm not an xpath expert so please take a look. :)

Regards,
Morgan

PS. I have 3 small patches sent to the list while you were away, but
sourceforge was acting up and there haven't been any comments on them.
Let me know if they're in your queue or rejected, or if I should
resend.

On Fri, Jan 23, 2015 at 1:38 AM, Hannes Schüller <ha...@yl...> wrote:
> Hi!
>
> Morgan Howe <mt...@gm...> wrote:
>> I found it a bit irritating that hints are numbered differently in
>> open mode as compared with yank or show modes, so this patch fixes
>> that issue.
>
> I don't find this particularly controversial. It makes sense to me and
> to be honest, I'm actually surprised that this isn't already the case.
>
> Any other adversial comments?
>
> Hannes
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Vimprobable-users mailing list
> Vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimprobable-users

Re: [Vimprobable-users] Preserving hint numbering in different hint modes

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

Hi!

Morgan Howe <mt...@gm...> wrote:
> I found it a bit irritating that hints are numbered differently in
> open mode as compared with yank or show modes, so this patch fixes
> that issue. 

I don't find this particularly controversial. It makes sense to me and
to be honest, I'm actually surprised that this isn't already the case.

Any other adversial comments?

Hannes

[Vimprobable-users] Preserving hint numbering in different hint modes

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

Probably not everyone will agree with this patch or whether it is
necessary, so consider this as much of an RFC as an actual patch. :)

I found it a bit irritating that hints are numbered differently in
open mode as compared with yank or show modes, so this patch fixes
that issue. For example, you may want to follow a link but you don't
trust the source, so you do ";l" and find that it's hint number 72.
You see the link and decide it's safe, so you do "f", but now due to
the different modes you have to scan through the page again and find
that the link has changed to 103. This is somewhat confusing, as you'd
expect to be able to just do ";l72", "f72". This issue is especially
noticeable on sites like reddit, which contain a lot of both links and
clickable javascript.

This is obviously a bit of a nitpick, but it seems much more intuitive
to me. It does introduce the issue of possibly yanking or showing a
link that is undefined, which I handled by just silently ignoring.
Feel free to discuss and keep the current behavior if I'm too picky.
:)

Regards,
Morgan

[Vimprobable-users] Download bugs

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

jasonwryan came across a regression in download handling, where 'f'ing
or ';s'ing a pdf link does nothing. After a bisect, I found this was
introduced by:

commit cbf47b201a04aaf5165595c308dd76bb42b185a9
Author: Hannes Schueller <ha...@yl...>
Date:   Fri Dec 26 11:19:24 2014 +0100

    bugfix: only trigger a download when status code is in the 2xx range

What I found is that SOUP_STATUS_IS_SUCCESSFUL always fails because
the http_status is always set to the default of 0. Some cursory
searching about this leads me to believe we should also be checking
SOUP_STATUS_IS_REDIRECT, but that obviously doesn't matter either
until the primary bug is fixed.

While bisecting this I also came across another bug in downloading
which does not appear to be new. When attempting to download some of
the direct pdf links from google (for an easy example) you'll get ugly
urls like "www.google.com/url?target=http://www.example.com/file.pdf".
webkit_download_get_suggested_name gives us a suggested filename of
"url", and the download fails. This seems more like a bug in webkit,
or possibly in our usage of the webkit interface.

Morgan

Re: [Vimprobable-users] Add command history length setting

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

Morgan Howe <mt...@gm...> wrote:
> This patch adds support for the "hi"/"history" setting for changing
> the command history length.

I'm not sure, but I think we have to free the memory after
g_list_delete_link() because the commands are written as newly allocated
strings g_list_append(s->commandhistory, g_strdup(c));

Maybe I'm wrong, and this is not related to the patch, but seems to be an
issue in current implementation too.

Daniel

Re: [Vimprobable-users] Changing the hints CSS and other config without recompile

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

Hannes Schüller <ha...@yl...> wrote:
> Hi,
> 
> the attached patch exposes all visible hinting elements to styling via
> style.css. Four classes are used:
> 
> - vimprobable_hinting_mode_hint: unfocused number
> - vimprobable_hinting_mode_hint_focus: focused number
> - vimprobable_hinted_element: unfocused complete link
> - vimprobable_hinted_element_focus: focused complete link

From point of styling it would be easier to split the classes into a two
parts. One for hint-label or hint-element and a second class that indicated
the focus on them.

- vimprobable_label: hint label in general
- vimprobable_element: hinted element
- vimprobable_active: hinted element or label is currently active

The classes vimprobable_label and vimprobable_element can be used to apply a
general style to the hint labels and hinted elements like font-size, or
border. And the vimprobable_active class could be used to update the style in
case the hinted element or label is focused.

    /* style the hint label */
    .vimprobable_label {
        -webkit-transform:translate(-4px,-4px);
        background-color: #fff;
        border: 1px solid #444;
        color: #000;
        font:bold .9em monospace;
        margin: 0;
        opacity: 0.5;
        padding: 0px 1px;
        position: absolute;
        z-index: 100000;
    }
    /* style update for active hint label */
    .vimprobable_label.vimprobable_active {
        opacity: 1;
    }

I think we should apply such a default style by adding the style node into the
head of the current page and make sure that we do not do that twice.

Daniel

[Vimprobable-users] Add the :clear command

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

This patch builds on the prior history setting patch, but I figured it
might be of the most questionable necessity. This adds the ":clear"
command for clearing history. I noticed that the commands processed
from the rc file ended up in the command history, and thought this
should not be the case. That's debatable, but this allows clearing the
history either as the last command in the rc file or manually any
other time.

Morgan

Re: [Vimprobable-users] Clean up a GLib warning and const correctness issue

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

In discussion with IRC user collin38, (s)he brought to my attention
that the one remaining warning I hadn't cleaned up was in a situation
where the printf was entirely unnecessary. So, I've fixed up the patch
to get rid of that final warning and resubmitting as v2.

Morgan

PS. I also have 2 more patches submitted last night that haven't shown
up on the mailing list. I'll wait another day or so to see if SF is
just being slow or lost my emails, and resubmit if necessary.

On Fri, Dec 26, 2014 at 10:09 PM, Morgan Howe <mt...@gm...> wrote:
> This patch cleans up what appears to be a memory leak in
> webview_download_cb, the const correctness of search_uris, and gets
> rid of the deprecated function warning on g_thread_init.
>
> Morgan

[Vimprobable-users] Add command history length setting

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

This patch adds support for the "hi"/"history" setting for changing
the command history length.

Morgan

Re: [Vimprobable-users] Changing the hints CSS and other config without recompile

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

Hi,

the attached patch exposes all visible hinting elements to styling via
style.css. Four classes are used:

- vimprobable_hinting_mode_hint: unfocused number
- vimprobable_hinting_mode_hint_focus: focused number
- vimprobable_hinted_element: unfocused complete link
- vimprobable_hinted_element_focus: focused complete link

You can override the defaults the same way Daniel described in his
earlier mail.

On a sidenote, I believe there is even a bug in the current hinting
script. It already attempts to set specific classes to focused and
unfocused hints, but gets confused in the process, I fear: class
names which aren't even set are attempted to be replaced. Daniel, maybe
I've been misreading something there? In any case, I believe this patch
fixes that as well.

Please test and provide feedback!

Hannes

[Vimprobable-users] Clean up a GLib warning and const correctness issue

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

This patch cleans up what appears to be a memory leak in
webview_download_cb, the const correctness of search_uris, and gets
rid of the deprecated function warning on g_thread_init.

Morgan

Re: [Vimprobable-users] Changing the hints CSS and other config without recompile // defaults

[Jason R. <jas...@gm...>]

On 24/12/14 at 08:48am, Hannes Schüller wrote:
>On Wed, 24 Dec 2014 07:57:30 +1300, Jason Ryan <jas...@gm...>
>wrote:
>> The current defaults (red on yellow) may pose accessibility issues
>> for people with colourblindness[0], a better combination would be
>> black on yellow (the international traffic standard).
>
>Thanks for this research, Jason!
>
>So are you suggesting a yellow background of the complete link, black
>background for the number and white for the number itself? Or do you
>mean getting rid off one of those three colours?
>
I was just envisaging a black number on a yellow background: the third colour
(the complete link) seems like overkill to me, but if it is to be retained then
a neutral colour would probably work best.

However, it has been many years since I actively paid attention to WCAG, so I'd
happily defer to people who are knowledgeable in that space.

Cheers,

/J

-- 

http://jasonwryan.com/  [GnuPG Key: B1BD4E40]

Re: [Vimprobable-users] Changing the hints CSS and other config without recompile // defaults

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

On Wed, 24 Dec 2014 07:57:30 +1300, Jason Ryan <jas...@gm...>
wrote:
> The current defaults (red on yellow) may pose accessibility issues
> for people with colourblindness[0], a better combination would be
> black on yellow (the international traffic standard).

Thanks for this research, Jason!

So are you suggesting a yellow background of the complete link, black
background for the number and white for the number itself? Or do you
mean getting rid off one of those three colours?

Hannes