I agree with the points being made, and I struggled with many of the same
problems before. I pushed through mostly by reading the code in Yi, and
using a ghci a lot to look up functions.
Here are some specific documentation and organisational problems which have
caused me grief, even now that I am
Done!
https://github.com/yi-editor/yi/commit/f856b6dab06f2f1e2a4958a64aa63a27d7b20dcf
Cheers,
Reiner
On 18/07/11 17:37, Reiner Pope wrote:
Okay, going against what I said before, I decided to fix up some
things in yi which have been niggling me, and I've just committed a
few small chang
Pango
configurable) and then I'll be happy with a Hackage release. This time I
mean it :P.
Cheers,
Reiner
On 17/07/11 21:13, Reiner Pope wrote:
I don't see a reason to wait for any of the things I'm working on, so
I'd be happy with a Hackage release.
Cheers,
Reiner
On 17/0
I don't see a reason to wait for any of the things I'm working on, so
I'd be happy with a Hackage release.
Cheers,
Reiner
On 17/07/11 15:59, Jeff Wheeler wrote:
Hey all,
I was thinking about another release soon. Reiner, especially, has
done lots of cool stuff since the last one.
Sound good?
On 27/06/11 07:26, Jean-Philippe Bernardy wrote:
On Sun, Jun 26, 2011 at 5:34 PM, Reiner Pope wrote:
On a similar note, would it be acceptable to join the 'hlRun' and 'hlFocus'
fields. Currently they are:
hlRun :: Scanner Point Char -> Point -> cache -> ca
ser should have access to both the visible
regions and the underlying text when parsing.
Cheers,
Reiner
On 27/06/11 00:18, Reiner Pope wrote:
Hi,
I was looking at the Highlighter data type in Yi.Syntax, and I'm
wondering about this:
data Highlighter cache syntax = SynHL {
...
Hi,
I was looking at the Highlighter data type in Yi.Syntax, and I'm
wondering about this:
data Highlighter cache syntax = SynHL {
...
hlRun :: Scanner Point Char -> Point -> cache -> cache,
...
}
What does this achieve over the following?
...
hlRun :: Rope -> Point -> cache
On 10/06/11 01:22, Corey O'Connor wrote:
On Tue, Jun 7, 2011 at 11:10 PM, Reiner Pope wrote:
Right, fair enough. However, suppose I want a different hierarchy. For
instance, I don't use multiple tabs, and I don't currently want nested
activity groups, so I might want:
Edi
On 08/06/11 14:39, Corey O'Connor wrote:
On Tue, Jun 7, 2011 at 7:41 PM, Reiner Pope wrote:
I'm not convinced that adding activity groups to the hierarchy is a good
idea. In my opinion, *all* window/view layout should be handled by a
'LayoutManager' object -- primarily for
Hi,
This is very interesting. I'm excited to see layout support in the vty
front-end.
---
I'm not convinced that adding activity groups to the hierarchy is a good
idea. In my opinion, *all* window/view layout should be handled by a
'LayoutManager' object -- primarily for simplicity, but als
On 21/05/11 06:56, Jean-Philippe Bernardy wrote:
I have casually looked through the code and I saw nothing against it.
As for the technique, I have to say it's a clever trick :). I normally would
have opposition of principle against unsafePerformIO, but you could argue
that serializable dynamics
Hi all,
I've written a patch which I would like reviewed before pushing.
You can view the changes at [1]. The patch is a rewrite of the
Yi.Dynamic module to support serialisation on Dynamics (which means that
things like minibuffer history are preserved across 'reloadConfigE').
The module Yi.
On 14/05/11 18:24, Reiner Pope wrote:
On 14/05/11 17:40, Nicolas Pouillard wrote:
On Sat, 14 May 2011 15:06:51 +1000, Reiner
Pope wrote:
Hi all,
Is there a policy for strictness of datatypes in Yi, and what is it?
Specifically:
1. When I write a datatype, which fields should I make
On 14/05/11 17:40, Nicolas Pouillard wrote:
On Sat, 14 May 2011 15:06:51 +1000, Reiner Pope wrote:
Hi all,
Is there a policy for strictness of datatypes in Yi, and what is it?
Specifically:
1. When I write a datatype, which fields should I make strict? For
instance, all fields in
On 14/05/11 17:42, Jean-Philippe Bernardy wrote:
On Sat, May 14, 2011 at 7:06 AM, Reiner Pope wrote:
What should I do to ensure strictness of lazy datatypes like [a]? For
instance, the 'bufAccessList :: ![BufferRef]' field of 'Window' is marked
strict, but is a list. Is it
Whoops, I missed your other reply. Never mind this!
Reiner
On 14/05/11 17:46, Reiner Pope wrote:
Ok, understood.
My question is, how do we enforce this? So:
* some fields of Window are nonstrict. Is this just a mistake?
* strictness annotations on (lazy) lists aren't suffi
re anyway).
Hope this helps!
Cheers,
JP.
On Sat, May 14, 2011 at 7:06 AM, Reiner Pope wrote:
Hi all,
Is there a policy for strictness of datatypes in Yi, and what is it?
Specifically:
When I write a datatype, which fields should I make strict? For instance,
all fields in Editor are strict, a
Hi all,
Is there a policy for strictness of datatypes in Yi, and what is it?
Specifically:
1. When I write a datatype, which fields should I make strict? For
instance, all fields in Editor are strict, and all fields except
'height' and 'winRegion' in Window are strict. Is there som
On 11/05/11 23:45, Jean-Philippe Bernardy wrote:
On Wed, May 11, 2011 at 3:11 PM, Reiner Pope wrote:
On 11/05/11 17:27, Jean-Philippe Bernardy wrote:
Rather than adding a new window type, It would be a lot easier to
1. Change the layout algorithm to put mini windows at the bottom
2
On 11/05/11 17:27, Jean-Philippe Bernardy wrote:
Rather than adding a new window type, It would be a lot easier to
1. Change the layout algorithm to put mini windows at the bottom
2. Creation of a miniwindow if one already exists.
I'm not sure I understand your second point.
Regarding the fir
Hi all,
(Longish email ahead.)
I'm currently working on making the layout of yi windows more flexible
by the user (see Issue 348). Among other things, I would like to have my
windows side-by-side as well as stacked on top of each other. My basic
design has been to add a layout manager to the
21 matches
Mail list logo
