Proposed fix for #1 - chmod +w buffer-file#5
Conversation
Starting with the obvious brute force approach. Expose the mode modifier and in inhibit flag to customize, predicate mode change on file being read-only, restore prior mode after if we've changed it prior. Uses before and after save hooks.
|
Ok, that's better. Here's first blush at the most obvious brute force solution. I'm going to need to get a bit better with git in general and magic in specific I can see. Cutting and pasting from emacs into github is not the way to do this I think. A thing to consider could be `write-file-functions' instead of before-save-hook which would let's us abort the save by returning nil vs throwing the error fi the save isn't going to work after trying chmod. |
addition testing target
|
I don't know what's causing emacs 26.3 to fail, can we add it to |
|
I'm not really sure this is an issue with chmod. I think it has to do with this line, which prevents the buffer of being edited when there's a merge conflict. We could just remove that line altogether (with the added risk of having people modifying the lockfile, which isn't that terrible anyway) or set up a hook for ediff mode. |
|
I wondered about that. If the issue is just that the buffer pops as
read-only then maybe we should just document the need to press C-x q prior
to making edits. Given the file is R/O I agree with the original design of
popping it read-only. Add a custom to disable implicitly setting it
read-only?
…On Sat, Jan 4, 2020 at 9:18 AM Nicolás Salas V. ***@***.***> wrote:
I'm not really sure this is an issue with chmod. I think it has to do with this
line
<https://github.com/anachronic/yarn-mode/blob/e59532b648dfbe4ada95b763792a93c2e0b87b30/yarn-mode.el#L102>,
which prevents the buffer of being edited when there's a merge conflict.
We could just remove that line altogether (with the added risk of having
people modifying the lockfile, which isn't that terrible anyway) or set up
a hook for ediff mode.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5?email_source=notifications&email_token=AA6BAZWR4LWVOEHK33BP5N3Q4CSC7A5CNFSM4KBTLBXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICZ4KI#issuecomment-570793513>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6BAZRL5YIPWEAVUFSXMMDQ4CSC7ANCNFSM4KBTLBXA>
.
--
*Corwin*
612-217-1742
612-298-0615 (fax)
612-695-4276 (mobile)
*corwin.brust (skype)corwin@bru.st <corwin@bru.st>*
|
|
Yes. I'll push that and then see what's going on.
…On Sat, Jan 4, 2020 at 9:11 AM Nicolás Salas V. ***@***.***> wrote:
I don't know what's causing emacs 26.3 to fail, can we add it to
allowed_failures in travis.yml?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5?email_source=notifications&email_token=AA6BAZWNHPHDDGUAFEDXEPDQ4CRK3A5CNFSM4KBTLBXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICZYLY#issuecomment-570793007>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6BAZV3W5N7U6FMQ6AEYMDQ4CRK3ANCNFSM4KBTLBXA>
.
--
*Corwin*
612-217-1742
612-298-0615 (fax)
612-695-4276 (mobile)
*corwin.brust (skype)corwin@bru.st <corwin@bru.st>*
|
not sure 26.3 is failing, will research presently
|
BTW, I've enabled PR-less commit from maintainer of the fork source repo
(e.g. you can commit directly to my patch-3 and master branches, I think.)
Fine by me to use those as sandbox.
…On Sat, Jan 4, 2020 at 10:53 AM Corwin Brust ***@***.***> wrote:
Yes. I'll push that and then see what's going on.
On Sat, Jan 4, 2020 at 9:11 AM Nicolás Salas V. ***@***.***>
wrote:
> I don't know what's causing emacs 26.3 to fail, can we add it to
> allowed_failures in travis.yml?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#5?email_source=notifications&email_token=AA6BAZWNHPHDDGUAFEDXEPDQ4CRK3A5CNFSM4KBTLBXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICZYLY#issuecomment-570793007>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AA6BAZV3W5N7U6FMQ6AEYMDQ4CRK3ANCNFSM4KBTLBXA>
> .
>
--
*Corwin*
612-217-1742
612-298-0615 (fax)
612-695-4276 (mobile)
*corwin.brust ***@***.*** ***@***.***>*
--
*Corwin*
612-217-1742
612-298-0615 (fax)
612-695-4276 (mobile)
*corwin.brust (skype)corwin@bru.st <corwin@bru.st>*
|
I don't know. It's been a while since I've used Emacs, and way more than that since I used ediff. I don't remember if one would need to |
|
I had the binding wrong -- I was thinking of C-x C-q which toggles
read-only-mode. That is buffer local, of course, is similar to if we did
our own save command and wrapped it in (let ((inhibit-read-only t))
...save the file...)
Looking at the failure for 26.3 it seems to be around GNUTLS which
complains about an auth setting that may be supposed to come from
libunpackaged. I also see an warning about unpackaged not being available
which makes think this could be a 26.3 bug where TLS doesn't probably
codify it's dependency on unpackaged. Or something. I'm kinda new.
On Sat, Jan 4, 2020 at 12:31 PM Nicolás Salas V. <notifications@github.com>
wrote:
… I wondered about that. If the issue is just that the buffer pops as
read-only then maybe we should just document the need to press C-x q prior
to making edits. Given the file is R/O I agree with the original design of
popping it read-only. Add a custom to disable implicitly setting it
read-only?
… <#m_-7134658713677530921_>
On Sat, Jan 4, 2020 at 9:18 AM Nicolás Salas V. *@*.***> wrote: I'm not
really sure this is an issue with chmod. I think it has to do with this
line
https://github.com/anachronic/yarn-mode/blob/e59532b648dfbe4ada95b763792a93c2e0b87b30/yarn-mode.el#L102,
which prevents the buffer of being edited when there's a merge conflict. We
could just remove that line altogether (with the added risk of having
people modifying the lockfile, which isn't that terrible anyway) or set up
a hook for ediff mode. — You are receiving this because you authored the
thread. Reply to this email directly, view it on GitHub <#5
<#5>?email_source=notifications&email_token=AA6BAZWR4LWVOEHK33BP5N3Q4CSC7A5CNFSM4KBTLBXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICZ4KI#issuecomment-570793513>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA6BAZRL5YIPWEAVUFSXMMDQ4CSC7ANCNFSM4KBTLBXA
.
-- *Corwin* 612-217-1742 612-298-0615 (fax) 612-695-4276 (mobile) *corwin.brust
***@***.*** ***@***.***> ***@***.*** ***@***.***>*
I don't know. It's been a while since I've used Emacs, and way more than
that since I used ediff. I don't remember if one would need to C-x q all
buffers or just one. If I'm lucky, I could try tonight or tomorrow night.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5?email_source=notifications&email_token=AA6BAZWSHYFI6JNDO7SF6O3Q4DIXNA5CNFSM4KBTLBXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIC5O6I#issuecomment-570808185>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6BAZW4EKXCELLMJGSQK23Q4DIXNANCNFSM4KBTLBXA>
.
--
*Corwin*
612-217-1742
612-298-0615 (fax)
612-695-4276 (mobile)
*corwin.brust (skype)corwin@bru.st <corwin@bru.st>*
|
Yeah, sorry, I didn't remember the binding either. Thing is that ediff opens up multiple buffers so that you can view the diff or merge conflicts (or w/e, really) side to side. I don't remember if there's a minor mode for ediff. If there is, we could hook to it and |
|
I've prepared an example repo for this issue here. Merge feature1 into master and there'll be a merge conflict. ;;;###autoload
(add-hook 'ediff-prepare-buffer-hook
(lambda ()
(when (equal major-mode 'yarn-mode)
(progn
(setq buffer-read-only nil)))))I tried the snippet above and it does seem to work. Btw, if you need to try out ediff, you can just Edit: sorry, I left a |
|
This is pretty clearly the way to go with this. Sorry to disappear the latter half of the weekend. I'll jump back into this after work this evening. |
|
This is still on my plate to confirm the above solution works and update/write tests. Probably not this weekend. If happen to try patching with this we'd welcome any additional reportage. |
|
Great! I'm happy to hear that you still have this in your backlog |
2 participants
First pass at fix for #1 starting with the obvious brute force approach. Expose the mode modifier and in inhibit flag to customize, predicate mode change on file being read-only, restore prior mode after if we've changed it prior. Uses before and after save hooks.