Gnus development mailing list
 help / color / mirror / Atom feed
From: Michael Welsh Duggan <md5i@md5i.com>
To: ding@gnus.org
Subject: Multiple uploads with sieve-manage-mode (unexpected behavior)
Date: Sun, 02 Jan 2011 22:22:23 -0500	[thread overview]
Message-ID: <87fwtau0wg.fsf@maru.md5i.com> (raw)

I have run into the following small niggling problem with
sieve-manage-mode.  If you select the active sieve script, edit it, and
then upload it (with `C-c C-c'), everything works as expected.  But
let's say that we find we find a bug in our updated script.  So, we go
back to the sieve-manage buffer, and select the script again, edit the
result, and then upload the fixed script with `C-c C-c' again.  If you
do this, you will find that the uploaded script will not be the active
sieve script.  Why?

Actually, it took me longer than it should have to figure out what was
happening here.  Let's say, for sake of argument, that the name of the
active sieve script is "sieve.siv".  After the first upload, the
"sieve.siv" buffer is buried.  When you select the active script in the
sieve manager again, the sieve-edit-script function uses
generate-new-buffer to create the buffer name.  In this case, since the
original "sieve.siv" buffer was buried, it will create a new buffer
called "sieve.siv<2>".  When this gets uploaded (with `C-c C-c'), it
gets added as a new script called "sieve.siv<2>", which is not active by
default (because there is already an active script).  Expected behavior
would have been to replace the existing active "sieve.siv" script.

Now, I am not certain what the appropriate remedy should be.  One would
be to re-use the original buffer with the same name (perhaps asking
whether that is appropriate beforehand).  Another would be to save the
sieve script name in a buffer-local variable, and only use the buffer
name if this variable is nil.  No matter what solution is chosen,
though, something should be modified, as the current behavior is
unexpected, and it is not necessarily immediate obvious what is
happening incorrectly.

-- 
Michael Welsh Duggan
(md5i@md5i.com)



             reply	other threads:[~2011-01-03  3:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <RT-Ticket-657185@rt.gnu.org>
2011-01-03  3:22 ` Michael Welsh Duggan [this message]
2011-01-04  0:24   ` Lars Magne Ingebrigtsen
2011-01-04  3:50     ` Michael Welsh Duggan
2011-01-11 19:33       ` Lars Magne Ingebrigtsen
2011-01-25  0:44         ` Michael Welsh Duggan
2011-01-25  0:46           ` Lars Ingebrigtsen
2011-01-25 10:12             ` Julien Danjou
2011-01-25 10:21               ` Lars Ingebrigtsen
2011-04-07 21:47         ` [gnu.org #657185] " Donald R Robertson III via RT
2011-04-07 22:24           ` Michael Welsh Duggan
     [not found]             ` <rt-3.4.5-9131-1302215081-1690.657185-6-0@rt.gnu.org>
2011-04-08 19:51               ` Donald R Robertson III via RT

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=87fwtau0wg.fsf@maru.md5i.com \
    --to=md5i@md5i.com \
    --cc=ding@gnus.org \
    /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).