From: Junio C Hamano <gitster@pobox.com>
To: Aditya Garg <gargaditya08@live.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
Eric Sunshine <sunshine@sunshineco.com>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
Ben Knoble <ben.knoble@gmail.com>,
"brian m . carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH] imap-send: add option to mark sent messages as read or unread
Date: Wed, 23 Jul 2025 10:25:42 -0700 [thread overview]
Message-ID: <xmqqecu6om3t.fsf@gitster.g> (raw)
In-Reply-To: <7108764f437a25079c95a25c227eb79f9f4aee6a.1753273554.git.gargaditya08@live.com> (Aditya Garg's message of "Wed, 23 Jul 2025 12:29:10 +0000")
Aditya Garg <gargaditya08@live.com> writes:
> +imap.markAsRead::
> + Choose whether to mark the sent message as read or not.
Is this something user typically want to use a single setting,
or would it often be per invocation? Especially with the new
invoker in send-email, wouldn't it become more like "if I use
imap-send to stuff things in my outgoing folder, they shouldn't be
marked as read, but fcc copies send-email stuffs via imap-send
should be marked as read" or something like that?
> + Default is `true`.
If we never marked these messages as read, then this default is a
breaking change, isn't it?
> @@ -47,11 +47,12 @@
>
> static int verbosity;
> static int list_folders;
> +static int mark_seen = 1;
IOW, this smells problematic.
> + if (mark_seen) {
> + ret = imap_exec_m(ctx, &cb, "APPEND \"%s%s\" (\\Seen) ", prefix, box);
> + } else {
> + ret = imap_exec_m(ctx, &cb, "APPEND \"%s%s\" ", prefix, box);
> + }
Why so many braces around single-statement blocks?
> @@ -1702,6 +1710,12 @@ static int curl_append_msgs_to_imap(struct imap_server_conf *server,
> curl_easy_setopt(curl, CURLOPT_READFUNCTION, fread_buffer);
> curl_easy_setopt(curl, CURLOPT_UPLOAD, 1L);
>
> + if (mark_seen) {
> + curl_easy_setopt(curl, CURLOPT_UPLOAD_FLAGS, CURLULFLAG_SEEN);
> + } else {
> + curl_easy_setopt(curl, CURLOPT_UPLOAD_FLAGS, 0L);
> + }
> +
Why so many braces around single-statement blocks?
According to
https://github.com/curl/curl/blob/master/docs/libcurl/symbols-in-versions
CURLULFLAG_SEEN first appeared in 8.13.0; INSTALL says we require 7.61.0
or later, so this may be OK.
next prev parent reply other threads:[~2025-07-23 17:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-23 12:29 [PATCH] imap-send: add option to mark sent messages as read or unread Aditya Garg
2025-07-23 17:25 ` Junio C Hamano [this message]
2025-07-23 17:33 ` Aditya Garg
2025-07-23 17:35 ` Aditya Garg
2025-07-23 17:56 ` Junio C Hamano
2025-07-23 18:00 ` Aditya Garg
2025-07-23 17:55 ` Junio C Hamano
2025-07-23 17:52 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2025-07-23 15:45 Aditya Garg
2025-07-23 17:46 ` Junio C Hamano
2025-07-23 17:49 ` Aditya Garg
2025-07-23 17:55 Aditya Garg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqecu6om3t.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=gargaditya08@live.com \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.