by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    tunabot
    @tunabot
    Abdulrahman Hamdy joined chat
    tunabot
    @tunabot
    [muesli] hm, do we really need a second dev channel already?
    Adam Schwalm
    @ALSchwalm
    @xiaq, I submitted #430 yesterday. I've been looking at your suggestions and I have some questions
    tunabot
    @tunabot
    [xiaq] @ALSchwalm Hi! Happy to answer to questions
    Adam Schwalm
    @ALSchwalm
    Specifically, what are you thinking the return type would be if the callback is passed the list of all candidates. I would think the list of filtered candidates, but I think that won't work. If some of the candidates are actually complex and have the same stem but different suffixes, we wouldn't be able to tell them apart
    tunabot
    @tunabot
    [xiaq] you can pass the actual candidate objects instead of text, and require the matcher to do extra work
    [xiaq] one inconvenience here is that edit.candidate does not implement Value yet
    Adam Schwalm
    @ALSchwalm
    Yeah, that was my problem there
    tunabot
    @tunabot
    [xiaq] but suppose that it is, and you can use $x[code] to access the edit.candidate.code
    [xiaq] then a matcher will look like this: [pattern]{ each [x]{ if (has-prefix $x[code] $pattern) { put $x } } }
    [xiaq] another option is to pass the matcher texts, and expect boolean outputs
    Adam Schwalm
    @ALSchwalm
    That was what I was planning on. I can do that and then go back and add the Value implementation for candidate and see how that works out
    If that sounds good to you
    tunabot
    @tunabot
    [xiaq] well, if you pass the matcher texts and expect booleans, you don't actually need to implement Value for candidate :)
    Adam Schwalm
    @ALSchwalm
    Yeah, I mean I would go back and switch things over to passing/returning candidates later.
    Though if we pass/return candidate then we would pay the cost of 'cooking' all the candidates; even those that were filtered later, right?
    I don't know how expensive that is
    tunabot
    @tunabot
    [xiaq] that's right, and it seems that passing texts and expecting bools is a better idea to me now.
    Adam Schwalm
    @ALSchwalm
    Alright, I'll do that then. Thanks
    tunabot
    @tunabot
    [xiaq] filtering raw candidates also have the benifit that you have access to the un-suffixed text simply via its text() method
    [xiaq] but on a related note, i am not sure whether this suffixing is actually a good idea.
    [xiaq] anyway, i hope it's clear to you what to do :)
    Adam Schwalm
    @ALSchwalm
    Yep, I'll submit a PR tonight or tomorrow
    tunabot
    @tunabot
    [xiaq] and thank you for contributing ;)
    Adam Schwalm
    @ALSchwalm
    No problem. It's a great project
    tunabot
    @tunabot
    [xiaq] i'm glad that you like the project. admittedly much of the code around the editor is somewhat messy, and i appreciate that you dived into the code :)
    tunabot
    @tunabot
    [ln_nl] (unsupported message type)
    tunabot
    @tunabot
    🐡 xiaq has been thinking about changing the syntax for argument list of lambdas
    [xiaq] i particularly don't like the fact in [a b c]{ ... } there must be no space between ]{
    [xiaq] i am also thinking about supporting docstrings as part of the syntax. that's also something to consider if we want to change the lambda syntax.
    tunabot
    @tunabot
    lostsummer joined chat
    tunabot
    @tunabot
    [xiaq] Test fishroom
    Kurtis Rader
    @krader1961
    What is the rationale for Elvish behaving as if the equivalent of doing set -o errexit in bash/zsh/ksh is always in effect? That is the only behavior that will keep me from using Elvish on a daily basis and contributing to its development given my reading of the documentation and experimenting with the implementation for a few days. Simply running a command like grep that might return a non-zero exit status for a non-fatal reason (e.g., nothing matched the pattern) should not be a fatal error by default. It is unreasonable to be required to wrap every command of thaat nature in a try { command } except { } block.
    Kurtis Rader
    @krader1961
    Also, I've read the "unique semantics" document. Specifically the section "Exit Status and Exceptions". The problem is it says "Elvish has no concept of exit status". Then goes on to say that an external commands non-zero exit status is turned into an exception. Which is okay if explicitly enabled but should not be the default behavior.
    tunabot
    @tunabot
    [xiaq] krader1961, do you propose to make it an option whether to treat non-zero exit status as exception?
    tunabot
    @tunabot
    [xiaq] If so: no. External command interaction is a fundamental shell feature, and it is a sign of poor design to make such fundamental semantics customizable. We can think about how to document it better, how to make it more ergonomic. Or getting rid of it. But making it customizable solves no problem
    Kurtis Rader
    @krader1961
    I am not sure how to deal with this. The same discussion has occurred in the Fish shell project. What I do believe, quite strongly, is that a non-zero exit status of an external command should not be a fatal error by default. There are too many commands which exit with a non-zero status that do not indicate a fatal error.
    The canonical example being grep but it is by no means the only example.
    If I write a elvish script that invokes such commands it is unreasonable to require me to wrap every invocation in a try { } except { } block.
    tunabot
    @tunabot
    [xiaq] There is a more lightweight ?() syntax for capturing exceptions, which include non-zero exit status
    Kurtis Rader
    @krader1961
    Note that Elvish builtins and functions can be exempted from this although I don't see a good reason to do so. Since builtins and functions can explicitly raise an exception rather than simply exit with a non-zero status.
    tunabot
    @tunabot
    [xiaq] krader1961, elvish functions do not have exit status
    Kurtis Rader
    @krader1961
    So you expect every invocation of an external command in a Elvish script which might return a non-fatal non-zero status to be wrapped like this: ?(echo abc | grep def)?
    And that doesn't even work unless you do it in the context of something like if ?(echo abc | grep a) { ... }.
    tunabot
    @tunabot
    [xiaq] It depends on your intention when using grep. There are two typical uses: one is for determining whether a string occurs, as in “if some-cmd | grep -q xxx” (this is posix sh). In that case, you can simply wrap it inside ?()
    [xiaq] Another is filtering lines that contain a string. In that case you need to suppress the exception when grep finds no match and exits with 1. I have long wanted to provide a syntax for that but you see I am really lazy :)
    [xiaq] AFAIK, most commands exit with 1 on non-fatal errors, and it would be nice to be able to suppress such errors.
    tunabot
    @tunabot
    [xiaq] I do not want to burden the user with the overhead of explicitly handling non-fatal errors; in this aspect our goals are aligned. But I also do not want any fatal error to go unnoticed.
    Russell
    @miller-time

    I'm having trouble defining an edit:arg-completer for git. Here's what I've got in my rc.elv (basically just copied from the documented recipe):

    # git branch completion
    all-git-branches = [(e:git branch -a --format="%(refname:strip=2)" | eawk [0 1 @rest]{ put $1 })]
    
    edit:arg-completer[git] = [args]{
      n = (count $args)
      if (eq $n 2) {
        put st co rebase stash
      } elif (ge $n 3) {
        put $@all-git-branches
      }
    }

    my git commands sometimes will do filename completion, but other than that all I get is the "unsupported completion :(" message

    Russell
    @miller-time
    sorry, probably wrong room. posted in elvish-public