On 16 September 2014 23:45, FRIGN wrote:
> The strongest argument for me against C++ is not a technical one, but
> the fact that you are forced to program in subsets.
> This leads to the problem that new developers planning on contributing
> to a project might have problems with adapting to it bec
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?
On 09/16/2014 05:45 PM, FRIGN wrote:
On Tue, 16 Sep 2014 17:25:02 -0500
Jimmie Houchin wrote:
Hey Jimmie,
Seeing how much C++ people complain about the C like stuff or the actual
C stuff in C++. Why don't they just grow a pair and clean out all the
stuff they complain about. Simplify the lan
> > 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
Marc André Tanner writes:
>> 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?
Vnjm>
I
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 Wed, Sep 17, 2014 at 09:28:41AM -0500, Jimmie Houchin wrote:
> C Primer Plus, 6th ed., Stephen Prata
> 21st Century C, 2nd ed., Ben Klemens
> Understanding and Using C Pointers, Richard Reese
I am not familiar with these books, I learnt from K&R and I'd recommend
you do the same. Once you've g
On 09/17/2014 12:50 AM, Markus Teich wrote:
Jimmie Houchin wrote:
I have been for the last several weeks (months) researching what language I
want to use to implement a couple of apps I want to do.
What kind of apps are you planning to write?
What I am working on right now is a quantitative
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
Thanks Marc,
the feature works as expected. The only difference I noted is that vim
do stop scrolling if you are at the top/bottom of the buffer while vis
still move the cursor if possible, without scrolling, since it reach
the top/bottom of the buffer. Not sure what is the right behaviour but
I s
On Tue, Sep 16, 2014 at 03:41:43PM -0300, Amadeus Folego wrote:
> On Tue, Sep 16, 2014 at 07:55:40PM +0200, Marc André Tanner wrote:
> > I have cleaned up the cursor handling code in window.[ch] and implemented
> > the CTRL-{U,D,E,Y} functionality in normal mode. However I'm not sure it
> > behaves
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
Hi,
The following patch makes c-j and c-m in dmenu work as the manpage
describes. Because ControlMask was set it would select and output the
line, but not exit.
Thanks to mistnum on IRC for reporting this!
Kind regards,
Hiltjo
From 00d3ebc66c1a1cc2fa8c834fd7632d9058fe3aab Mon Sep 17 00:00:00 200
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 Tue, Sep 16, 2014 at 07:14:53PM -0400, Wolfgang Corcoran-Mathe wrote:
> Fixed typo breaking + functionality in tail:
>
> diff --git a/tail.c b/tail.c
> index 59e68ca..87a08b9 100644
> --- a/tail.c
> +++ b/tail.c
> @@ -60,7 +60,7 @@ dropinit(FILE *fp, const char *str, long n)
>ssize_t le
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,
>
30 matches
Mail list logo
