todo.sr.ht

#287 Crash when running :pipe -m less 4 months ago

git.sr.ht/~rjarry/aerc/commands/msg.Pipe.Run.func5() git.sr.ht/~rjarry/aerc/commands/msg/pipe.go:214 +0x1e1

It seems that the message info contains a nil envelope.

Line 214 in pipe.go only checks for a nil message info but not for a nil envelope before accessing info.Envelope.Subject. A nil envelope can occur when the backend cannot read or parse the message.

#281 Unable to open local `mbox` files 5 months ago

Comment by ~konimarti on ~rjarry/aerc

A possible approach could be:

extract the url.Parse logic into a separate function that returns the path to the file (you can add test for this function)
if the returned path starts with '~', expand it

The body of the extracted function could look like this:

{
       var path string

       u, err := url.Parse(s)
       if err != nil {
               return path, err
       }

       if u.Host == "" {
               path = u.Path
       } else {
               path = filepath.Join(u.Host, u.Path)
       }

       if path == "" {
               path = u.Opaque
       }

       return path, err
}

#281 Unable to open local `mbox` files 5 months ago

on ~rjarry/aerc

On Sat Oct 12, 2024 at 8:07 PM IST, ~konimarti wrote:

the url.Parse command will parse the source string into different variables depending on the scheme prefix, i.e either 'mbox:' or 'mbox://'

url.Parse("mbox://~/mbox") will parse the path into url.Host and url.Path (this is currently expected to work correctly); however, when using url.Parse("mbox:~/mbox", without the '//') it will parse the path into url.Opaque.

Yes!! I just found out what was happening and was composing the email about it and your email arrived.

Essentially this if block here is not being executed as u.Host is not ~ but instead is just nothing. But If I do aerc mbox:/Users/user/mbox though it works fine as u.Path contains this absolute path and the else block manages to set correct value for dir.

File: worker/mbox/worker.go
var dir string
		if u.Host == "~" {
			home, err := os.UserHomeDir()
			if err != nil {
				reterr = err
				break
			}
			dir = filepath.Join(home, u.Path)
		} else {
			dir = filepath.Join(u.Host, u.Path)
		}
a robust fix would make both schemes work How can I solve this?

#281 Unable to open local `mbox` files 5 months ago

Comment by ~konimarti on ~rjarry/aerc

I was just about to send a fix to the mailing list when I saw that you would want to work on this issue yourself.

Here is some guidance:

the url.Parse command will parse the source string into different variables depending on the scheme prefix, i.e either 'mbox:' or 'mbox://'

url.Parse("mbox://~/mbox") will parse the path into url.Host and url.Path (this is currently expected to work correctly); however, when using url.Parse("mbox:~/mbox", without the '//') it will parse the path into url.Opaque.

a robust fix would make both schemes work

#224 Recursive parsing of attached messages 1 year, 1 month ago

on ~rjarry/aerc

On Fri Feb 02, 2024 at 11:41, ~mcepl outgoing@sr.ht wrote:

On Fri Feb 2, 2024 at 11:02 AM CET, ~konimarti wrote:

Don't you already see a suggestion to open the rfc822 message with :eml. I get this option list on master for message/rfc822 attachments:

I don’t have m there, but that could be probably easily fixed in the configuration.

I have started to play with Bence’s https://github.com/ferdinandyb/caeml and it looks pretty reasonable. Unfortunately, when replying to the shown message I get raw unencoded message to reply to, which is a little bit less useful.

I wonder why that happens? Oh right, if you reply to a picture attachment you would also get the raw image. This is a general property with parts. I guess you can use caeml to view and if you do want to reply, :eml (after Koni's new patch is applied).

#224 Recursive parsing of attached messages 1 year, 1 month ago

Comment by ~konimarti on ~rjarry/aerc

On Fri Feb 2, 2024 at 11:41 AM CET, ~mcepl wrote:

I don’t have m there, but that could be probably easily fixed in the configuration.

Apologies, you're right. m is not in the default binds.conf. You just see the line without the m key. I have m = :eml<Enter> in the [view] section of my binds.conf.

#224 Recursive parsing of attached messages 1 year, 1 month ago

on ~rjarry/aerc

On Fri Feb 2, 2024 at 11:02 AM CET, ~konimarti wrote:

Don't you already see a suggestion to open the rfc822 message with :eml. I get this option list on master for message/rfc822 attachments:

I don’t have m there, but that could be probably easily fixed in the configuration.

I have started to play with Bence’s https://github.com/ferdinandyb/caeml and it looks pretty reasonable. Unfortunately, when replying to the shown message I get raw unencoded message to reply to, which is a little bit less useful.

#224 Recursive parsing of attached messages 1 year, 1 month ago

Comment by ~konimarti on ~rjarry/aerc

Don't you already see a suggestion to open the rfc822 message with :eml. I get this option list on master for message/rfc822 attachments:
  O       Open using the system handler  :open<enter>
  S       Save to file                   :save<space>
  |       Pipe to shell command          :pipe<space>
  m       View message attachment        :eml<Enter>
So you should be able to just press m to view the attached message in a new message viewer tab?

#227 after opening a message with :eml, we should be able to reply to it 1 year, 1 month ago

~konimarti assigned ~konimarti to #227 on ~rjarry/aerc

#219 regression: after archive the next selected message is the last message in the folder 1 year, 1 month ago

Comment by ~konimarti on ~rjarry/aerc

On Sat Jan 27, 2024 at 1:57 AM CET, ~elshize wrote:

This actually doesn't happen for me with :archive but it it does on :mv Trash. Also using maildir, glanced over recent commits but nothing obvious (to me) jumped out.

I can also reproduce with :mv Trash on maildir.

Bisected to this recent commit:

commit 40c25caafd583d4ee6ab3f5b318306e534abe480 Date: Mon Jan 22 20:46:54 2024 +0100
mv: allow to move messages across accounts