Re: [elixir-core:5968] Proposal for Random related functions

Initially Range.at/2 and Range.random/1 were part of Enum.at/2 and Enum.random/1 respectively. They were just moved to their own functions because it made more sense to me. These functions are fast enough IMO (as fast as I can think of). I would not get rid of Integer.random/1-2 as it's the base

Re: [elixir-core:5967] How to change the markdown engine to generate docs in Elixir Project

> > why wouldn't it be possible for other projects to set the markdown > engine throuhg the CLI? > Because only Elixir uses it from the command line at this point and, even if we make it available with the upcoming mix escript.install feature, c dependencies can't be bundled in escripts, so the

Re: [elixir-core:5966] Proposal: Enum.pad and Enum.pad_zip

I believe the proposal above does not fit the current definition of pad in Elixir. We use pad for values that are automatically cycled and leftover with the semantics in your code. I am also not sure if zip_pad or pad_zip are the best names or if it would be better to follow the same road as

Re: [elixir-core:5965] Proposal for Random related functions

We should definitely optimize functions like at and random when we can, so definitely +1 on this front. Regarding the other functions, I am still skeptical of their need. In particular, if we implement Enum.random fast enough for ranges, it would be enough to replace many of the other functions

Re: [elixir-core:5964] Proposal: Enum.pad and Enum.pad_zip

Jose could you please give me an answer on this, as I would like to to finally make it into the Elixir. Thank you On Thu, 5 May 2016 11:56:47 +0700 eksperimental wrote: > Jose, > It was earlier suggested that we should have a function like this. > Could you please

Re: [elixir-core:5963] Proposal for Random related functions

An answer from someone from the core team would be more than welcome on this proposal. In addition to the proposed funtions, this proposal also tackles an issue in Enum.random/1 when dealing with a ranges, which is really slow if the range is huge, since it delegates to take_random to be

Re: [elixir-core:5960] How to change the markdown engine to generate docs in Elixir Project

And thank you for looking into this! On Thursday, June 23, 2016, eksperimental wrote: > Hi, > I have found three offending lines when running `make docs_elixir`, but > Earmark is unable to tell (yet) which file is causing trouble. > > :42: warning: Closing unclosed

Re: [elixir-core:5956] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

> > Also for those looking for a way to "cancel the current line" in iex, you > can type #iex:break at any time to return to do so. > This is super useful to know. And I know it. And I still never use it because I don't think about until it's too late. And I've been using Elixir, and known

Re: [elixir-core:5956] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

I like it as well. Also for those looking for a way to "cancel the current line" in iex, you can type #iex:break at any time to return to do so. On Thursday, June 23, 2016 at 2:15:46 PM UTC-4, José Valim wrote: > > Sounds good to me too! > > > > *José Valim* > www.plataformatec.com.br > Skype:

Re: [elixir-core:5954] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

Sounds good to me too! *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R On Thu, Jun 23, 2016 at 8:11 PM, Paul Clegg wrote: > I can get behind this as a no-config-option compromise. :) > > ...Paul > > > > On Thu, Jun 23, 2016 at 10:59

Re: [elixir-core:5948] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

I share Jose' opinion here, but making it configurable sounds good. Cheers, Louis On 23 June 2016 at 17:40, Myron Marston wrote: > This behavior of IEx has always surprised and annoyed me. I regularly type h > [first few chars of mod name] in IEx to read the read the >