This patch sets up the trigger config section of aerc.conf.
Each trigger has its own function which is called from the place where
it is triggered. Currently only the new-email trigger is implemented.
The triggers make use of format strings. For instance, in the new-email
trigger this allows the user to select the trigger command and also the
information extracted from the command and placed into their command.
To actually execute the trigger commands the keypresses are simulated.
Further triggers can be implemented in the future.
Formatting of the command is moved to a new package.
This command allows the user to change tab by giving the tab name. This
can be tab completed too. The previous tab is stored in the tabs module
so that when a new tab is created it is still possible to go to the
previous one.
Normal invocation is :ct folder
Previous tab is :ct -
Allow users to add attachments to emails in the Compose view. Syntax is
:attach <path>, where path is a valid file. Attachments will show up in
the pre-send review screen.
A user may want to be able to see what mimetype they are viewing, so
that they can determine what program it may be opened in or for some
other reason.
The config option is under the [viewer] section and is called
'always-show-mime'. It defaults to false to preserve the current
behaviour.
This patch adds the currently pressed keys to the statusline. This is
useful when keybindings are multiple keys long and you might forget
which keys are already pressed.
This introduces a new interface `Clickable`. I'd imagine this would be
implemented for most widgets eventually and would allow for programs run
in the terminal to also have their mouse events forwarded to them.
For the tabs it was relatively simple to check that the position of the
click is within the boxes for the tabs. For other components I'd imagine
that some state representing their currently drawn bounding box would be
useful.
This allows users to use backtab (Shift+tab) to go back through the
fields in the tutorial, like C-K. This then mimics the other methods in
having a forward and backward variant.
Also documented this in the wizard help paragraph.
Before, we were using several IMAP-specific concepts to represent
information being displayed in the UI. Factor these structures out of
the IMAP package to make it easier for other backends to provide the
required information.
Before, the information needed to display different parts of the UI was
tightly coupled to the specific messages being sent back and forth to
the backend worker. Separating out a models package allows us to be more
specific about exactly what a backend is able to and required to
provide for the UI.
Assuming we always have a sorted dirlist
(other code depends on that already), we don't need to loop over the
dirStore.
Any filtering done should be performed elsewhere
Because editors like vim use backupfiles and rename them to the original
name, the file handle used can point to the wrong file. Reopening the
file should fix this.
Many email providers use the imap sub-domain for imap and the smtp
sub-domain for smtp. FastMail is an example of this[1]. This is a small
quality-of-life improvement which automatically replaces imap.* with
smtp.* when going from the imap screen to the smtp screen in the wizard
[1]: https://www.fastmail.com/help/technical/servernamesandports.html
This implements selecting the most preferred mimetype under the
'View->Alternatives' configuration setting when viewing a message.
Mimetypes in the alternatives array are weighted by their position,
where the lower the index in the array the higher the priority, so this
is taken into account during selection.
If no message part matches a mimetype in the alternatives array, then it
selects the first mimetype in the message.
Adds an archive command that moves the current message into the folder
specified in the account config entry.
Supports three layouts at this point:
- flat: puts all messages next to each other
- year: creates a folder per year
- month: same as above, plus folders per month
This also adds a "-p" argument to "cp" and "mv" that works like
"--parents" on mkdir(1). We use this to auto-create the directories
for the archive layout.
Consists of 3 functions
* Store: Access to MessageStore type
* SelectedAccount: Access to Account widget that the target widget
belongs to
* SelectedMessage: Current message (selected in msglist or the one we
are viewing)
Signed-off-by: Kevin Kuehler <keur@ocf.berkeley.edu>
Prevents the program from panicing when changing folders too quickly.
onMessage can race store creation for an AccountView.
Signed-off-by: Kevin Kuehler <keur@ocf.berkeley.edu>
vterm.Write and vterm.SetSize race when the window resizes, which
causing the underlying library to segfault.
Signed-off-by: Kevin Kuehler <keur@ocf.berkeley.edu>
* :save takes a path and saves the current message part to that location
* :pipe is the same as pipe on the account page, but uses the current
message part rather than the whole email (ie :pipe gzip -d)
* Refactored account:pipe and extracted common pipe code to
commands.util.QuickTerm
* Added helper command aerc.PushError
This commit introduces a new Aerc.Tick function that should be called to
refresh the internal state. This in turn makes each AccountView process worker
events.
The UI goroutine repeatedly refreshes the internal state before drawing a new
frame. The reason for this is that many worker messages may need to be
processed for a single frame, and drawing the UI is far slower than refreshing
the internal state. This has been confirmed in my testing (calling Aerc.Tick
only once per frame results in a slower display).
Many synchronization code has been removed. We can now write widgets without
having to care so much about races. The remaining sync users are:
- widgets/spinner: the spinner value is updated from inside an internal
goroutine
- lib/ui/invalidatable: Invalidate may be called from any goroutine
- lib/ui/grid: same
- lib/ui/ui: an internal goroutine needs read access to UI.exit
- worker/types/worker: Worker.callbacks is used for both worker and UI
callbacks
The exact goroutine requirements for Drawable have been documented.
