This page displays an archive of comments from the site before the site was converted to Hugo. Comments were removed so the site can be rendered without the use of any dynamic content or databases.
Comments below are preserved exactly as they were before the site was converted.
Thank you for all your efforts!
Thank you for such a useful plugin ! Take care.
Hey, just wanted to give You a big "THANK YOU!".
Thank you!
I just found this. It's made my life better. I've got it working for yaml and markdown and python already. Would love to do ansible and terraform too. (Couldn't figure it out tonight quite.) Great stuff! Thank you. Keep up the good work. :)
Legend. Hope things have been getting better.
I use ALE every day! Here's to a better 2021 <3
Thank you for ALE! Like Clay I use it every day. Just wanted to tell you I'm grateful for your effort.
Thank you very much for the ALE. It's arguably the best plugin for VIM ever made.
Thank you so much 💓 0
Thank you for your hard work to the useful plugin!
great respect to you !!
Thank you for your contribution.
Thank you so much for you great work on ALE! Take care.
Great work on ALE! Stay safe!
Hey, I was just checking Ale and looks you have been doing quite well. Thank you for nice tool. Take care and stay safe.
All the way from Thailand :)
Good LUCK! I known u from ale project. It's great!
Hi,
Just wanted to to say thank you for ALE. I write Ansible all day which is all in Yaml, and ALE has found problems before they became problems.
Thanks, Gareth (From Wales, UK)
Definitely the most succinct and to the point vimscript intro I've read, thanks.
Excellent reference! Thank you so much for sharing.
This is THE blog post. The one I needed to contribute to my favorite Vim plugins, ALE included. Thanks.
Thanks for this excellent VimL intro!
One question, the string case-sensitivity section exists twice. Was that intentional?
VimL supports both case-sensitive and case-insensitive comparisons for String values, and the behavior of the == and is operators in Vim is configurable. Because of this, it is advised to always write ==# and is# when working with String values, or ==? and is? instead when you want to perform a case-insensitive comparison. x is? y in VimL is roughly equivalent to String(x).toLowerCase() === String(y).toLowerCase() in JavaScript.
That's a mistake, I'll fix that now.
Fantastic! Thank you so much for writing this.
Thank you, this is excellent! Please, create more on Vim/Neovim for beginners.
Hi w0rp!
I usually refrain from installing any plugins that add "IDE-like" features to Vim, because in my experience, they're just a huge pain to install/configure.
ALE changed my mind. It's pleasant to install and use, it's fast and the documentation and configuration options are awesome.
You're doing amazing work that makes my work so much easier. Thank you! Just wanted to let you know.
Cheers,
Radi
Your first thought when creating an issue should be that you should try to resolve it.
I don't think anyone would argue that.
. . . I, as a copyright holder and project manager, am not under any legal obligation to maintain that software, fix bugs, or to provide new features.
Owners of GitHub projects are expected to merge pull requests from other . . .
"Let the best fork win", I suppose? I think there's something to be said about avoiding a "bus-factor zero" open-source project. I'm curious how your argument or even feelings towards a project could change if offloading some responsibility (like front-lining an issue tracker) was viable.
This post explains that a project maintainer may not have the time, nor the inclination to make code changes. I think it's not correct to characterize "the problem" as some kind of "people wanting things done for them, for nothin' in return" situation (that's my interpretation of the tone).
Figuring out how to successfully manage a project is not as fun as writing the code, dropping the mic and walking away - but I don't think its so hard that a patronizing "see LICENSE.txt, fool" response is actually warranted.
Anyway, when I read something like this I see it as a warning sign for a project that I should stay away from before I have to refactor everything I have built around it in favor of the actually-supported, forked version (e.g. vim -> neovim).
At the end of the day things like "text editors" and "text editor plugins" are derivative projects. We use those tools to more quickly/efficiently get computers to do actual work. It has always been silly to me that these projects have any kind of drama or heartache associated with them.
Response cannot be warranted if software is provided without warranty. Consider the words you speak. FOSS cannot exist without disclaiming warranty. That legal protection is paramount.
Remember that it's _because_ no response is warranted that FOSS is beautiful. People don't have to do anything ever. They simple do it because _they want to do it._ No obligations at all, just a desire to provide something for the Hell of it.
I can confirm I am the author via a post edit if needed.
Thanks for taking the time to share your experiences... this kind of retrospective on something they has blossomed will surely help open source as a whole and encourage more people to innovate and share.
I've been using ALE after refactoring my configs earlier this year and i must say it's very well laid out and it has improved my productivity massively..
Thank you!
ALE is very cool!
The word you want is envy, not jealousy. Jealousy is when you fear someone taking something that you have. Envy is when you want something that someone else has.
I determined that such a plugin would have to be written from scratch
How? Could Syntastic be improved instead? If no, why not?
More core functionality already implemented in Syntastic needed to be implemented
So did Syntastic catch up with ALE?
I could probably write a very long article about my experiences in interacting with other human beings
Please do! Looking forward to reading it!
The trouble with improving Syntastic was that a complete rewrite was needed for the functionality ALE now supports to work properly. Asynchronous programming requires a whole new way of thinking and rewriting pretty much everything. makeprg-style support in Syntastic needed to be replaced with callbacks and custom error handling. Starting fresh was the only way forward. ALE has essentially replaced Syntastic now.
ALEInfo is a great feature. More tools should have something like that. I absentmindedly clicked on this article while ALE was broken and it pointed me to reading that, which then indicated I should check if flake8 was installed.
ALE is a great plugin, thank you!
I love what you have done with ALE.
It has tremendously improved and definitely sped-up my life ;)
Thank you so much!
(At first I wanted to be constructive, but really I can only say how much I like it)
Another attractive solution is to return a wrapper struct that stores the state flag, a possible error string, and the result, with the addition of being able to use it in auto expressions.
Have a look here: https://github.com/AndrejMitrovic/minilib/blob/master/src/minilib/core/types.d#L88
Copy-pasting here for convenience:
/**
This struct type allows you to store both an
error state and the associated data.
It can be used in if statement auto expressions.
*/
struct TaggedResult(T)
{
bool ok = true;
auto opCast(X = bool)() { return ok; }
T _payload;
alias _payload this;
}
///
unittest
{
static struct Node { string[string] data; }
// hardcoded example, the function will return an
// error state if willSucceed is set to false
static TaggedResult!Node getNode(bool willSucceed)
{
typeof(return) result;
if (willSucceed)
result.data["foo"] = "bar";
else
result.ok = false;
return result;
}
if (auto node = getNode(true))
assert(node.data == ["foo" : "bar"]);
else
assert(0); // shouldn't get to here
// enforce also works
if (auto node = enforce(getNode(true)))
assert(node.data == ["foo" : "bar"]);
if (auto node = getNode(false))
assert(0); // shouldn't get to here
try
{
// this will throw
if (auto node = enforce(getNode(false))) { }
assert(0);
}
catch (Exception)
{
}
}
Please add what "ARC" means; I had to look it up.
Using ARC will be technically be @nogc, I suppose, but would still incur the allocation. Allocation (whether regular or GC) is often unbounded, which is one of things @nogc is trying to prevent.
I just found this post while trying to throw exceptions statically in @nogc code. I cannot understand from your post why its a pitfall. Can you elaborate a little bit more about what becomes incorrect when you throw the same exception again? What is the expected result if you threw exceptions normally, i.e. allocated the new object with GC?
I will never use D until they get rid of GC and all the stupid annotations
I only just noticed the comments here. I really should fix my email notifications.
The pitfall with storing a static exception and re-throwing it is that you either make the exception somehow immutable, and provide the wrong stack trace, or you modify the exception, and you change a stack trace while an exception is still in-flight. Either way, you will produce stack traces which are wrong and don't make sense.
What are the best practices for handling errors during the load? Exceptions?
The best error handling mechanism I can think of is using exceptions. However, if you are running your D code in an environment where you cannot use exceptions at all, you might be left with error codes and error objects. A pattern similar to Objective C might be appropriate, where you set the error in some extra parameter taken by a pointer or a reference.
Are you saying the last example better than the C++ way (using a private constructor and public static methods which use the private constructor), if so - why is it better? Or just showing how to do it the D way?
If you really want to, you can of course also @disable init:
struct Foo { @disable static typeof(this) init(); }
You probably don't, though. Even with .init disabled, you can still get a Foo without calling any constructors:
Foo f = void;
It may also be worth noting that D has static opCall:
struct Bar { static Bar opCall() { Bar result = void; // initialize result return result; } }
Letting you write:
Bar b = Bar();
come back 2 irc ssw_kikkoman we love u
frist
Hello, w0rp. Do you actually programming in D now?
I used to primarily use C, and I can't believe I'm only learning about D now. It has so much nice features that other languages just don't have.
I primarily program in Go when I want a systems level language now, but D has a lot of great ideas.
sounds great. i am checking out the videos now
Keep it up :)