Skip to content
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

Derive default enter-separator from previous split-cells #2197

Closed
katrinleinweber opened this issue Oct 15, 2019 · 3 comments
Closed

Derive default enter-separator from previous split-cells #2197

katrinleinweber opened this issue Oct 15, 2019 · 3 comments
Assignees
Labels
Module: Frontend These issues involve working on HTML, CSS, and JavaScript code that affects the user interface. Type: Feature Request Identifies requests for new features or enhancements. These involve proposing new improvements.
Milestone

Comments

@katrinleinweber
Copy link
Contributor

katrinleinweber commented Oct 15, 2019

Is your feature request related to a problem or area of OpenRefine? Please describe.
I'm always frustrated when the "Join multi-valued cells" prompt suggests , to me, even though:

  1. I used a different symbol in the previous "Split multi-valued cells" operation, and
  2. the , is present at least in some of the still split cells.

Describe the solution you'd like
Would both operations be more convenient & less error-prone if OpenRefine:

a) derived the default character from 1. or at least,
b) not suggested a symbol for which 2. was true?

Describe alternatives you've considered
I'm not sure.

Additional context
Related to #1113 & #2139.

@wetneb
Copy link
Sponsor Member

wetneb commented Oct 16, 2019

For 1., we could consider storing the last value used for the Join/Split operations in the preferences, and propose that as default value in both dialogs.

@ostephens
Copy link
Sponsor Member

Either using the last value as the default or being able to set a default value in preferences would be approaches that worked for me (I always have to change this, and it's always a pain!)

Resolving issue (2) is more problematic - I don't think we can predict what the user wants to do here (maybe they specifically do want to use that separator even though it is in the cells already) and checking all values in the column for a separator character is likely to lead to performance problems for large projects.

So my vote would be to put (2) aside for the moment and focus on solving (1)

@wetneb wetneb added Type: Feature Request Identifies requests for new features or enhancements. These involve proposing new improvements. Module: Frontend These issues involve working on HTML, CSS, and JavaScript code that affects the user interface. labels Oct 16, 2019
@lisa761 lisa761 self-assigned this Apr 3, 2020
@wetneb
Copy link
Sponsor Member

wetneb commented Jun 25, 2020

Given @ostephens' comment above let's say that point 2. is out of scope because heuristics are likely to be flaky. So this is closed by #2520.

@wetneb wetneb closed this as completed Jun 25, 2020
@wetneb wetneb added this to the 3.5 milestone Jun 25, 2020
@wetneb wetneb mentioned this issue Apr 24, 2021
16 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Module: Frontend These issues involve working on HTML, CSS, and JavaScript code that affects the user interface. Type: Feature Request Identifies requests for new features or enhancements. These involve proposing new improvements.
Projects
None yet
Development

No branches or pull requests

4 participants