-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Equake mode should be frame-local rather than buffer-local #19
Comments
In GitLab by @Lockywolf on Sep 1, 2021, 23:06 I initially thought about creating a separate "issue", but perhaps this one fits better. I use I can use |
In GitLab by @Lockywolf on Sep 1, 2021, 23:07 mentioned in issue Lockywolf/linuxbugs-lwf#175 |
What do you think the desired behaviour should be though? Or, put another way, what is the issue that you're facing precisely? (a) Is it about keeping the tabs in the modeline? (b) Is it about not opening anything in an Equake frame that's not a terminal? I think this parent issue here is connected to (a), but not to (b). And I'm not sure that (b) is exactly the behaviour that would be expected. So, if I pull up Yakuake, and run But this is Emacs, and so I imagine we could figure out some sort of optional setting to have a different behaviour. But I'm still not entirely sure what the desired behaviour for you would be. That any non-terminal things that one tries to open from an Equake frame spawn a new frame instead? |
In GitLab by @Lockywolf on Sep 2, 2021, 22:37 Well, (a), would be very nice, for sure! Maybe it would even solve my issue altogether. With respect to (b)... let me be more specific. I am feeling some difference between "using external applications in equake" versus "using Emacs' own applications in equake". When using However, when running I mean, I am not pretending that my opinion is objective here. It is just that I want |
(a) is something I want to eventually solve. Since it potentially interacts with how tabs are handled, I've been sort of putting it off until I can evaluate whether using the new native Emacs tabs might be a better solution. (Also waiting to make sure that most users are likely on a version of Emacs that supports native tabs.) For (b), I think this is partially workflow-specific. If I have Equake "open" and open up some file to edit in it, it's likely because I have something full-screen below Equake that I want to be able to see and so I don't want to spawn a new Emacs frame that obscures this. (Otherwise I'd just edit in a regular Emacs frame rather than in Equake.) (I'm not happy that my tabs disappear when I do this, as sometimes I'd like to still be able to switch tabs when editing in this way; thus one of the reasons I'd like to solve (a).) But, it fully makes sense that one might want to keep non-terminal things out of an Equake frame. I'm investigating how this might be done. The underlying problem is that a lot of Equake's behaviour involves "tricking" Emacs to behave in non-standard ways. As would this. I'm working on a potential solution for customising (b)-type behaviour. I'll try to get something pushed to an experimental branch soon. |
Ok, see the https://gitlab.com/emacsomancer/equake/-/tree/redirect-open-to-new-frame branch. If you use this branch and set Bug reports welcome. |
The But the original issue remains open. |
In GitLab by @Lockywolf on Sep 13, 2021, 02:17 Great, thanks! |
In GitLab by @Lockywolf on Sep 13, 2021, 23:59 It seems that I cannot close this bug. Shall it be closed? |
@Lockywolf This change still doesn't fully address the main original issue here, so I'll leave it open. |
(Also, there are some advantages to buffer-local as well, cf. https://gitlab.com/emacsomancer/equake/-/issues/26 .) |
Since the
equake-mode
minor mode is set buffer-locally, two undesirable UX issues arise:Perhaps
equake-mode
can be set frame-locally. Or else, some workaround can be put in place to toggle the buffer-localequake-mode
based on frame properties/name.Possibly utilising native tabs in Emacs (see https://gitlab.com/emacsomancer/equake/-/issues/14 ) could also be helpful in resolving this issue.
The text was updated successfully, but these errors were encountered: