Comments (15)
My current idea is to add a section in the config with the complete list of labels. If this is present, then it is synced with the Gmail settings. To ease the migration I can also extend the download
functionality. Perhaps the color can come at a later stage, but it should be easy to add.
from gmailctl.
Not exactly related, but close: Suppose I already have a label foo
and filters that apply this label. Is there any way to change the label name to bar
more simply than:
- On the web UI, rename the label
- In my gmailctl config, rename any instance of the label (hopefully I put it in a variable name if it’s the sort of thing I thought I might rename)
- Verify that
gmailctl diff
is empty
I don’t think there is, and I'm having trouble even coming up with a way to potentially simplify the process, but if there is one I haven’t thought of I’d like to know.
from gmailctl.
So, this issue is nice to have indeed, but you run into all sorts of problems if you want to do it properly, and that's why I decided to put it off for now.
As @dhouck pointed out, renaming by hand is painful, but how do you know if a label has been added vs. renamed? This could open a can of worms.
Perhaps the only proper way to do it would be to completely take over the labels management, and add a new section of the config specifically for them. This is however quite some work and it also involves a change of the config format.
from gmailctl.
The minimal implementation, where it simply creates the label specified in the configuration, and lets the user deal with complexities such as removing them, renaming them, etc, seems like a useful single step to me.
Opt-in, if you are concerned people expect an mind-reading-complete version, but I'm comfortable that I shouldn't run gmailctl while messing around with labels on the gmail side – and that I can't expect gmailctl to reverse-engineer those changes and apply them to the jsonnet source.
I'm way too familiar with "properly or not at all", but I'm trying for more pragmatism these days, and this'd be the pragmatic step one toward a proper solution.
from gmailctl.
The problem is not implementing features incrementally, it's with surprising features. If you rename something in the config, it's now reflected correctly to the Gmail settings. If you implement the label create feature as you suggest, renaming a label in the config will just create another, and assuming a filter is targeting that label, old mails will remain in the old label, while new ones will be in the new. A user expects a rename, while they are getting two labels. This is surprising. Funny thing is that to fix this they'll have to go to the UI, delete the new label and rename the old one. Another problem is that typos will translate in new (unwanted) labels, that could mess up your inbox in subtle ways.
I however realize that when you are building your config from scratch you have to create a lot of labels from the UI, and that's annoying. I'll keep this open since it's a nice to have. Maybe I'll find a nice way to make this not surprising or error prone, and so could be done.
from gmailctl.
I however realize that when you are building your config from scratch you have to create a lot of labels from the UI, and that's annoying.
I'm not, and I don't expect the rename, but I'll also own this: when I design UI and UX, it produces results that only a software developer could love, so I'm not going to claim that other people would have the same expectations.
I'll think about this, too, and see if I can figure something else out. I understand and respect your position, and declining the partial implementation on that basis.
from gmailctl.
I think the only way to do this sensibly is twofold:
- When trying to apply a config, if there are missing labels, output something like
Label "foo" does not exist. Create it? [Yn]
, possibly showing the relevant portion of the config first. If no, abort reconfiguration.-
Optional typo detection:
Label "foo" does not exist. The most similar labels are: - fog - food - fool - goo Create label "foo"? [yN]
(No, I don’t know why this hypothetical person has a label for goo-related emails)
This would help prevent users going "Yes I want that label; I thought I already created it" and then accidentally having two labels, but AIUI actually fixing the configuration would still need to be done manually.
-
- Add another command, say
gmailctl label
, with subcommandscreate <name>
andedit <old_name> [--rename <new_name>]
.- Optionally, this command could also support other options to
gmailctl label
, like--text-color
,--background-color
,--label-visibility=(show|hide|if-unread)
, and--message-visibility=(show|hide)
. Those might be a bit beyond the scope of the program, though, and are definitely less useful features than the core creating/renaming labels. - If you don’t want to support any sort of label managing beyond the basic create/rename, then the syntax
gmailctl label edit <old_name> --rename <new_name>
is a bit cumbersome andgmailctl label rename <old_name> <new_name>
might be preferable..
- Optionally, this command could also support other options to
This way you don’t need to switch between the GMail web UI and command line, and it still has adequate typo prevention.
from gmailctl.
@dhouck This sounds reasonable. We could have a bit of a problem showing this when multiple labels are added, but this looks like a starting point.
Perhaps this issue should be split in two:
- the
label
command as described - the auto-create for the labels. Maybe also guarded behind a flag as @slippycheeze previously suggested. Something like
gmailctl (edit|apply) --create-missing-labels
from gmailctl.
Just chiming in that this feature would indeed be lovely to have. As a previous inbox user that got burned by its turndown, I really want to recreate something approaching bundles, but my idea for how to do so involves generating a lot of labels in pairs (e.g. "foo" and "foo (done)"), which is painful to do manual. Having auto label creation would allow me to finally get around to doing this cleanup, whereas currently gmail is choking on my labels containing very large numbers of emails. Bonus points if the labels could be entirely config-based for showing/hiding, etc, but I think it wouldn't be too painful to do that manually in the UI once I'd created everything
from gmailctl.
I agree that this is important. I'll get to it eventually, but instead of making an incomplete solution I would prefer to make the thing 100% declarative. My own bad experiences tell me that half-baked solutions tend to give birth to all sorts of scripts and workarounds client side...
from gmailctl.
Perhaps the error prone situation of a label rename can be successfully detected and prevented. Before doing any changes I can check for every label if:
- the label has been removed from the config, and
- the label contains messages (the APIs return this information)
Then this was either a rename or a removal. Since we don't know what to do, we should fail with a message and suggest to either:
- Remove all the messages from the label, if a delete was intended, or
- Rename the label manually in the Gmail UI, if that was the intention.
If the label instead didn't contain messages, then we can safely delete it.
from gmailctl.
Auto-creation could also be solved with complete list of labels approach suggested by @mbrt by having a jsonnet helper function that iterates over rules and generates a set of labels, something like:
labels: lib.allLabelsFromRules(rules),
// or
labels: ['manual', 'list', 'of', 'labels'],
from gmailctl.
@legeana Very good idea! This could be added to the library, so you don't have to maintain them manually.
The only caveat happens if you have labels that you apply manually (I do). In that case they won't appear in any filter and so you have to extend that list manually.
If someone wants to maintain the list completely manually (e.g. to protect themselves from typos in the label name), it's also possible.
Thanks for the suggestion!
from gmailctl.
you have to extend that list manually
I mean... labels: lib.allLabelsFromRules(rules) + ['manual', 'labels'];
=)
from gmailctl.
This has been a little bit more work than I wanted, but this feature should be basically complete in PR #68. README is also up to date there.
I did some unit testing and I tried it out with my own configs, but for sure it might still have some bugs. If someone wants to give it a try and give some feedback it would be really nice!
I will probably merge it next week.
from gmailctl.
Related Issues (20)
- A way to quickly apply changed filters to the existing emails HOT 1
- Is there a particular reason why isEscaped / isRaw cannot be used for cc / bcc? HOT 3
- VSCode Support HOT 2
- gmailctl should not try to create "INBOX" label HOT 6
- Tests fail with realistic inputs HOT 2
- Cant figure it out HOT 1
- Option for `gmailctl download` to "download" a local XML file HOT 2
- Add option to apply all parent labels if `gmailctl` is managing labels HOT 4
- `gmailctl` should interpret `Some/Label/Name` as a nested label HOT 3
- Consider editing repository setings to remove "Packages" section HOT 1
- Progress indicators HOT 4
- Token has been expired or revoked HOT 6
- Following flow for sorting mails possible? HOT 3
- Potential GMail bug causes exporting to XML not working with category action rules, workaround needed HOT 2
- Support diffing with colordiff/delta/etc HOT 4
- Why does gmailctl split this kind of "or" filter into separate rules? HOT 19
- Support `deliveredto` rule HOT 3
- Could libsonnet helper files be situated next to the tmp file for `gmailctl edit` to avoid import path errors? HOT 4
- Is it possible to programatically edit filters with gmailctl? HOT 2
- Expose a public API HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gmailctl.