vimprobable-users — Mailing list for Vimprobable users

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

Hi Hannes!
On Tue, Aug 16, 2011 at 09:51:21PM +0200, Hannes Schüller wrote:
> Any idea of how to handle target attributes? As I said, I think the
> current behaviour of the patch isn't too bad, but it's also not the
> expected behaviour ;) So any chance of getting that working as well?
> Which logic would need to be relocated?

I think we should depending of pressed key give additional params from
C-Layer to the scripts createHints() function. These param would be set
in the object and used to do the right thing in the fire() function.

We have to differ between opening new window or not and returning the
url of hint or open it. Uzbl uses two variables for this 'newwindow' and
'returnuri', don't know if we need both too.

Cases:
f (open in current window):
- 'newwindow' set to false
- dispatch click event on hinted element
  - links within frames should be opened in the current frame
  - would also fix some sites using tabmenu with links that are observed
    for cnklick event -- these will cause the site to be reloaded in the
    current version because the fire() function retrieves the url to the
    C-Layer
- return nothing to C-Layer

F (open in new window):
- 'newwindow' set to true
- dispatch CTRL-Click event (seems not to work) alternate set
  target='_blank' dispatch click event and remove target attribute
  - should work like the pentadactyl plugin, that opens the link into
    a new window

Yank URL (not implemented):
- return the src or href attribute value to the C-Layer

Other Modes (not implemented):
- return some other nice information of the hinted element to the
  C-Layer

I think for the more sofisticated hint actions like the ;... in
pentadactyl we have to set a mode for the hinting.js so that the script
knows what for an information to return on fire().

Daniel

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

Hi!

Daniel Carl <dan...@gm...> wrote:
> > - Using the patch, I get the following message on the console: "@1:
> >   Unsafe JavaScript attempt to access frame with URL
> >   http://... from frame with URL http://... Domains, protocols and
> >   ports must match."
> The loggin of these message seems to be a bug in webkit. The
> violation of same origin policy sould throw an exception instead of
> logging only a message on console and retriev undefined values.
> https://lists.webkit.org/pipermail/webkit-dev/2010-August/thread.html#13880
> http://code.google.com/p/chromium/issues/detail?id=17325
> 
> I think we have to live with this behaviour for now.

I guess it's not much of a problem. Maybe something to document on the
website (wiki/ticket) when it's merged.

Any idea of how to handle target attributes? As I said, I think the
current behaviour of the patch isn't too bad, but it's also not the
expected behaviour ;) So any chance of getting that working as well?
Which logic would need to be relocated?

Hannes

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

Hi Hannes.

> - Using the patch, I get the following message on the console: "@1:
>   Unsafe JavaScript attempt to access frame with URL
>   http://... from frame with URL http://... Domains, protocols and
>   ports must match."
The loggin of these message seems to be a bug in webkit. The violation of same
origin policy sould throw an exception instead of logging only a message on
console and retriev undefined values.
https://lists.webkit.org/pipermail/webkit-dev/2010-August/thread.html#13880
http://code.google.com/p/chromium/issues/detail?id=17325

I think we have to live with this behaviour for now.

Daniel

Re: [Vimprobable-users] Features for next version

[Ryan M. <rm...@de...>]

Hi,

> On a related note, there is the question of version numbering.
> Should we have:
> - Vimprobable1 1.0 and Vimprobable2 1.0 or
> - Vimprobable 1.0 and Vimprobable 2.0?

vimprobable1 should be vimprobable-legacy
vimprobable2 should be vimprobable

All new development should be done as vimprobable, IMHO.

Ryan

Re: [Vimprobable-users] Features for next version

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

Hi Hannes!

On Mon, Aug 15, 2011 at 02:27:20PM +0200, Hannes Schüller wrote:
> So, if we went this way, wouldn't this be "Vimprobable3"? I.e. another
> new branch separat from the others? I.e.: Doesn't what you're saying
> actually *support* my suggestion to open up yet another branch to keep
> Vimprobable2 "cleaner"?
Do you mean, we should use a seperate branch for every more featureful
vimprobable? This could be a way, but we have to maintain 3 different
versions, apply bugfixes on them, test them... .
To seperate Vimprobable1 is usefull, because it's realy something other
then the more featrueful Vimprobable2. But I think it's do hard to have
to many branches with seperate versions.
I think all future features should be avaiable for Vimprobable2 and be
enabled/disabled via config.h

Daniel

Re: [Vimprobable-users] Features for next version

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

Hi!

Daniel Carl <dan...@gm...> wrote:
> > On a related note, there is the question of version numbering.
> > Should we have:
> > - Vimprobable1 1.0 and Vimprobable2 1.0 or
> > - Vimprobable 1.0 and Vimprobable 2.0?
> In my opinion vimprobable1 and vimprobable2 are two different things
> and not only different version of the same programm. I think
> vimprobable1 should be in a seperate branch with seperate version
> numbers. Users that like the vimprobable1 can checkout this branch
> and can fetch bugfixes for it and, maybe, some new fetaures.
> 
> Vimprobable2/master could be the other branch and have it's own
> versionnumbering.
> 
> Like mentiones in a pervious post, I would prefer to put all features
> into the master branch and allo them to be enabled/disabled via
> precompiler options.

So, if we went this way, wouldn't this be "Vimprobable3"? I.e. another
new branch separat from the others? I.e.: Doesn't what you're saying
actually *support* my suggestion to open up yet another branch to keep
Vimprobable2 "cleaner"?

Hannes

Re: [Vimprobable-users] Features for next version

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

Hi!
> On a related note, there is the question of version numbering. Should
> we have:
> - Vimprobable1 1.0 and Vimprobable2 1.0 or
> - Vimprobable 1.0 and Vimprobable 2.0?
In my opinion vimprobable1 and vimprobable2 are two different things and
not only different version of the same programm. I think vimprobable1
should be in a seperate branch with seperate version numbers. Users that
like the vimprobable1 can checkout this branch and can fetch bugfixes
for it and, maybe, some new fetaures.

Vimprobable2/master could be the other branch and have it's own
versionnumbering.

