| Age | Commit message (Collapse) | Author |
|---|
|
Audio tail fix
|
|
|
|
|
|
|
|
|
|
|
|
* Update CHANGELOG with latest updates
* Update version string in docs
|
|
|
|
Previously executing `:AuditoryOn` and `:AuditoryOff` would always do
the thing they're supposed to do regardless of whether Auditory was
already on or off.
This caused errors because things got messed up when trying to
double assign the mappings and double unmap the mappings.
Now check for the status of the `g:auditory_on` flag before turning
Auditory on or off.
|
|
|
|
|
|
Pressing `G` would bring the cursor to the first line in the buffer
instead of the last line in the buffer because the count in the mapping
was always `v:count1`. This meant that the `G` mapping behaved like `1G`
when no count was specified.
This change fixes the `G` mapping to use `v:count` so that it goes to
the last line in the buffer as expected.
We also add support for arbitrary mappings to choose whether they want
to be `v:count` or `v:count1` depending on what value is specified in
the mapping dict.
|
|
|
|
* Update CHANGELOG
* Update version string in docs
|
|
|
|
|
|
|
|
Make the mappings dictionary global to allow it to be user-customisable.
This way users can add new commands or sounds to be mapped without
modifying the plugin directly. Seems like it could be useful.
|
|
Initial documentation for the plugin. Include general information as
well as descriptions of commands and configuration variables.
|
|
|
|
|
|
|
|
|
|
Delete some old code that isn't used any more. This was when I first
made the plugin. These functions were used to start a song when insert
mode was activated and stop the song on insert leave.
Since we're not playing full songs any more, and our insert sounds are
tied to key presses, these functions are no longer needed.
|
|
My change from 71ec214cdb8814ecb71c837bf947583fda54d37e caused Galaxy
Far Far Away sounds to be turned on any time you had
`g:auditory_galaxy_far_far_away` turned on, regardless of whether
`g:auditory_on` was also turned on.
Fix this because we never want sounds to play when `g:auditory_on` is
off.
We now rely on `auditory#AssignInsertMappings()` to know whether to use
Galaxy Far Far Away or default insert mode sounds.
Need to toggle `g:auditory_galaxy_far_far_away` in that function because
we're calling the toggle function so we need to set it to the opposite
of what we want.
In the future if we add more insert mode sounds we'll have to change
this structure around but it should work for now.
|
|
Adding a configuration variable for these sounds allows them to be
turned on by default without having to
`:AuditoryToggleGalaxyFarFarAway`, so if you prefer these sounds you can
enable them at the outset.
|
|
When using `:AuditoryToggle` in conjunction with `:AuditoryOn` or
`:AuditoryOff`, things would get messed up. This is because
`:AuditoryToggle` relies on `g:auditory_on` in order to know whether to
turn sounds on or off, but the variable was only getting set in
`auditory#ToggleMappings`, not in the functions that `:AuditoryOn` or
`:AuditoryOff` call.
Move the setting of the variable into `auditory#AssignMappings` and
`auditory#Unmap` so that the right thing will happen regardless of which
on/off/toggle commands you run.
|
|
* Create `auditory#ToggleMappings()` that turns sounds on if they're off
and off if they're on
* Create an `:AuditoryToggle` command that runs the toggle function in a
more user-friendly callable way
With a toggle command, turning Auditory on or off can be as simple as
hitting 1 custom mapping. With our previous `AuditoryOn` and
`AuditoryOff`, you would have to use 2 mappings: 1 for on and another
for off.
|
|
Realised that I don't need to explicitly check for 1, I can check
against true or false. Get rid of the explicit check to make this more
concise.
|
|
Don't heedlessly turn on sounds when the plugin is loaded. Instead, give
users a choice of whether or not sounds should be loaded when starting
Vim with a configuration variable that can be set in a user vimrc. By
default sounds are now off.
|
|
Create a new command to match `:AuditoryOff` that turns on mappings and
sounds. We'll need this because I'm going to make the plugin not enable
sounds by default. That will be controlled by a global variable. You'll
be able to turn the sounds on and off as you wish.
|
|
* Move the insert mode autocommand definition into a new function that
turns on insert mode sounds
* Create a function to turn off insert mode sounds
* Call these from our normal `AssignMappings` and `Unmap` functions so
we can turn all our sounds on and off in one fell swoop
|
|
Add support for unmapping a map from any mode where it was defined, not
just normal mode mappings from `auditory#Unmap()`.
|
|
Put our `d`, `v_d`, and `dd` mappings in the `s:mappings` dictionary so
that they get automatically activated and deactivated when our map and
unmap functions go through the dict.
This required some modifications to `auditory#AssignMappings()` to allow
it to accept `map_to` commands that don't have a preceding
`auditory#Play()` call (because in the case of our `d` mappings, the
audio is played inside the function they call.
Also ensure we're not adding a pipe to the command if there's no
preceding audio part.
|
|
|
|
If a user has defined:
nnoremap j gj
then when you press `j` with Auditory turned on, it should make the
sound and do `gj`.
Previously it did `j` instead. Now it does `gj`. No more blatant
disregard for user mappings.
|
|
Take out the `map_to` field for Auditory's mappings and instead do what
it needs to do in `AssignMappings`. Makes the code a bit more DRY.
We replace it where necessary with a `count` field that tells whether we
should `v:count1` the mapping.
|
|
New command that turns the plugin off by removing its mappings.
|
|
In `auditory#Unmap()`, after unmapping Auditory maps, remap user-defined
mappings.
Say you redefined `j` -> `gj`. When turning Auditory off, we would
previously just unmap `j`, resulting in `j` -> `j`. Now that we're
restoring user mapppings, `j` once again gets mapped to `gj`.
Also keep track of the mode that Auditory uses for its mappings when
storing a user-defined mapping so that we're only saving and restoring
them if they're defined in the mode used by Auditory.
User mappings get saved in `auditory#AssignMappings()`, or the function
that essentially turns on the plugin.
Fix the `if` condition that checks `if l:user_mapping`. This gave me a
lot of trouble because I needed to match it against emtpy string,
instead of a boolean condition. Use the proper condition to get it
actually working.
|
|
|
|
Unmaps all normal mode commands. This will be used to turn Auditory off.
We'll want to also turn custom user mappings back on in the process but
that's for a later commit.
|
|
Turns out I accidentally misspelled Mackenzie's name. Probably got
confused with his GitHub handle `denkerm`.
|
|
Refactor to operate on one mapping passed in as an argument instead of
the whole `s:mappings` dictionary. This will allow me to call the
function inside `auditory#AssignMappings` and avoid having 2 `for` loops
when 1 will suffice.
|
|
Get any mappings users have defined for the keys/commands that we use
for playing audio and store them in our `mappings` dictionary. This will
allow us to be friendly and have the keys do what users have defined
them to do instead of using the stock Vim actions for everything.
Storing these mappings will also allow us to easily restore user
mappings when we make a way to turn the plugin's sounds off by unmapping
our custom sound maps.
|
|
Rename the function because we're not only assigning normal mode
mappings here, we're also assigning visual mode mappings. And we might
be assigning mappings for other modes here too in the future, so this
name doesn't make sense.
I had originally called it this to distinguish it from the insert mode
set defined in plugin/auditory.vim with the `CursorMovedI` autocommand,
but I think this should be more clear about what it's doing.
Edit: Also modify the comment above this section for similar reasons.
|
|
The search commands, as I has specified previously in the verbose
mappings from before, should not be silenced, otherwise you can't see
the useful output that they provide in the command line area.
Add a way to make a mapping silent or not using a new field in the
mappings dictionary.
|
|
Needed to come up with a way to add it to the `mappings` dictionary
without overriding the existing normal mode 'x' mapping. Prefixed it
with `v_` for the dictionary key so that it doesn't conflict, but that
could easily be the start of a mapping (for whatever reason), so added a
`map_from` field to make it explicit what we're mapping from in cases
where the dict key is unclear.
Also added another field to the dict to specify a custom mapping
command. It will default to `nnoremap` as that's the one we use for most
of our commands, but you can change it if you need another mode as we do
for this visual 'x' mapping.
|
|
If we're not piping to an `execute` command in the mapping, we need to
`<cr>` to execute the sound player and type the normal mode command.
Otherwise the normal mode command gets typed in command mode which is
not what we want and messes things up greatly.
Figured I would just tack the `<cr>` on to the pipe variable rather than
create a new one since it's the inverse of what we need in that
situation. Hopefully the intention is clear enough but I'll grant that
this doesn't expose the most clarity.
Edit: Added a comment for better explanation of the <cr>.
|
|
I wanted to use `nmap` so that user-defined commands would come through,
but that caused the sounds to play recursively, a problem I now remember
from when I originally wrote this. Change it to `nnoremap` by default to
get around this. We'll look into whether it's possible to get
user-defined mappings attached somehow. Maybe in the save-and-restore
process.
|
|
Turns out my assumption that we didn't need <silent> when `execute`ing
in 83449bf7e30d45f91eccbcdffd56abb126be56c1 was incorrect. When
performing <C-d>, the audio play command appears in the command line,
which is not the behaviour we want.
Let's just revert to always using `<silent>` and figure that should work
for us.
Figured out between the last commit and this one that my manual testing
wasn't with the latest code. I was using
a037e921a4b9b0539c93450fe3df1f6c8175ceab this whole time because I
didn't have my development setup configured correctly. Now I can
actually see what's going on as I make changes (what a concept!).
Also bring back the ternary since we're not setting any more variables
for this condition any more.
|
