nvbn
Feature Request: Instant-Interactive Mode + Zoxide with FZF
Hi there! hope you are well! I've been getting hang of zoxide (with fzf) and im really think it will be amazing if thefuck adopts it the thing with zoxide, it only does folders, but it works amazing, i can be all the way in ~/ (or anywhere) and type cd ben -> and it goes (correctly) to ~/wholesomegarden/xo-benedict (which is long to type/Up/Tab your way through) simply amazing
I want the same for general commands arguments and files,
for example, i can type p live (from directory) (p is my alias for python3.11, and inside a folder i frequently use, theres a file .///liveupdate.py)
so like zoxide, if the file/folder has a high frequency, it can give a high score to thefuck to run, over a certain positive score, it can skip the prompting to continue, like instant mode, or load a nice & rich interactive window to choose from. Just taking history should give a lot of useful things with fzf + the fuck (you probably already use it) but what i want is like zoxide for the terminal to understand my intention regardless which folder im at, and just run my commands, so this is where the fuck comes in hopefully 🙏
Oh and another important thing... as i undertand, i need to type fuck+Enter to trigger this... i thought it suppose to be instant i would like it to recognize whenever a command was instantly regected and retry without typing fuck
If this is already implemented and i missed it i'd love to know! Thanks a lot and all the best!
Ps- sry if its long, its late haha
It seems weird to say, "Let's look at these files" and then offer no explanation. I think it's a helpful overview.
That is fair. How about this ?
I think the question to answer is, why does the learner/ user need to go through it?
- These are pointing to other doc links, which distract the learner/ user from the next steps in the tutorial
- They will need to go through it again anyway when they configure the app, project, etc.,
It is also more in agreement with the later startapp files directory explanation 😉
@evildmp suggested the edit in the djangocon-sprint today; @evildmp please feel free to add your inputs!
Well, I don't agree with this and other changes proposed by @evildmp, removing large amounts of explanatory material from the tutorial (https://github.com/django/django/pull/18253, https://github.com/django/django/pull/18246, https://github.com/django/django/pull/18239). Perhaps my opinion is in the minority, but I would like to see some consensus on the Django forum before moving forward with all these removals. I came to Django as an experienced programmer and I found many of these incidental explanations helpful, even if not strictly necessary. It seems Daniele wants to target the tutorial more at beginner programmers.
Dear Tim,
please consider my edited comment above, I have tried to answer "why" of the edit, as I understood it ! I will try to post them as new comments in the future
Well, I don't agree with this and other changes proposed by @evildmp, removing large amounts of explanatory material from the tutorial (#18253, #18246, #18239). Perhaps my opinion is in the minority, but I would like to see some consensus on the Django forum before moving forward with all these removals.
Our tutorial is like a beloved old friend that has succumbed to some middle-aged bloating. It has become rather flabby in places (these aren't even the most problematic examples - look at https://docs.djangoproject.com/en/5.0/intro/tutorial05/, in which the poor user must plod through multiple paragraphs of verbiage before they get to do anything).
There is an endless number valuable-to-a-few people things that could be added to it (and we can see that a lot have gone in already).
We need to make the tutorial crisp, lean, and punchy, so that every part of it is a contribution to the user's learning experience, not digressions into things that are described or explained elsewhere, and that the vast majority of users derive no value from.
These digressions really serve the authors' (wholly understandable, and also hard to resist) need to teach and explain much more than they serve the learners' needs.
Nothing is lost by moving such material out of the tutorial into a more appropriate place and linking to it. In fact, it's of advantage to people who are interested in it, because now they will find it in context, and given the space it needs - not shoehorned into an awkward aside in the tutorial.
By the way these issues were created in a workshop at DjangoCon Europe (by participants in the workshop, after discussion of what the tutorial does well and not so well; discussed also with @nessita, @carltongibson, @felixxm, @thibaudcolas and others in multiple conversations, perhaps they'd like to provide some input too).
It seems Daniele wants to target the tutorial more at beginner programmers.
Not in the least. It doesn't matter how experienced your are or how advanced your skills, when you are in a learning situation acquiring a new skill, you learn more effectively if you are not being interrupted by unnecessary digressions and distractions.
I don't want to waste time in dialog if the decision is already made, but I think these asides and explanations do provide value. They briefly show off aspect of Django that the reader can return to in more depth later. They teach philosophy and the "why" behind what we are doing.
If the Django community has decided we don't want these things anymore, then yes, we could excise quite a lot of material from the tutorial so the user can get through it much more quickly and come away with less knowledge. I think that would be a loss. When I was a new Django user, I was in no rush to get through the tutorial, and I remember enjoying its detailed explanations.
I appreciate all the work you're doing to try to improve the tutorial, but I don't agree with your characterization that it suffers from middle-aged bloat when most of these explanations have been there since the beginning (with some revisions at Django's PAIs have changed). Cheers!
There have been numerous discussions about simplifying the tutorial over a number of years now. There's widespread criticism within the wider ecosystem that it's too complicated: joking phrases such as "the infamous polls tutorial" ref are often used.
Bringing it into line with the Diataxis approach has been an agreed goal for a number of years now. These changes are in line with that.
We can (of course) open a thread on the forum and summon opinions again to reiterate all these conversations one more time, but it just seems like another unnecessary trip into the long grass.
I appreciate your points as well Tim. I think there is a tension between the tutorial goal and wanting to explain more. I feel that. Nonetheless I think Daniele has made the case in his work that the more pure tutorial is the better way. (I can't repeat that case as well as he's made it but I have come to accept it, as have others...)
@esskaey There is no need to include images to show what the changes will look like - that's easy enough for readers to infer via https://github.com/django/django/pull/18242/files. In fact including the images makes it harder to follow your pull request, so I suggest removing them.
I think it's right to remove that material from the tutorial - but that's only half the job. There are at least four more questions to be considered:
-
What should we say about the folder structure, now that we have excised that additional explanation? I think we should say something - for example: "As we proceed through the tutorial we will encounter some of these files more closely and work with them - their purpose and function will become clearer then."
-
Should the information we have removed be included somewhere in the documentation, if not here?
-
If so, where? (Perhaps there is already a page somewhere that explains the output of
startproject- I can't easily check right now, but I suspect that there isn't. You could start looking at https://docs.djangoproject.com/en/5.0/ref/django-admin/#startproject, but my feeling is that a new page under https://docs.djangoproject.com/en/5.0/topics/ titled something like "Django project layouts and conventions" might be called for.) -
Should we link to this material from the tutorial? (In my opinion, definitely.)
Tim wrote:
I think these asides and explanations do provide value. They briefly show off aspect of Django that the reader can return to in more depth later. They teach philosophy and the "why" behind what we are doing.
I think this material does more than provide value, I think it is essential to the completeness and success of the documentation. The "why" of Django is often scattered in the documentation though, rather than being collected and organised more deliberately.
If you were giving me my first flying lesson in a turbine-powered aircraft after years of flying piston-engined planes, at a certain point in that lesson I might be surprised, say by the slow spool-up time of the engines. And to understand what is happening and how to think about it, I would ask for some explanation. But the time for the explanation - the philosophy of flying a turbo-prop) would not be in the middle of that first flight (when it would be distracting, and I wouldn't be able to pay it proper attention) but when we are safely back on the ground for the debriefing.
I feel it's the same with the documentation. I would like to develop the explanatory power of our documentation in the /topics section, where we can organise material about why and philosophy and so on in more satisfactory ways.
The tutorial and the flying lesson are for learning - acquiring familiarity, having safe encounters with the machinery and work and techniques - in a controlled environment. The explanation guides (and the post-flight debriefing) are for acquiring deeper knowledge and understanding.
@esskaey There is no need to include images to show what the changes will look like - that's easy enough for readers to infer via https://github.com/django/django/pull/18242/files. In fact including the images makes it harder to follow your pull request, so I suggest removing them.
I thought it saves one time, by not having to check out and generate the docs. Not adding images is only easier for me :) I have tried to address the questions from your comment.
Hello!
I've been following the conversation in this PR, and pondering about the best course of action. After some consideration, I agree with @evildmp and @carltongibson about the benefits of sticking to the Diátaxis principles and focusing the content of the tutorial to what the user needs to learn at a given step. My rationale is as follows:
- Feedback heard in DjangoCon Europe about the presence of distracting and confusing content in the tutorial, specifically in tutorial 1.
- Many Trac tickets have been closed with the rationale that tutorials should provide only the minimum necessary explanation.
- My own history of learning. When I read these two comments from @timgraham I thought "I must be an alien" because I've had the opposite experience:
I came to Django as an experienced programmer and I found many of these incidental explanations helpful, even if not strictly necessary. [...] When I was a new Django user, I was in no rush to get through the tutorial, and I remember enjoying its detailed explanations.
Following the flying lessons analogy, I can share my own real anecdote which illustrates why, even for experienced users, sticking to the basic when learning a new thing is important:
I've been driving manual stick cars for over 20 years now, so you could say I'm an experienced driver. I've navigated through all sorts of streets, routes, and countries—handling everything from old clunky cars that made parking on slopes a real challenge to newer models with cameras and alarms for added assistance. When I recently switched to driving an automatic car, it was a whole new experience. I had to focus on the bare minimum to keep the car running smoothly and avoid any mishaps, especially since I was so used to think about RPMs and smooth gear transitions. My right hand would constantly (incorrectly) reach for the stick and my left foot would attempt to press on a missing clutch. When the salesperson was explaining how to use the car, they started mentioning the radio, windshield wipers, and how to connect my phone to the car's screen, and I was just like, "NO, STOP, SHUT UP! I can barely keep this thing moving straight!".
When I first drove this car, it was a sunny day, so any explanation about windshield wipers was completely unnecessary and distracting! Of course that at some I definitely had to learn how to use them, but the first drive was not the right time for it. Same for the radio, the GPS, the "sport mode", and what not.
Answering some spot on questions from Daniele:
What should we say about the folder structure? "As we proceed through the tutorial we will encounter some of these files more closely and work with them - their purpose and function will become clearer then."
That proposal sounds sensible.
Should the information we have removed be included somewhere in the documentation, if not here?
Yes, please. We should find a place for these for this PR and the other PRs that are removing unnecessary explanations.
If so, where?
I think we could grow the ref to include the result of invoking startproject.
my feeling is that a new page under https://docs.djangoproject.com/en/5.0/topics/ titled something like "Django project layouts and conventions" might be called for.
This also sounds like a good option but I think it will require more traction/time to get this done.
Should we link to this material from the tutorial? (In my opinion, definitely.)
I agree.
Can we change the verb in the title of the PR, from 'remove' to 'move'?
Sure, we should follow the existing commit message pattern which is using "Relocated", see 73e8e811416dcb5007ad9cc9d1632aaca95bf302 and 82c71f0168b1c132e499505609d285c6016ed4f2