← 输入框|github.com|刷新
Skip to content

Allow entering custom display formats #573

Closed

Description

@MKleusberg

See issue #569. It would be nice to be able to enter custom display formats in the Edit Display format dialog when the format you require isn't part of the list. Bonus points for remembering custom display formats and having an option to give them names etc.

There are two problems here though. Both requiring us to add some more error checking code:

  1. If the user types in some invalid code we'd get a syntax error. Not sure how we'd react there but we definitely don't display a proper error message.
  2. The user could type in some code that generates more than one column. This one is tricky because it doesn't produce a syntax error but would cause a lot of confusion throughout the application. So by some means we'd have to detect this case and prohibit it.

Activity

  1. jungle-boogie commented on Apr 22, 2016

    @jungle-boogie
    Contributor

    I first encountered the custom option when selecting one of the other available options (hex, octal, round number, etc) on a colum, and then going back to "edit display format". I noticed my selection was not what I previously selected (hex, octal, round number, etc), but rather it was "custom".

  2. justinclift commented on Apr 22, 2016

    @justinclift
    Member

    That's a good point, I've noticed that too. The label for the chosen option should probably be kept, instead of switching to "custom". 😄

  3. mgrojo commented on Nov 6, 2017

    @mgrojo
    Member

    I think, most of the custom formats, that the users would want to add, would be a call to the sfrtime, printf or similar format functions for the column (one example is in #1213). What if we only allow custom formats of this form, that could be easily validated using regexps? It would be at least an improvement over the current situation.

  4. justinclift commented on Nov 18, 2017

    @justinclift
    Member

    @mgrojo That sounds like a pretty decent concept. It also doesn't sound super complex to get working, though it could turn out to be trickier than expected (unsure though). 😄

  5. added a commit that references this issue on Jan 27, 2019
  6. mgrojo commented on Feb 15, 2019

    @mgrojo
    Member

    Closing this, as PR #1720 is already merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions