-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
option to show expanded by default? #17
Comments
In 0.4.4 you can do the following:
We may, in the, future add an option where you can do:
But that's not available yet. |
Ok you talked me in to it... I added It will be available in the next official release. You're welcome to try it now, and test it for us. |
Thanks, it's working perfectly as far as I can tell. |
So what's the point of copying functionality from Kint and reimplementing it in worse[1] approaches while gaining nothing? Will you copy my parsers too? Cause I've spent countless hours to extract every bit of information from every possible type of dumped variable. I've worked around And that's all just for the basic variable parser. You can't not copy this, that is the very firstmost requirement for a dumper, isn't it? Why play catch up when we could act in the spirit of open source and team up. Don't you like something about Kint? I'm here and very active, how can I improve it so you'd feel better about it? I'm making it with a forever free promise and a MIT licence, and my first priority for 1.0 release is make it as contributors friendly as possible. There really is no point of making contests here, at the end of the day, we are creating development tools and PHP is fragmented as it is, let's make something de-facto and best in all senses of the word! If you are not willing to jump ship, I can understand that, but I'd like a discussion on why and whether there's something I can do about that... [1] much more characters to type for the user, global space littered with constants, only one possible parameter to dump. |
I don't think any of us have anything against Kint. I used Kint for the first time last week, and I think it offers a lot of great features. The reason I continue to develop Krumo is because I've been using it for years, and it does everything I need it to. I have very simple needs, basically printing complex arrays, and Krumo does this very well. I don't see the existence of Kint and Krumo being a bad thing. Like any good open source project there are often many different implementations of the same concept. I'd be happy to contribute to Kint too, I just need to get more familiar with it first. |
I feel partially responsible for this discussion because of asking for the feature. I just wanted readable var_dumps without having to have xdebug installed. I was trying out both packages to see which one provides that simple feature and nothing else. To me this requires two things.
My thinking was that any var_dump() package should have 'expanded by default' and asking for that was better than asking for an entire new light weight theme to be added to Kint. Actually I'd like to make the 'light' theme and submit a pr for either or both packages. In the end I went with the chrome extension var_dumpling(). It really is all I need for simple var_dump debugging. But I can see a more robust package like Kint or Krumos could be benefitial for more complex situations. I appreciate all the hard work you both put into these projects. Especially considering they are free to use. I also know you both are researching and discussing improvements for your next releases. That being said I'll list what I don't like about both packages at their current release. I think these changes would greatly improve them and increase their usage.
In composer.json
If the config file is in the location above Laravel users can run
and it will by default be published to app/config/packages/packagname/ Instructions for non framework users could be to manually copy the config file to this same location in their app if they wish to override config options.
Although I mention Laravel several times these changes are all really framework agnostic I think. I also know this is a lot of refactoring and restructuring. No complaints here, just stating my opinion on what both packages need. And I'm willing to contribute what I can. |
I'll briefly reply but I'm away from the computer and will post a full answer when I get back.
Some of the mentioned functionality is only present in the Kint 1.0 branch here in github, check it out if you like. |
Is this solved for you @isimmons can we close the issue? |
This issue can be closed. |
Sorry if I'm missing it somewhere. ravern/kint has a option to make the dump display expanded by using a ! in front of the command
!Kint::dump($somearray) or !dd($somearray)
Is there such a option with krumo? Hopefully with a cleaner syntax than putting ! in front :-)
The text was updated successfully, but these errors were encountered: