* zsh function breaks after error @ 2022-02-08 17:16 Thomas Lauer 2022-02-09 15:18 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Thomas Lauer @ 2022-02-08 17:16 UTC (permalink / raw) To: Zsh Users I have googled for what seems to be an simple and obvious thing but somehow I seem to be unable to find what I'm looking for. So here goes. I have this function, called via keyboard shortcut while editing a line: expandDir2() { zle backward-kill-word local _dir=$CUTBUFFER _dir=${_dir:gs/*/.+/} _dir=${_dir:gs/?/./} _dir=${_dir:gs/:/(?i)/} _dir=$(command grep -hP "$_dir" ~/other/dirlist_*.txt | rofi -dmenu -p \"Directory\") echo Never reached on Esc. [[ "$_dir" == "" ]] && BUFFER=$BUFFER$CUTBUFFER || BUFFER=$BUFFER$_dir CURSOR=$#BUFFER } This basically reads a search string (say "u*sh*z"), greps a set of files with directory lists (created by a custom script) and runs rofi in dmenu mode to select one directory which then replaces the search string. This works very well. The trouble starts when rofi is terminated not via selecting one of the shown directories (exit value 0) but with Esc/Ctrl-G (exit value 1). In this case the function just breaks and I have found no way to actually check for either the returned string of rofi or its exit value. Bash has set +-e and I am sure there is sth similar for zsh but I can't for the life of me find it (I have for now "solved" the problem by writing a two-liner that calls rofi and always returns exit 0 but that's a kludge at best). THX Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-08 17:16 zsh function breaks after error Thomas Lauer @ 2022-02-09 15:18 ` Bart Schaefer 2022-02-09 18:45 ` Thomas Lauer 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2022-02-09 15:18 UTC (permalink / raw) To: Thomas Lauer; +Cc: Zsh Users On Tue, Feb 8, 2022 at 9:16 AM Thomas Lauer <thomas.lauer@virgin.net> wrote: > > The trouble starts when rofi is terminated > not via selecting one of the shown directories (exit value 0) but with > Esc/Ctrl-G (exit value 1). > > In this case the function just breaks Preface: I have no way to test this directly, I no longer have an X interface to play with. However, I can't repeat this using a simpler pipeline that exits 1 from inside the $(...). Are you sure the exit status is 1? Could instead for example the grep be receiving a SIGPIPE because rofi stopped reading too soon? I tried to simulate that, too, but without ill effect. Zsh does have "set +e" and "set -e" but unless -e (errexit) is in effect from outside the function you've presented, that shouldn't matter. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-09 15:18 ` Bart Schaefer @ 2022-02-09 18:45 ` Thomas Lauer 2022-02-09 20:16 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Thomas Lauer @ 2022-02-09 18:45 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh Users > On Tue, Feb 8, 2022 at 9:16 AM Thomas Lauer <thomas.lauer@virgin.net> wrote: > > > > The trouble starts when rofi is terminated > > not via selecting one of the shown directories (exit value 0) but with > > Esc/Ctrl-G (exit value 1). > > > > In this case the function just breaks > > Are you sure the exit status is 1? Yes. > Could instead for example the grep > be receiving a SIGPIPE because rofi stopped reading too soon? Well... as I wrote in my OP: if I replace the rofi call with a tiny script that does precisely the same thing but *always* exits with error code 0, all works as it should. So I am pretty sure that rofi exiting with 1 is indeed the culprit here. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-09 18:45 ` Thomas Lauer @ 2022-02-09 20:16 ` Bart Schaefer 2022-02-10 13:55 ` Thomas Lauer 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2022-02-09 20:16 UTC (permalink / raw) To: Thomas Lauer; +Cc: Zsh Users On Wed, Feb 9, 2022 at 10:45 AM Thomas Lauer <thomas.lauer@virgin.net> wrote: > > Well... as I wrote in my OP: if I replace the rofi call with a tiny > script that does precisely the same thing but *always* exits with error > code 0, all works as it should. So I am pretty sure that rofi exiting > with 1 is indeed the culprit here. If you use your tiny script and replace "exit 0" with "exit $?" (so it exits with the same status as rofi) does that still reproduce the problem? Incidentally, what's the $ZSH_PATCHLEVEL ? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-09 20:16 ` Bart Schaefer @ 2022-02-10 13:55 ` Thomas Lauer 2022-02-10 13:59 ` Roman Perepelitsa 0 siblings, 1 reply; 20+ messages in thread From: Thomas Lauer @ 2022-02-10 13:55 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh Users > > Well... as I wrote in my OP: if I replace the rofi call with a tiny > > script that does precisely the same thing but *always* exits with error > > code 0, all works as it should. So I am pretty sure that rofi exiting > > with 1 is indeed the culprit here. > > If you use your tiny script and replace "exit 0" with "exit $?" (so it > exits with the same status as rofi) does that still reproduce the > problem? Yes, the function still breaks. > Incidentally, what's the $ZSH_PATCHLEVEL ? "debian/5.7.1-1" It's no big deal but I find it strange that I can't have a function which executes to the very end when an external call fails. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-10 13:55 ` Thomas Lauer @ 2022-02-10 13:59 ` Roman Perepelitsa 2022-02-10 16:20 ` Thomas Lauer 0 siblings, 1 reply; 20+ messages in thread From: Roman Perepelitsa @ 2022-02-10 13:59 UTC (permalink / raw) To: Thomas Lauer; +Cc: Bart Schaefer, Zsh Users [-- Attachment #1: Type: text/plain, Size: 640 bytes --] On Thu, 10 Feb 2022 at 14:56, Thomas Lauer <thomas.lauer@virgin.net> wrote: > > > Well... as I wrote in my OP: if I replace the rofi call with a tiny > > > script that does precisely the same thing but *always* exits with error > > > code 0, all works as it should. So I am pretty sure that rofi exiting > > > with 1 is indeed the culprit here. > > > > If you use your tiny script and replace "exit 0" with "exit $?" (so it > > exits with the same status as rofi) does that still reproduce the > > problem? > > Yes, the function still breaks. What happens if you add `emulate -L zsh` (without quotes) at the top of the function? Roman. [-- Attachment #2: Type: text/html, Size: 1097 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-10 13:59 ` Roman Perepelitsa @ 2022-02-10 16:20 ` Thomas Lauer 2022-02-10 16:48 ` Roman Perepelitsa 0 siblings, 1 reply; 20+ messages in thread From: Thomas Lauer @ 2022-02-10 16:20 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Bart Schaefer, Zsh Users > From: Roman Perepelitsa <roman.perepelitsa@gmail.com> > > What happens if you add `emulate -L zsh` (without quotes) at the top of the > function? Something good happens... it now works as I'd expect! Thanks, will have to read up about this! Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-10 16:20 ` Thomas Lauer @ 2022-02-10 16:48 ` Roman Perepelitsa 2022-02-10 17:20 ` Thomas Lauer 0 siblings, 1 reply; 20+ messages in thread From: Roman Perepelitsa @ 2022-02-10 16:48 UTC (permalink / raw) To: Thomas Lauer; +Cc: Bart Schaefer, Zsh Users On Thu, Feb 10, 2022 at 5:20 PM Thomas Lauer <thomas.lauer@virgin.net> wrote: > > > From: Roman Perepelitsa <roman.perepelitsa@gmail.com> > > > > What happens if you add `emulate -L zsh` (without quotes) at the top of the > > function? > > Something good happens... it now works as I'd expect! Thanks, will have > to read up about this! This means that err_return option is set in your interactive zsh. This is likely the result of invoking a function that has `setopt err_return` in it without `emulate -L zsh` and without `setopt local_options`. That function needs to be fixed. For example, you could replace `setopt err_return` with `emulate -L zsh -o err_return`. You can read about zsh options and `emulate -L` here: https://zsh.sourceforge.io/Doc/Release/Options.html Roman. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-10 16:48 ` Roman Perepelitsa @ 2022-02-10 17:20 ` Thomas Lauer 2022-02-10 21:26 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Thomas Lauer @ 2022-02-10 17:20 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Bart Schaefer, Zsh Users > From: Roman Perepelitsa <roman.perepelitsa@gmail.com> > > This means that err_return option is set in your interactive zsh. This > is likely the result of invoking a function that has `setopt > err_return` in it without `emulate -L zsh` and without `setopt > local_options`. That function needs to be fixed. For example, you > could replace `setopt err_return` with `emulate -L zsh -o err_return`. > > You can read about zsh options and `emulate -L` here: > https://zsh.sourceforge.io/Doc/Release/Options.html Yep. Indeed, I have err_return set in my .zshrc (there are so many options there that I have no idea when or even why I did include this). Removed and things now work w/o "emulate -L zsh". Appreciate your explanation and help. Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-10 17:20 ` Thomas Lauer @ 2022-02-10 21:26 ` Ray Andrews 2022-02-10 21:45 ` Thomas Paulsen 2022-02-11 14:58 ` Thomas Lauer 0 siblings, 2 replies; 20+ messages in thread From: Ray Andrews @ 2022-02-10 21:26 UTC (permalink / raw) To: zsh-users On 2022-02-10 09:20, Thomas Lauer wrote: > > (there are so many > options there that I have no idea when or even why I did include this). > When I first got involved I learned to turn absolutely everything 'config' off except for my one and only .zshrc file so that I'd at least know where to look if things went strange. Then I picked a sample .zshrc on faith off the internet and slowly by trial and error figured out what half of it does. The other half is still a mystery, mostly the 'complete completer completion completing' stuff -- and I get the feeling no one really understands it fully anyway. Like with everything else, the docs assume you are already an expert. But a beginner's guide to configuration would have sure been nice. I bitched about this a little bit: the setup utility should offer you several config options complete with a brief description of what each one offers. Mind, I was coming from DOS whereas most zsh converts are already shell experts, so my culture shock was much worse than for most. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: zsh function breaks after error 2022-02-10 21:26 ` Ray Andrews @ 2022-02-10 21:45 ` Thomas Paulsen 2022-02-10 23:37 ` Daniel Shahaf 2022-02-11 15:07 ` Thomas Lauer 2022-02-11 14:58 ` Thomas Lauer 1 sibling, 2 replies; 20+ messages in thread From: Thomas Paulsen @ 2022-02-10 21:45 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users --- Ursprüngliche Nachricht --- Von: Ray Andrews <rayandrews@eastlink.ca> Datum: 10.02.2022 22:26:02 An: zsh-users@zsh.org Betreff: Re: zsh function breaks after error On 2022-02-10 09:20, Thomas Lauer wrote: > > (there are so many > options there that I have no idea when or even why I did include this). >mostly the 'complete completer completion completing' stuff -- and I get the feeling no one really understands it fully anyway. I understand and think, we should work out a commented .zshrc step by step project, archiving it, so any newbie has a chance to work out a working .zshrc by himself. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-10 21:45 ` Thomas Paulsen @ 2022-02-10 23:37 ` Daniel Shahaf 2022-02-11 15:07 ` Thomas Lauer 1 sibling, 0 replies; 20+ messages in thread From: Daniel Shahaf @ 2022-02-10 23:37 UTC (permalink / raw) To: zsh-users Thomas Paulsen wrote on Thu, 10 Feb 2022 21:45 +00:00: > I understand and think, we should work out a commented .zshrc step by > step project, archiving it, so any newbie has a chance to work out a > working .zshrc by himself. Like this? https://gitlab.com/zsh-sensible/zsh-sensible/ Looking in this list's archives for discussions of zsh-newuser-install should turn up related threads. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-10 21:45 ` Thomas Paulsen 2022-02-10 23:37 ` Daniel Shahaf @ 2022-02-11 15:07 ` Thomas Lauer 1 sibling, 0 replies; 20+ messages in thread From: Thomas Lauer @ 2022-02-11 15:07 UTC (permalink / raw) To: Thomas Paulsen; +Cc: Ray Andrews, zsh-users > From: "Thomas Paulsen" <thomas.paulsen@firemail.de> > --- Ursprüngliche Nachricht --- > Von: Ray Andrews <rayandrews@eastlink.ca> > Datum: 10.02.2022 22:26:02 > An: zsh-users@zsh.org > Betreff: Re: zsh function breaks after error > > On 2022-02-10 09:20, Thomas Lauer wrote: > > > > (there are so many > > options there that I have no idea when or even why I did include this). > > >mostly the 'complete completer completion completing' stuff -- and I get the > feeling no one really understands it fully anyway. > I understand and think, we should work out a commented .zshrc step by step project, archiving it, so any newbie has a chance to work out a working .zshrc by himself. This would certainly help but many things zsh are interconnected in a way that means that you have to understand something in order to understand something else... but to understand the first thing you have to understand the second (I am exaggerating but in a way reading and trying to digest the zsh docs did remind me of the time when I went through the Big Blue Book of KIM (this was a 6502-based "microcomputer" as these things were called then) and tried to understand the 6502 and its assembler language. I read this book three times before I had the first tiny glimmer of understanding what it was all about and it took me another two times to get to grips with the 6502.) Anyway, if such a project comes into being I would be willing to help within my capabilities and time constraints. I have written loads of tech docs over the years so perhaps I could add some value. Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-10 21:26 ` Ray Andrews 2022-02-10 21:45 ` Thomas Paulsen @ 2022-02-11 14:58 ` Thomas Lauer 2022-02-11 15:59 ` Ray Andrews 1 sibling, 1 reply; 20+ messages in thread From: Thomas Lauer @ 2022-02-11 14:58 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users > From: Ray Andrews <rayandrews@eastlink.ca> > On 2022-02-10 09:20, Thomas Lauer wrote: > > > > (there are so many > > options there that I have no idea when or even why I did include this). > > > When I first got involved I learned to turn absolutely everything > 'config' off except for my one and only .zshrc file so that I'd at least > know where to look if things went strange. Then I picked a sample > .zshrc on faith off the internet and slowly by trial and error figured > out what half of it does. The other half is still a mystery, mostly the > 'complete completer completion completing' stuff -- and I get the > feeling no one really understands it fully anyway. Like with everything > else, the docs assume you are already an expert. But a beginner's guide > to configuration would have sure been nice. I bitched about this a > little bit: the setup utility should offer you several config options > complete with a brief description of what each one offers. Mind, I was > coming from DOS whereas most zsh converts are already shell experts, so > my culture shock was much worse than for most. Well... I tend to know what I am doing and I think (or thought) that all the options in my .zshrc are there for a reason. I literally went through the options documentation one by one over a few days, looked into each option and (tried to understand and) decide whether it was a Good (tm) thing or not. For most options this worked pretty well, but there were a few which were then over my head (probably some still are). But I agree that the density of the documentation can be a problem, especially for people who are no developers and are perhaps not used to dense docs :-) I'm a Windows refugee as well but over there I've used a command processor called Take Command (the former 4NT) for decades and so I was already used to a powerful and complex beast of a shell. And yes, the completion still is mostly a mystery but with judicious use of Google, Stackexchange, Reddit etc etc and a lot of trial and error I have cobbled together something that works pretty much as I want. Actually it was the completion that convinced me to drop bash and start using zsh. But if there ever was a case of YMMV *and* RTFM then zsh must be it:-) Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-11 14:58 ` Thomas Lauer @ 2022-02-11 15:59 ` Ray Andrews 2022-02-11 23:31 ` Bart Schaefer 2022-02-12 16:45 ` Thomas Lauer 0 siblings, 2 replies; 20+ messages in thread From: Ray Andrews @ 2022-02-11 15:59 UTC (permalink / raw) To: zsh-users On 2022-02-11 06:58, Thomas Lauer wrote: > > But I agree that the density of the documentation can be a problem, > especially for people who are no developers and are perhaps not used to > dense docs :-) You can say that again. It gets easier with exposure of course, but even now I'd say that zsh/unix/linux docs -- especially the old 'man pages' are often spectacularly badly written. 'Dense' might be a charitable way of putting it. > I'm a Windows refugee as well but over there I've used a command > processor called Take Command (the former 4NT) 4DOS and Take Command ruined me. I got to just taking for granted that level of polished perfection and when I moved over here, the culture shock nearly killed me. > but with judicious use > of Google, Stackexchange, Reddit etc etc and a lot of trial and error > Yeah, resources are out there if you just beat the bushes long enough. Like Daniel's link above. But how about if it were all collated and condensed and brought in-house? > This would certainly help but many things zsh are interconnected in a way that means that you have to understand something in order to understand something else... but to understand the first thing you have to understand the second Heck yes, which is why layering is a good idea. The newbie's 'introduction to zsh config' won't even attempt to tell you everything, it will merely get you to 90% of what might be your eventual, expert configuration, but hold you by the hand and get you there painlessly. 90% of what you want in 10% of the time it would otherwise have taken. Advanced wizards can devote years of study to mastering the remaining 10%. A sample line might have this sort of feel: HISTSIZE=SAVEHIST=20000 #Trust us, you want a big history recall buffer. If your machine is pathetically short of resources make it smaller. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-11 15:59 ` Ray Andrews @ 2022-02-11 23:31 ` Bart Schaefer 2022-02-12 3:39 ` Ray Andrews 2022-02-22 3:58 ` Matthew Martin 2022-02-12 16:45 ` Thomas Lauer 1 sibling, 2 replies; 20+ messages in thread From: Bart Schaefer @ 2022-02-11 23:31 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users On Fri, Feb 11, 2022 at 8:00 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Yeah, resources are out there if you just beat the bushes long enough. > But how about if it were all collated and condensed and > brought in-house? Consensus is hard. For example, I personally I think tens of thousands of lines of history is unnecessary no matter how much RAM you have to throw at it. The other question that constantly arises is whether the goal is to make the shell more helpful out of the box for relatively knowledgeable users, or to make it more attractive to newbies. If the latter, is the most important thing to give it a flashy appearance? In either case, where do you draw the line to "get you to 90%"? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-11 23:31 ` Bart Schaefer @ 2022-02-12 3:39 ` Ray Andrews 2022-02-22 3:58 ` Matthew Martin 1 sibling, 0 replies; 20+ messages in thread From: Ray Andrews @ 2022-02-12 3:39 UTC (permalink / raw) To: zsh-users On 2022-02-11 15:31, Bart Schaefer wrote: > > Consensus is hard. For example, I personally I think tens of > thousands of lines of history is unnecessary no matter how much RAM > you have to throw at it. I picked that line almost at random. Thinking about it, mine probably is too big. Point is that some reasonable amount of history is something that almost everyone wants. > > The other question that constantly arises is whether the goal is to > make the shell more helpful out of the box for relatively > knowledgeable users, or to make it more attractive to newbies. That's why you have several offerings, from basic to ... well, the 'advanced' configs could almost become rococo fun-fests, just showing off for the fun of it. Don't hafta get anything perfect, just close. I still vividly remember the very first time I got Linux installed and booted. There I am at a stone age prompt and I had some instructions printed off (from Windows) as to what to do next. Well, it was bash of course, but NO history, NO backspace key, NO prompt (to speak of) ... other missing stuff, can't remember ... anyway it was so bloody primitive that DOS looked elegant by comparison. Eventually I got an editor working and I think it was 'joe' or something, that made edlin look sophisticated. I almost quit. Initiation hazing or something? But, after jumping to zsh, I remember when I started thinking about prompts -- I can't remember where but there were samples named 'Oliver's prompt' and 'Bart's prompt' and so on and you picked one and tried it. Marvelous. Tune to perfection later, in the mean time it's very good at least. Suffering is not good for the soul. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-11 23:31 ` Bart Schaefer 2022-02-12 3:39 ` Ray Andrews @ 2022-02-22 3:58 ` Matthew Martin 1 sibling, 0 replies; 20+ messages in thread From: Matthew Martin @ 2022-02-22 3:58 UTC (permalink / raw) To: zsh-users On Fri, Feb 11, 2022 at 03:31:08PM -0800, Bart Schaefer wrote: > On Fri, Feb 11, 2022 at 8:00 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > > Yeah, resources are out there if you just beat the bushes long enough. > > But how about if it were all collated and condensed and > > brought in-house? > > Consensus is hard. For example, I personally I think tens of > thousands of lines of history is unnecessary no matter how much RAM > you have to throw at it. > > The other question that constantly arises is whether the goal is to > make the shell more helpful out of the box for relatively > knowledgeable users, or to make it more attractive to newbies. If the > latter, is the most important thing to give it a flashy appearance? > In either case, where do you draw the line to "get you to 90%"? For shell configuration in particular consensus seems particularly thorny because each user has their own opinions on what's sane. Rather than try to come up with some sane default config, I think zsh-newuser-install goes in the right direction; however, it seems nearly all new users find it intimidating. I've taken a stab at a newuser like wizard but as a webpage to hopefully make it more approachable https://storage.googleapis.com/zsh-guide/index.html If people like it, I can put it on a real domain. The idea is to just be good enough to not need a framework and get running in 5 minutes or so. For what to include I looked at zsh-newuser-install, oh my zsh, zsh4humans, and zsh-sensible. The repo is at https://github.com/phy1729/zsh-guide . ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-11 15:59 ` Ray Andrews 2022-02-11 23:31 ` Bart Schaefer @ 2022-02-12 16:45 ` Thomas Lauer 2022-02-12 17:48 ` Ray Andrews 1 sibling, 1 reply; 20+ messages in thread From: Thomas Lauer @ 2022-02-12 16:45 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users > From: Ray Andrews <rayandrews@eastlink.ca> > > On 2022-02-11 06:58, Thomas Lauer wrote: > > > I'm a Windows refugee as well but over there I've used a command > > processor called Take Command (the former 4NT) > 4DOS and Take Command ruined me. I got to just taking for granted that > level of > polished perfection and when I moved over here, the culture shock > nearly killed me. Interesting. Take Command *was* (or is) powerful but IMO it's no match for zsh. I happily invested a lot of time investigating zsh and its options because I found many things immediately appealing. > On 2022-02-11 15:31, Bart Schaefer wrote: > > > > Consensus is hard. For example, I personally I think tens of > > thousands of lines of history is unnecessary no matter how much RAM > > you have to throw at it. > I picked that line almost at random. Thinking about it, mine probably > is too big. > Point is that some reasonable amount of history is something that almost > everyone > wants. I am with Bart on this one. Many so-called "defaults" in all sorts of software, including zsh, are far removed from what I find reasonable (or at least work-flow enhancing). The whole point of "optionising" features is to give people choice. But with that comes of course a learning curve and some responsibility for the choices one makes. Tom ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: zsh function breaks after error 2022-02-12 16:45 ` Thomas Lauer @ 2022-02-12 17:48 ` Ray Andrews 0 siblings, 0 replies; 20+ messages in thread From: Ray Andrews @ 2022-02-12 17:48 UTC (permalink / raw) To: zsh-users On 2022-02-12 08:45, Thomas Lauer wrote: > > Interesting. Take Command *was* (or is) powerful but IMO it's no match > for zsh. Indeed not. Zsh is 'bigger' and more powerful in every way, but also less consistent. To some degree this is inevitable and quite forgivable. Projects that grow by accretion must encounter this sort of thing and solutions are far from simple. I am with Bart on this one. Many so-called "defaults" in all sorts of > software, including zsh, are far removed from what I find reasonable (or > at least work-flow enhancing). The whole point of "optionising" features > is to give people choice. But with that comes of course a learning curve > and some responsibility for the choices one makes. Sure, so my notion of several different default configurations gives you several possible starting points, and then invites you and helps you to start customizing. The difference is that instead of starting from 'zero', you're starting from one of a suite of configurations that are considered reasonable by real users. And of course the 'zero option' would be there as well so all of the above can be ignored as desired. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2022-02-22 4:04 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-02-08 17:16 zsh function breaks after error Thomas Lauer 2022-02-09 15:18 ` Bart Schaefer 2022-02-09 18:45 ` Thomas Lauer 2022-02-09 20:16 ` Bart Schaefer 2022-02-10 13:55 ` Thomas Lauer 2022-02-10 13:59 ` Roman Perepelitsa 2022-02-10 16:20 ` Thomas Lauer 2022-02-10 16:48 ` Roman Perepelitsa 2022-02-10 17:20 ` Thomas Lauer 2022-02-10 21:26 ` Ray Andrews 2022-02-10 21:45 ` Thomas Paulsen 2022-02-10 23:37 ` Daniel Shahaf 2022-02-11 15:07 ` Thomas Lauer 2022-02-11 14:58 ` Thomas Lauer 2022-02-11 15:59 ` Ray Andrews 2022-02-11 23:31 ` Bart Schaefer 2022-02-12 3:39 ` Ray Andrews 2022-02-22 3:58 ` Matthew Martin 2022-02-12 16:45 ` Thomas Lauer 2022-02-12 17:48 ` Ray Andrews
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).