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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).