For the features, it could be useful to have fetature branches (could be
prefixed with feature/*), that exists until the feature is merged into
the master/vimprobable1. After merging we could remove the
featurebranches, to ceep the repository clean.

Like mentiones in a pervious post, I would prefer to put all features
into the master branch and allo them to be enabled/disabled via
precompiler options. For the features the complexity with the switchable
features should acceptable. I think, to have only a basic vimprobable2
and several feature branches could make it difficould for users to merge
the wished browser together. For every bugfix in featurebranch the user
have to merge the sources together. Sometimes merging is hard enought
for developers that  knew the code well, but for a user who want to
build the browser it would be harder.

Daniel

Re: [Vimprobable-users] Features for next version

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

Jason Ryan <jas...@gm...> wrote:
> On 15/08/11 at 08:13am, Hannes Sch__ller wrote:
> > Jason Ryan <jas...@gm...> wrote:
> > > > On a related note, there is the question of version numbering.
> > > > Should we have:
> > > > - Vimprobable1 1.0 and Vimprobable2 1.0 or
> > > > - Vimprobable 1.0 and Vimprobable 2.0?  
> > > 
> > > The former: the latter makes Vimprobable 2.0 sound like the later
> > > release of Vimprobable 1.0
> > 
> > Well, it *is*, isn't it? It's a branch of the original code with
> > stuff added to it.
> > 
> Ah, I hadn't grasped the nature of the relationship: I thought they
> were developed in parallel.

Well, yes, this is also true. Vimprobable2 was branched off
Vimprobable1. Since then, they have been developed in parallel.
However, truely in parallel: Everything has been done in both branches
at the same time save for the addition of new features depending on "2"
exclusive functions.

Hannes

Re: [Vimprobable-users] Features for next version

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

On 15/08/11 at 08:13am, Hannes Schüller wrote:
> Jason Ryan <jas...@gm...> wrote:
> > > On a related note, there is the question of version numbering.
> > > Should we have:
> > > - Vimprobable1 1.0 and Vimprobable2 1.0 or
> > > - Vimprobable 1.0 and Vimprobable 2.0?  
> > 
> > The former: the latter makes Vimprobable 2.0 sound like the later
> > release of Vimprobable 1.0
> 
> Well, it *is*, isn't it? It's a branch of the original code with stuff
> added to it.
> 
Ah, I hadn't grasped the nature of the relationship: I thought they were
developed in parallel.

-- 

http://jasonwryan.com/

Re: [Vimprobable-users] Features for next version

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

Jason Ryan <jas...@gm...> wrote:
> > On a related note, there is the question of version numbering.
> > Should we have:
> > - Vimprobable1 1.0 and Vimprobable2 1.0 or
> > - Vimprobable 1.0 and Vimprobable 2.0?  
> 
> The former: the latter makes Vimprobable 2.0 sound like the later
> release of Vimprobable 1.0

Well, it *is*, isn't it? It's a branch of the original code with stuff
added to it.

Hannes

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

Hi!

This patch doesn't resolve the problem and should not be applied. I disables
hinting in all frames.

Is there anybody how knows how to test if a frame has same protocol, host and
port, without accessing this properties on the frame, whate raises the error?

> ---
>  hinting.js |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/hinting.js b/hinting.js
> index 2b981e8..c106654 100644
> --- a/hinting.js
> +++ b/hinting.js
> @@ -22,6 +22,9 @@ function Hints() {
>          hints = [];
>  
>          function helper (win, offsetX, offsetY) {
> +            if (topwin.location !== win.location) {
> +                return;
> +            }
>              var doc = win.document;
>  
>              var win_height = win.height;
> -- 

Daniel

Re: [Vimprobable-users] Features for next version

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

Hi!

I have some feature from pentadactyl that I would like to have already in
vimprobable. The possibility to hit CTRL-I within a textarea to open a
configurable editor with the contents from the textarea. On Save the new
content will be transfered back into textarea. Yes, I can do this handy, but
in this way it's much faster.

For the future we could also think about a simple help system that allows the
user to open helppages on :help.

Daniel

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

On Sun, Aug 14, 2011 at 11:23:04AM +0200, Hannes Schüller wrote:
> - Using the patch, I get the following message on the console: "@1:
>   Unsafe JavaScript attempt to access frame with URL
>   http://... from frame with URL http://... Domains, protocols and
>   ports must match."
I added alitte check to prevent these messages. This is only a quick fix until
we find a soution to access the also to make it hintable.

Daniel

Re: [Vimprobable-users] Features for next version

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

Hi!

Daniel Carl <dan...@gm...> wrote:
> On Sat, Aug 13, 2011 at 09:14:25PM +0200, Hannes Schüller wrote:
> > As announced already, I would put the version 1 branch into
> > bug-fixing mode. The question is: Should we do the same for the
> > version 2 branch and make future development on a completely new
> > one?
>
> I'm not even sure if it's a good idea to separate vimprobable1 and
> vimprobable2 into different branches. It make the maintaining a
> little easier, but I think to apply bugfixex also to the version 1
> could be forgotten. I'm not using version 1 and so I apply patches
> only for version 2. I'm not familar with the version 1, but could we
> use precompiler flags to let the user decide which version to
> compile, or would this make the sources to complicate to understand?

For once, yes, it would increase source code complexity, yes.
Concerning bugfixes, the opposite of what you assume is the case I'd
say: different branches make more work.

> > On a related note, there is the question of version numbering.
> > Should we have:
> > - Vimprobable1 1.0 and Vimprobable2 1.0 or
> > - Vimprobable 1.0 and Vimprobable 2.0?
>
> Could we abandon the deviding of version 1 and 2 and have only one
> flexible to compile vimprobable? Vimprobable1 could be a vimprobable
> compiled with tiny option, vimprobable2 compiled with the huge
> option, or so.

See above, this would still increase code complexity, making it much
less readable, less reliable, more prone to errors and race conditions
etc.

Hannes

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

Daniel Carl <dan...@gm...> wrote:
> > - The patches you posted don't apply cleanly on top of each other.
> > This is due to whitespace breakage.  
>
> Oh sorry, I think I have meessed up something with my local branches.
> Could you merge it into your local branch? Should I try to make the
> pathces again to be applied on current HEAD?

I could apply them with some minor manual work, don't worry :)

Hannes

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

Hi Hannes!

> - The patches you posted don't apply cleanly on top of each other. This
>   is due to whitespace breakage.
Oh sorry, I think I have meessed up something with my local branches. Could
you merge it into your local branch? Should I try to make the pathces again to
be applied on current HEAD?

> - Using the patch, I get the following message on the console: "@1:
>   Unsafe JavaScript attempt to access frame with URL
>   http://... from frame with URL http://... Domains, protocols and
>   ports must match."
I'm not shure how to deal with it. It's a violation of the same origin policy,
that takes affect here. At the moment I found no solution to avoid the
messages, maybe a try catch at the right position will prevent it to appear.
In the current version we wouldn't be able to access frames that aren't in the
same origin policy like the page into which we insert the hinting.js.
The pentadactyl plugin for firefox can handle also frame from other domains,
so I promise we could do it also.

Daniel

Re: [Vimprobable-users] Features for next version

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

Hi!

On Sat, Aug 13, 2011 at 09:14:25PM +0200, Hannes Schüller wrote:
> As mentioned in previous discussions, I don't care at all about that -
> simply because I don't have Flash installed, so I don't need to block
> it.
The blocking of flash wasn't the point of interest. It was only an example for
running JavaScript from user for every Pageload.

> It seems to be a popular request, though. If it is done, my only
> request is that it should actually *block* these elements, not just
> *hide* them.
If I read the script right the flash is blocked.

> As announced already, I would put the version 1 branch into bug-fixing
> mode. The question is: Should we do the same for the version 2 branch
> and make future development on a completely new one?
I'm not even sure if it's a good idea to separate vimprobable1 and
vimprobable2 into different branches. It make the maintaining a little easier,
but I think to apply bugfixex also to the version 1 could be forgotten. I'm
not using version 1 and so I apply patches only for version 2. I'm not familar
with the version 1, but could we use precompiler flags to let the user decide
which version to compile, or would this make the sources to complicate to
understand?

> The reason I'm proposing this is this: Adding more and more features
> obviously makes the browser more 'fat' gradually. This might go too far
> for some people. Continuing development on the same branch would mix up
> bugfixes and new features, making it "all or nothing" for the users:
> If they want bugfixes, they also have to take the new features they
> probably don't even want. On the other hand, starting new branches
> regularly allows people to either go on following the bleeding edge
> development or sticking to a trusted, feature-frozen, but nevertheless
> maintained version.
Maybe we can follow the vim, that allows the user to compile in different fat
versions or to enable/disable every single feature by hand. So we don't have
to apply bugfixes on several branches.

> On a related note, there is the question of version numbering. Should
> we have:
> - Vimprobable1 1.0 and Vimprobable2 1.0 or
> - Vimprobable 1.0 and Vimprobable 2.0?
Could we abandon the deviding of version 1 and 2 and have only one flexible to
compile vimprobable? Vimprobable1 could be a vimprobable compiled with tiny
option, vimprobable2 compiled with the huge option, or so.

Daniel

Re: [Vimprobable-users] Features for next version

[Matto F. <ma...@ma...>]

Hi,

On Sat, Aug 13, 2011 at 06:43:45PM +0200, Daniel Carl wrote:
 
> 1) On the project site of uzbl I found a nice JavaScript that can block
>    loading of flash objects and load them on mouse click
>    (http://www.uzbl.org/wiki/flashblock). But at the time we have no
>    possibility to load user specified scripts if a page was opened. I think it
>    could be a nice feature to implemented something like the style.css for
>    user scripts 'script.js' and a configuration variable to allow/disallow the
>    loading of the script file. Is this an over bloated feature or would it be
>    a nice to have for someone else too?

I am not a fan of flash and in the day-to-day use of Vimprobable I have never
run into the need of something like this. But I wouldn't vote against it if
it doesn't require much resources.

> 2) Often I find myself searching for something interesting via a searchengine
>    and opening several results into new browser windows, to read them later.

[ ... ]

>    to show the entries of the list and to select a URL from it to open. The
>    URL list could prevent users from open many pages only for the reason to
>    mark them for reading later.

What I have been thinking about is a efficient way to shoot the current URL
into an external script. Whatever that script does, is up to the user.
Perhaps this is a more generic approach, that would allow for something you 
want but also allow users to come up with much more usefull things.

OTOH, I do this now with the usage of the windowmanager. I do a yank of
the current URL into the copy-and-paste buffer, and let ratpoison do the 
work (with "get-selection"). So if this could be done from within 
ratpoison, perhaps it could also be done from within other 
windowmanagers ...

Cheers,

Matto

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

Hi,

first review:

- The patches you posted don't apply cleanly on top of each other. This
  is due to whitespace breakage.

- Talking of whitespace breakage, the first patch seems to be
  especially messy in this regard. Some parts of the code are hardly
  readable after applying it.

- From a functional point of view, I like this very much! As you
  already said, we will probably have to find a way to preserve the
  target information (I see your point about relocating this logic
  into Javascript now). The way it is now is already very useful,
  though.

- Using the patch, I get the following message on the console: "@1:
  Unsafe JavaScript attempt to access frame with URL
  http://... from frame with URL http://... Domains, protocols and
  ports must match."

Hannes

Re: [Vimprobable-users] Features for next version

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/08/11 07:14, Hannes Schüller wrote:
> 
> As announced already, I would put the version 1 branch into bug-fixing
> mode. The question is: Should we do the same for the version 2 branch
> and make future development on a completely new one?
> 
> The reason I'm proposing this is this: Adding more and more features
> obviously makes the browser more 'fat' gradually. This might go too far
> for some people. Continuing development on the same branch would mix up
> bugfixes and new features, making it "all or nothing" for the users:
> If they want bugfixes, they also have to take the new features they
> probably don't even want. On the other hand, starting new branches
> regularly allows people to either go on following the bleeding edge
> development or sticking to a trusted, feature-frozen, but nevertheless
> maintained version.

I would favour this approach: allowing those who wish to continue to use
the more minimal browser to do so, and giving those who want to access
the more featureful version that choice.
> 
> On a related note, there is the question of version numbering. Should
> we have:
> - Vimprobable1 1.0 and Vimprobable2 1.0 or
> - Vimprobable 1.0 and Vimprobable 2.0?

The former: the latter makes Vimprobable 2.0 sound like the later
release of Vimprobable 1.0

Cheers,

/J


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJORtUIAAoJEEReUuqxvU5ARgsIALrwxvkWfi95dbQvdj/r/ktl
iMJX1C9m5i+XPUhDcJWE0oW2WEO/1ivGXx0T7bKNeOc174mp8t29e1bfHP3A2xvc
KfhQlBxdRPyBYsgrhfgghl6NSovljyX0F+FGfWCTSbp8El66A/e7anAED7ZHwO2X
MziiFf4YRSmrd2QylQ2T6kr6xLL6bhbfX0KCVKYu+nV/yGsphiQiGwhn19A96PvI
CAbHJVeyaDNLsNYcBu26qun++spcrbLY4JhGSs/kHfqtMHU0D/p7lJp2R+Tm/9Kt
jQUCJkkO0Ba17viOPSrA3heDhJkxhE7LJvDjs3JiHVPF1KiXtrqi0Lv6XvinfKI=
=4oW8
-----END PGP SIGNATURE-----

Re: [Vimprobable-users] Features for next version

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

Hi!

Daniel Carl <dan...@gm...> wrote:
> 1) (http://www.uzbl.org/wiki/flashblock)

As mentioned in previous discussions, I don't care at all about that -
simply because I don't have Flash installed, so I don't need to block
it. It seems to be a popular request, though. If it is done, my only
request is that it should actually *block* these elements, not just
*hide* them.

> 2) to have the ability to yank URLs into a list and to open them
> later - something like the 'u' command to open last closed page or
> the 'p' or 'P' command to load URL from clipboard.

This is an excellent idea and it should be very easy to implement. If
we get the future hinting policy straightened out, it could even be
possible to squeeze this into the 1.0 release.

Since we're planning, I'd like to bring up one very general point: the
future release/version number policy.

As announced already, I would put the version 1 branch into bug-fixing
mode. The question is: Should we do the same for the version 2 branch
and make future development on a completely new one?

The reason I'm proposing this is this: Adding more and more features
obviously makes the browser more 'fat' gradually. This might go too far
for some people. Continuing development on the same branch would mix up
bugfixes and new features, making it "all or nothing" for the users:
If they want bugfixes, they also have to take the new features they
probably don't even want. On the other hand, starting new branches
regularly allows people to either go on following the bleeding edge
development or sticking to a trusted, feature-frozen, but nevertheless
maintained version.

On a related note, there is the question of version numbering. Should
we have:
- Vimprobable1 1.0 and Vimprobable2 1.0 or
- Vimprobable 1.0 and Vimprobable 2.0?

What does everybody think?

Hannes

Re: [Vimprobable-users] Features for next version

[Serge E. H. <se...@ha...>]

Quoting Daniel Carl (dan...@gm...):
> Hi!
> 
> Cause of the forthcoming release of the version 1.0 I took advantage of the
> 2) Often I find myself searching for something interesting via a searchengine
>    and opening several results into new browser windows, to read them later.
>    Maybe I could configure my windowmanager to open the new windows in the
>    Background, to keep on searchengine's result page until I've opened all the
>    pages I considered as interesting. But I believe it would be a very
>    interesting feature, to have the ability to yank URLs into a list and to
>    open them later - something like the 'u' command to open last closed page
>    or the 'p' or 'P' command to load URL from clipboard.

I like it!  Kind of like readitlater.  For extra points, a third hint follow
option (not sure which keystroke) which just moves the chosen link right
into that list without ever opening it.  'Q<followed by f-like hinting>'
maybe?

-serge

[Vimprobable-users] Features for next version

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

Hi!

Cause of the forthcoming release of the version 1.0 I took advantage of the
situation to ask if there is a roadmap of features to implement for version
1.1 or 1.0.1. If there isn't such a roadmap, maybe we can discuss it here.

Features I want to see implemented:

1) On the project site of uzbl I found a nice JavaScript that can block
   loading of flash objects and load them on mouse click
   (http://www.uzbl.org/wiki/flashblock). But at the time we have no
   possibility to load user specified scripts if a page was opened. I think it
   could be a nice feature to implemented something like the style.css for
   user scripts 'script.js' and a configuration variable to allow/disallow the
   loading of the script file. Is this an over bloated feature or would it be
   a nice to have for someone else too?

2) Often I find myself searching for something interesting via a searchengine
   and opening several results into new browser windows, to read them later.
   Maybe I could configure my windowmanager to open the new windows in the
   Background, to keep on searchengine's result page until I've opened all the
   pages I considered as interesting. But I believe it would be a very
   interesting feature, to have the ability to yank URLs into a list and to
   open them later - something like the 'u' command to open last closed page
   or the 'p' or 'P' command to load URL from clipboard.

   I think we could use a file to yank the URLs into it and have a command to
   open the first URL from it and pop it from the list. After reading the page
   or some related page the command can open the next short time bookmarked
   page. We could use a lowercase letter command to open the next URL from
   list into current window and the uppercase one, to open it into a new
   vimprobable instance. An additional command like :open could be implemented
   to show the entries of the list and to select a URL from it to open. The
   URL list could prevent users from open many pages only for the reason to
   mark them for reading later.

Daniel

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

Hi Hannes,

I know that the patches are really cruel, have to many changes at the time,
so it's not remarkable that you loose the overview. The patches should be
applied on top of the previous one.

To get the history of the stashed patch, you can have a look at the branch
on github https://github.com/fanglingsu/vimprobable/commits/fls/hinting-refacture.

Daniel
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: [Vimprobable-users] [PATCH] Refactured hinting

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

Hi!

Daniel Carl <dan...@gm...> wrote:
> Therefor I started to
> refacture the hinting.js to deal with hinting also on framebased
> pages. 

This sounds marvelous and I have to dig into this subject in detail
this weekend! For now, just one question as I'm slowly losing overview:
Are these patches replacements of your previous patch, are they on top
of it or something completely unrelated?

Hannes