On Wed, Sep 24, 2014 at 10:58:11PM +0200, Silvan Jegen wrote:
> On Wed, Sep 24, 2014 at 09:36:12PM +0200, Marc André Tanner wrote:
> > On Wed, Sep 24, 2014 at 06:12:30PM +0200, Silvan Jegen wrote:
> > > On Tue, Sep 23, 2014 at 08:03:45PM +0200, ale rimoldi wrote:
> > > [...]
> > >
> > > - 'J' in vi
> > vis now supports ':set tabwidth 4' and ':set expandtab true'.
>
> ":set expandtab 1" works correctly
>
> ":set tabwidth 4" set the width of the tab but i always get 8 spaces
> when expandtab is enabled
>
> i've checked in the code, and the set is writing the value in window
> and get reading
On 24 Sep 2014, wrote:
On Wed, Sep 24, 2014, at 15:36, Marc Andr=C3=A9 Tanner wrote:
> > - 'J' in visual mode is not implemented
>
> Why would one use it?
To be able to select lines to be joined interactively instead of having
to count the lines by hand (since there's no J, only
J). I do this
I think "Vim" sucks for this reason:
https://groups.google.com/forum/#!searchin/vim_dev/Ruby$20abort$20vim$20marc/vim_dev/irITPpKnTP8/Osl0AHJUH60J
(scroll down to fun! Dummy() )
for i in range(0, 2000)
end for
can be interrupted by a resize event and start running other code - and
you don't have
On Thu, Sep 25, 2014, at 08:57, Raphaël Proust wrote:
> I actually have my vimrc setting K as an upward J (i.e., join current
> line with the previous one) (although I haven't made the effort to
> make it work in visual mode because then I just use J):
> nnoremap K :.-,.join
Why not just map it t
On Thu, Sep 25, 2014 at 1:43 PM, Marc André Tanner wrote:
> On Wed, Sep 24, 2014 at 05:33:49PM -0400, random...@fastmail.us wrote:
>> On Wed, Sep 24, 2014, at 15:36, Marc André Tanner wrote:
>> > > - 'J' in visual mode is not implemented
>> >
>> > Why would one use it?
>>
>> To be able to select l
On Wed, Sep 24, 2014 at 05:33:49PM -0400, random...@fastmail.us wrote:
> On Wed, Sep 24, 2014, at 15:36, Marc André Tanner wrote:
> > > - 'J' in visual mode is not implemented
> >
> > Why would one use it?
>
> To be able to select lines to be joined interactively instead of having
> to count the
On Wed, Sep 24, 2014 at 05:20:44PM -0400, random...@fastmail.us wrote:
> On Wed, Sep 24, 2014, at 15:21, Marc André Tanner wrote:
> > > x should not delete the end of line character (but this might be solved
> > > with the placement issue above)
> >
> > I (and a few others? Christian Neukirchen?)
hi marc andré
thank you very much for your reply and for implementing so many of the
features i've mentioned!
being still in digest modus and since i'm not getting the mails from
the archive it's a bit of a pain to reply...
> While this is true to some degree, I still think that it can be
> impl
On Wed, Sep 24, 2014, at 15:36, Marc André Tanner wrote:
> > - 'J' in visual mode is not implemented
>
> Why would one use it?
To be able to select lines to be joined interactively instead of having
to count the lines by hand (since there's no J, only
J). I do this all the time.
On Wed, Sep 24, 2014, at 15:21, Marc André Tanner wrote:
> > x should not delete the end of line character (but this might be solved
> > with the placement issue above)
>
> I (and a few others? Christian Neukirchen?) actually like the fact that
> the newline is treated like a normal character.
On Wed, Sep 24, 2014 at 09:36:12PM +0200, Marc André Tanner wrote:
> On Wed, Sep 24, 2014 at 06:12:30PM +0200, Silvan Jegen wrote:
> > On Tue, Sep 23, 2014 at 08:03:45PM +0200, ale rimoldi wrote:
> > [...]
> >
> > - 'J' in visual mode is not implemented
>
> Why would one use it?
I use it to join
On Wed, Sep 24, 2014 at 04:05:46PM -0400, Wolfgang Corcoran-Mathe wrote:
> Quoth Marc André Tanner on Wed, Sep 24 2014 21:21 +0200:
> >>o O should go into insert mode after adding the line
> >>a appends at the current cursor place
> >
> >Fixed
>
> Marc,
>
> Thanks very much for your tremendous wo
> > automatically insert the comment sign at the beginning of the next line
>
> How does this work in vim?
Based on 'textwidth', lines are wrapped automatically to the next line
as you type. If the lines start with a comment leader like '#', the
leader is copied into the next line along with whit
Quoth Marc André Tanner on Wed, Sep 24 2014 21:21 +0200:
o O should go into insert mode after adding the line
a appends at the current cursor place
Fixed
Marc,
Thanks very much for your tremendous work on vis.
As currently implemented, o moves the last non-newline character of
the current l
On Wed, Sep 24, 2014 at 06:12:30PM +0200, Silvan Jegen wrote:
> On Tue, Sep 23, 2014 at 08:03:45PM +0200, ale rimoldi wrote:
> > - o does not go into insert mode (how easy it is to switch my habits to oi?)
> > - a does not append
> > - end of line is not the last char in the line but the end of lin
> I'd like to draw attention to plover steno knight as well.
Link in case someone else is curious: http://openstenoproject.org
Fascinating, thanks.
Kartik
http://akkartik.name/about
I'd like to draw attention to plover steno knight as well.
Maybe changing the input system alltogether could provide more value
than writing yet another editor ? I'm unsure.
Marc Weber
On Tue, Sep 23, 2014 at 08:03:45PM +0200, ale rimoldi wrote:
> hi marc andré
>
> as announced a few days ago, here is my write down about vis.
Thank you! This is very useful.
> you probably won't agree with each point in there...
Yes, see the inline comments.
> for many years now, i've been us
On Tue, Sep 23, 2014 at 08:03:45PM +0200, ale rimoldi wrote:
> - o does not go into insert mode (how easy it is to switch my habits to oi?)
> - a does not append
> - end of line is not the last char in the line but the end of line character
> - P does not paste before
>
> and here the only real bu
On 09/19/14 15:20, Raphaël Proust wrote:
> I think this design is simpler: editors to edit
> text, they talk to a server about line numbers and character offsets,
> the server understands these positions as meaningful code entities.
>
I definitely agree on this point ! Better to have language-rel
On Wed, Sep 24, 2014 at 10:50 AM, Marc Weber wrote:
> Rewriting an editor? Have a a look at existing solutions
You forgot to mention the historic example for a group of people that
aimed at everything DIY and got stuck with an over-bloated text editor
which some people jokingly call "a great OS b
Excerpts from ale rimoldi's message of Tue Sep 23 18:03:45 + 2014:
> on top of that, while i never had a look at the vim source code, i've
> read scaring tales about it.
Some cases where the vim source code appears very hacky to me:
http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-s
On Tue, Sep 23, 2014 at 7:03 PM, ale rimoldi wrote:
> :paste :nopaste modes (if the commands above are implemented)
By the way, if you use st you can have paste/nopaste switch
automatically. See
https://github.com/raphael-proust/rcs/blob/master/home/user/.vimrc#L218
for details.
> […]
I agree
hi marc andré
as announced a few days ago, here is my write down about vis.
you probably won't agree with each point in there...
for many years now, i've been using vim as my main text editor. both for code
and for typing text.
while i consider myself a vim heavy user, when i browse through
Hello,
On Fri, Sep 19, 2014 at 03:13:28PM +0100, Raphaël Proust wrote:
> On Fri, Sep 19, 2014 at 2:22 PM, Maxime Coste wrote:
> > […]
> > That was one of the motivations for swapping selection and operation order
> > in
> > Kakoune (haters gonna hate...), by decoupling selections from the operat
On Fri, Sep 19, 2014 at 2:22 PM, Maxime Coste wrote:
> […]
> That was one of the motivations for swapping selection and operation order in
> Kakoune (haters gonna hate...), by decoupling selections from the operator,
> you
> can express arbitrarily complex selection operations, you have a (rather
Hello
On Fri, Sep 19, 2014 at 02:45:37PM +0200, Hugues Evrard wrote:
> === TL;DR ===
> - editing command could use abstractions that are independent from the
>actual source code syntax
> - e.g., say "comment this line" rather than "add at the
>beginning of the line"
> - pro: offer unif
On Fri, Sep 19, 2014 at 1:45 PM, Hugues Evrard wrote:
> […]
> However, such abstractions require the editor to know the structure of
> language being edited. If this means having a parser for each language
> under edition, then I think it's better to not have such abstractions.
> Still, the inform
> Let me give an example:
> - we want to comment a block of code
> - we edit C-like code, i.e.:
>- let's say a block of code is defined by text between the next "{"
> and its matching "}"
>- comment means add "//" at the beginning of the line
>
> To realize this on "level 2" commands
Hi all,
On 09/17/14 22:12, ale rimoldi wrote:
>
>> Could some vim expert on the list tell me whether it is possible to
>> indent the next n lines by m levels in vim?
>
> the simplest one already works in vis. indent n lines (or better a
> "{" inner area) and repeat the action with dots (eventually
On Wed, Sep 17, 2014 at 10:12:46PM +0200, ale rimoldi wrote:
> hi marc andré,
>
> first thanks for your fine vis... i spent about an hour trying it out,
> while taking notes on what i'm missing...
Please share your findings.
> it misses too many features i use in my everyday work with vim, but i
On 9/17/14, 3:51 PM, Teodoro Santoni wrote:
> Welp, you made it, i'm hooking the bait. You're putting the editor out every
> single goddamn time someone discusses about text editors:
So... twice?
> > That goes back to the linked list/array thing, you dont have generics, so
> > you use the
> > easy thing without generics: linked lists, which are almost always a poor
> > choice.
Writing a polymorph array in c is less of 10 lines. Any decent
programmer should be able of coding it. can not y
Ok, this is going to be my last mail in this discussion
(we have a sentence for this in spanish: don't try to teach
play flute to a donkey, because first you waste your
time, and second you disturb the donkey).
> > If you want detect this kind of errors you can apply another techniques,
> > but no
hi marc andré,
first thanks for your fine vis... i spent about an hour trying it out,
while taking notes on what i'm missing...
it misses too many features i use in my everyday work with vim, but it
was a positive experience.
i'll probably send my comments very soon...
> Could some vim expert
On Wed, Sep 17, 2014 at 07:42:47PM +0100, Maxime Coste wrote:
>
> Seriously, there are a lot of bad design
> decision in Windows, as there a are a lot in modern linux userland, and
> they do not seems to stem from the implementation language.
When you pull in .NET and don't rewrite the code from
On Wed, Sep 17, 2014 at 09:40:44PM +0200, q...@c9x.me wrote:
> On Wed, Sep 17, 2014 at 07:42:47PM +0100, Maxime Coste wrote:
> > > That doesn???t happen that often to justify overloading. Hint: Avoided
> > > complexity in the system *beforehand*.
> >
> > That goes back to the linked list/array
On Wed, Sep 17, 2014 at 07:42:47PM +0100, Maxime Coste wrote:
> > That doesn???t happen that often to justify overloading. Hint: Avoided
> > complexity in the system *beforehand*.
>
> That goes back to the linked list/array thing, you dont have generics, so you
> use the
> easy thing without
On Wed, Sep 17, 2014 at 06:29:01AM +0200, Christoph Lohmann wrote:
> On Wed, 17 Sep 2014 06:29:01 +0200 Maxime Coste wrote:
> > On Tue, Sep 16, 2014 at 11:02:40PM +0200, Christoph Lohmann wrote:
> > > This is programming and not your playground. Avoid fancy code.
> >
> > I guess that is a matter
On Wed, Sep 17, 2014 at 01:33:19PM +0200, FRIGN wrote:
> On Wed, 17 Sep 2014 15:22:34 +0400
> "Alexander S." wrote:
>
> Hey Alexander,
>
> > furthermore, syntactic sugar and an ability to write e. g.
> > win.repaint(rect) instead of window_repaint_rectangle(win, &rect)
> > actually *increases* t
On Wed, Sep 17, 2014 at 07:15:51PM +0100, Maxime Coste wrote:
> Oh boy, you don't know much about C++ do you, of course a char* is
That's a blessing right? :)
On Wed, Sep 17, 2014 at 05:05:33PM +0200, Roberto E. Vargas Caballero wrote:
> Yes, but I don't agree the type system must be used for this kind of
> errors. What happens if you mix variables about count of lines of
> different buffers? The type system will not detect anything, and
> if you go ahea
On Wed, Sep 17, 2014 at 04:56:59PM +0200, Marc André Tanner wrote:
> > Operators
> > -
> >planned: > (shift-right), < (shift-left)
>
> Those are now also (at least in a rudimentary way) implemented.
>
> Could some vim expert on the list tell me whether it is possible to
> indent th
I like javascript, and I would love to see more Javascript in
suckless software.
In JavaScript I can abuse the lack of a typesystem, and can
build functions that return configurable, callable
objects, returning other objects for which is given what data they
will hold and what functions they will
> > If you want to use the type
> > system to ensure the correctness of your code, instead of writing
> > good code then you have an understanding problem about programming.
> That's an odd thing to hear from a professional like you. Making
> mistakes isn't about "writing good code" (what does this
> Operators
> -
>planned: > (shift-right), < (shift-left)
Those are now also (at least in a rudimentary way) implemented.
Could some vim expert on the list tell me whether it is possible to
indent the next n lines by m levels in vim?
All combinations I tried like: n>mj simply inde
On 09/17/2014 06:22 AM, Alexander S. wrote:
Oh, another C vs C++ holy crusade, it seems.
As a participant. I hope it can remain a reasonably rational, reasonably
fact based conversation even if it is a passionate one.
The reason I engaged the discussion is that I don't like reading
argument
On Wed, 17 Sep 2014 15:22:34 +0400
"Alexander S." wrote:
Hey Alexander,
> furthermore, syntactic sugar and an ability to write e. g.
> win.repaint(rect) instead of window_repaint_rectangle(win, &rect)
> actually *increases* the readability of code when you have to deal
> with several lines of th
Oh, another C vs C++ holy crusade, it seems.
I'd like to note here that while object-oriented progamming can be
done in C, doing polymorphism, for example, is a pain in the ass;
furthermore, syntactic sugar and an ability to write e. g.
win.repaint(rect) instead of window_repaint_rectangle(win, &re
On Wed, 17 Sep 2014 00:03:55 +0100
Maxime Coste wrote:
> Ok, so on a modern processor, data access pattern matters, with your linked
> list,
> you basically have a cache miss at each access to the next element when you
> iterate,
> when you use an array, you get linear access in memory, which m
On Wed, 17 Sep 2014 07:41:50 +0100
Ralph Eastwood wrote:
> Apologies, I need a better mail client.
Try sylpheed or mutt.
--
FRIGN
> > Can you explain me why in C you have to represent them as int or long as
> > not with a structure like you did in c++?.
>
> Because I want the convenience of adding two byte counts using +, which I can
> do in C++, and have that compile down to exactly the same assembly as if I
> used ints,
>
Apologies, I need a better mail client.
On 17 September 2014 07:39, Ralph Eastwood wrote:
> Maxime Coste wrote:
>> That last one is by far the most interesting, Bartos being very familliar
>> with
>> C++. Note that its not C that is advocated, but haskell...
>
> I would advocate functional langu
Maxime Coste wrote:
> That last one is by far the most interesting, Bartos being very familliar with
> C++. Note that its not C that is advocated, but haskell...
I would advocate functional languages (not necessarily Haskell) over C++ any day
- although implementations of functional languages hav
Maxime Coste wrote:
> That is the complaint I mostly hear about Go, the lack of Generic. That and
> garbage collection.
Why would I want to apply the same algorithm to semantically different
arguments? Appart from different kinds of number representations no useful
example comes to mind.
--Markus
Greetings.
On Wed, 17 Sep 2014 06:29:01 +0200 Maxime Coste wrote:
> On Tue, Sep 16, 2014 at 11:02:40PM +0200, Christoph Lohmann wrote:
> > This is programming and not your playground. Avoid fancy code.
>
> I guess that is a matter of taste, I just know m1 + m2 calls
> operator+(Matrix, Matrix).
On Tue, Sep 16, 2014 at 12:37:44AM -0700, Markus Teich wrote:
> M Farkas-Dyck wrote:
> > [1] http://harmful.cat-v.org/software/c++/linus
> > [2] http://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/
>
> Heyho,
>
> also relevant for the (non-)topic:
> http://bartoszmilewski.com/2013/09/1
On Tue, Sep 16, 2014 at 11:02:40PM +0200, Christoph Lohmann wrote:
> > Ok, so what exactly is the sum of 3 lines and 2 bytes ? The whole point
> > is to catch at compilation code that is logically invalid, if you have
> > f(ByteCount, LineCount), you cannot call it with a (LineCount, ByteCount)
> >
On Tue, Sep 16, 2014 at 11:20:45PM +0200, Roberto E. Vargas Caballero wrote:
> > Ok, so what exactly is the sum of 3 lines and 2 bytes ? The whole point
> > is to catch at compilation code that is logically invalid, if you have
> > f(ByteCount, LineCount), you cannot call it with a (LineCount, Byte
> No. Because the realloc that you have to do maybe has to move in the
> worst case n-1 elements in a new memory arena. So you have n (moving
> to the position) * n-1 (memcpy to new position in memory) = n^2. You
> can decrease the possibility of reallocation allocating
> more memory of needed, but
> Ok, so what exactly is the sum of 3 lines and 2 bytes ? The whole point
> is to catch at compilation code that is logically invalid, if you have
> f(ByteCount, LineCount), you cannot call it with a (LineCount, ByteCount)
> signature. In C you would be forced to use f(int, int), and long debugging
On Tue, 16 Sep 2014 23:02:40 +0200
Christoph Lohmann <2...@r-36.net> wrote:
> No, civilisation ended when »C++« was mentioned. Code abstraction and
> bad design choices made from idiots relying on OOP are the reason why
> your local Windows machine is so slow in loading drivers, opening Wi
On Tue, 16 Sep 2014 21:30:47 +0100
Maxime Coste wrote:
> Ok, so what exactly is the sum of 3 lines and 2 bytes ? The whole point
> is to catch at compilation code that is logically invalid, if you have
> f(ByteCount, LineCount), you cannot call it with a (LineCount, ByteCount)
> signature. In C y
Greetings.
On Tue, 16 Sep 2014 23:02:40 +0200 Maxime Coste wrote:
> On Tue, Sep 16, 2014 at 10:02:54PM +0200, Roberto E. Vargas Caballero wrote:
> > > Well, I still rely a lot on having a proper type system to do checks at
> > > compile time. For example I have separate types for line counts, byt
On Tue, Sep 16, 2014 at 10:02:54PM +0200, Roberto E. Vargas Caballero wrote:
> > Well, I still rely a lot on having a proper type system to do checks at
> > compile time. For example I have separate types for line counts, byte
>
> Proper..., good word for saying a pain in the ass. One of the best
> Well, I still rely a lot on having a proper type system to do checks at
> compile time. For example I have separate types for line counts, byte
Proper..., good word for saying a pain in the ass. One of the best thing
of C (and C++ because they share this part) is automatic conversions
that remov
On Tue, Sep 16, 2014 at 09:13:00AM +0100, Ralph Eastwood wrote:
> Maxime, I really like what you'e done with kakoune, although your code
> base doesn't
> seem to use C++'s features heavily, meaning that your could write
> equally clean code in C.
> Why does it have to be C89? C99 is nicer.
>
>
>
On Tue, Sep 16, 2014 at 01:56:14PM +0200, Gregor Best wrote:
> Hi guys,
>
> I've got two patches and three questions:
>
> First, the patches. The first fixes editing of length 0 files,
Thanks applied with some cosmetic changes. I'm not sure the perror call makes
that much sense and since the oth
On Tue, Sep 16, 2014 at 12:19 PM, M Farkas-Dyck wrote:
> On 16/09/2014, Raphaël Proust wrote:
>> I am planning on making a filter for the sam language. I.e. something
>> like sed but that would accept sam expressions.
>
> http://swtch.com/plan9port/man/man1/ssam.html
Thanks, I didn't know about
Hi guys,
I've got two patches and three questions:
First, the patches. The first fixes editing of length 0 files, the second fixes
compilation on OpenBSD. Since _BSD_SOURCE was already present in other files
belonging to vis, I figured adding it to vis.c as well poses no harm.
The first question
On 16/09/2014, Raphaël Proust wrote:
> I am planning on making a filter for the sam language. I.e. something
> like sed but that would accept sam expressions.
http://swtch.com/plan9port/man/man1/ssam.html
On Mon, Sep 15, 2014 at 10:52 PM, Dimitris Papastamos wrote:
> A nice experimental and in-development editor is edit[0]
Really nice!
I am planning on making a filter for the sam language. I.e. something
like sed but that would accept sam expressions. That would make a
search and replace trivial
On 16 September 2014 00:23, FRIGN wrote:
>
> Some vocal individuals? I struggle to find anybody who isn't against C++.
> C++ does provide some abstraction features, yes, but every time I read
> C++ or even boost-code, my brain just shuts off and begs for C's
> simplicity and clarity.
In my opinio
M Farkas-Dyck wrote:
> [1] http://harmful.cat-v.org/software/c++/linus
> [2] http://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/
Heyho,
also relevant for the (non-)topic:
http://bartoszmilewski.com/2013/09/19/edward-chands/
--Markus
On 15/09/2014, Maxime Coste wrote:
> And for C++, well, I know there is some vocal individuals against it on the
> sl mailing list, but I think most members are sensible, we do not need to
> stay frozen with C89, C++ is bigger than C, more complex, but provides a lot
> of abstraction features that
On Tue, 16 Sep 2014 00:12:58 +0100
Maxime Coste wrote:
> Hard to resist talking about a project I spent most of my spare coding time
> on for the last 3 years.
Fair point.
> I agree 18000 is not small, but not that big either, clearly reasonable
> for the amount of things Kakoune does (and nope
Hi
On Mon, Sep 15, 2014 at 11:50:52PM +0300, Dimitris Zervas wrote:
> On September 15, 2014 6:41:29 PM EEST, q...@c9x.me wrote:
> >On Mon, Sep 15, 2014 at 02:21:25PM +0100, Maxime Coste wrote:
> >> Hello,
> >> [...]
> >> Maxime Coste.
> >
> >I like your advertisement man, keep it up :).
> >I also
On Mon, Sep 15, 2014 at 6:13 PM, Dimitris Papastamos wrote:
> On Mon, Sep 15, 2014 at 06:02:19PM -0400, Lee Fallat wrote:
>> On Mon, Sep 15, 2014 at 5:52 PM, Dimitris Papastamos wrote:
>> >> I want to code a text editor that is suckless and actually matters. If
>> >> your implementation is bette
On Mon, Sep 15, 2014 at 06:02:19PM -0400, Lee Fallat wrote:
> On Mon, Sep 15, 2014 at 5:52 PM, Dimitris Papastamos wrote:
> >> I want to code a text editor that is suckless and actually matters. If
> >> your implementation is better, we better code for your project.
> >
> > FWIW, the only reason
On Mon, Sep 15, 2014 at 5:52 PM, Dimitris Papastamos wrote:
>> I want to code a text editor that is suckless and actually matters. If your
>> implementation is better, we better code for your project.
>
> FWIW, the only reason I liked sandy was because it was not yet another
> vi clone.
>
> A nic
> I want to code a text editor that is suckless and actually matters. If your
> implementation is better, we better code for your project.
FWIW, the only reason I liked sandy was because it was not yet another
vi clone.
A nice experimental and in-development editor is edit[0]
[0] http://c9x.me/
On Mon, Sep 15, 2014 at 11:37:31PM +0300, Dimitris Zervas wrote:
> I'm not telling it "in a bad way", but your project seems (from the
comments, I haven't tried it yet) very promising and more worth coding than
sandy.
> Is that right? (question to sandy users too).
> I want to code a text editor
>I don't think so, try to edit something like this:
>
> コンニチハ
>
>or this:
>
> printf "Hello\0World" > TEST && sandy TEST
>
>or this (not recommended):
>
> seq 1000 > TEST && sandy TEST
>
>Last time I looked the vim bindings weren't that powerful, for example
>text object are not supported? As a
On September 15, 2014 6:41:29 PM EEST, q...@c9x.me wrote:
>On Mon, Sep 15, 2014 at 02:21:25PM +0100, Maxime Coste wrote:
>> Hello,
>> [...]
>> Maxime Coste.
>
>I like your advertisement man, keep it up :).
>I also like advocating for change rather than
>flavorless copy.
>
>- Q.
Yes, I agree.
I also
On 9/15/14, 3:03 PM, Marc André Tanner wrote:
> This is true to some degree. The problem is that most people are already
> familiar with vi(m) (myself included). Therefore the hope is that by sticking
> to the vim conventions more contributors will be attracted. As for my personal
> needs they are
On Mon, Sep 15, 2014 at 02:21:25PM +0100, Maxime Coste wrote:
> Hello,
>
> Here are a few thought on your design, based on my own experience with
> Kakoune.
Thanks for sharing them! Kakoune looks interesting. At some later point
I will take a closer look.
> On Sat, Sep 13, 2014 at 04:01:15PM +
On Mon, Sep 15, 2014 at 10:49:09AM +0300, Dimitris Zervas wrote:
> On September 13, 2014 5:01:15 PM EEST, "Marc André Tanner"
> wrote:
> >TLDR: I'm writing an experimental but (hopefully) highly efficient vim
> >like text editor based on a piece chain data structure. You will find
> >an url to a
On Sun, Sep 14, 2014 at 09:02:30PM -0500, M Farkas-Dyck wrote:
> On 13/09/2014, Marc André Tanner wrote:
> > The default interface is a vim clone called vis.
>
> Name clash on BSD [1][2][3]
This is somewhat unfortunate but the opportunity was too good
not to make a reference to vis[0] (due to th
On Mon, Sep 15, 2014 at 02:21:25PM +0100, Maxime Coste wrote:
> Hello,
> [...]
> Maxime Coste.
I like your advertisement man, keep it up :).
I also like advocating for change rather than
flavorless copy.
- Q.
Marc André Tanner said:
> Editor Frontends
>
>
> The editor core is written in a library like fashion which should make
> it possible to write multiple frontends with possibly different user
> interfaces/paradigms.
>
> At the moment there exists a barely functional, non-modal n
Hello,
Here are a few thought on your design, based on my own experience with Kakoune.
On Sat, Sep 13, 2014 at 04:01:15PM +0200, Marc André Tanner wrote:
> Text management using a piece table/chain
> =
>
> [...]
While this looks like a nice data structure
Dimitris Zervas on Mon, 2014/09/15 10:49:
> On September 13, 2014 5:01:15 PM EEST, "Marc André Tanner"
> wrote:
> >TLDR: I'm writing an experimental but (hopefully) highly efficient vim
> >like text editor based on a piece chain data structure. You will find
> >an url to a git repository at the
On September 13, 2014 5:01:15 PM EEST, "Marc André Tanner"
wrote:
>TLDR: I'm writing an experimental but (hopefully) highly efficient vim
>like text editor based on a piece chain data structure. You will find
>an url to a git repository at the end of this rather long mail.
Take a look at sandy [
On 13/09/2014, Marc André Tanner wrote:
> The default interface is a vim clone called vis.
Name clash on BSD [1][2][3]
[1]
https://www.freebsd.org/cgi/man.cgi?query=vis&apropos=0&sektion=0&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html
[2] http://www.openbsd.org/cgi-bin/man.cgi?query=vis
Original Message
From: Marc André Tanner
Sent: Sunday, 14 September 2014 10:43
To: Christian Hesse
Reply To: dev mail list
Cc: dev@suckless.org
Subject: Re: [dev] [RFC] Design of a vim like text editor
On Sat, Sep 13, 2014 at 11:32:44PM +0200, Christian Hesse wrote:
> Marc André Tanner
On Sat, Sep 13, 2014 at 11:32:44PM +0200, Christian Hesse wrote:
> Marc André Tanner on Sat, 2014/09/13 16:01:
> > TLDR: I'm writing an experimental but (hopefully) highly efficient vim
> > like text editor based on a piece chain data structure. You will find
> > an url to a git repository at the
On Sat, Sep 13, 2014 at 04:58:35PM +0200, FRIGN wrote:
> I have got one question though: When you are talking about Unicode-awareness,
> are you talking about UTF-8 or more complex sets?
Just UTF-8. The internals asume it in some cases to move from one character
to the next.
> > It is possible t
On Sat, Sep 13, 2014 at 11:06:33AM -0400, Andrew Hills wrote:
> Hi Marc,
>
> Thank you for the thorough and illustrated RFC. If you have not already
> done so, I suggest you keep this text around with the project.
Good idea, I've added it as README for now.
> > Notice that the common case of app
On Sat, 13 Sep 2014 10:09:23 -0700
Markus Teich wrote:
> I find the vim style completion pretty handy. It just completes words, which
> it
> already knows (from open/included files), so you don't need to implement
> complex
> language- and context-dependent filtering. This can also be used when
1 - 100 of 108 matches
Mail list logo
