noctuid
commented
6 years ago Why not just have a workspace with a terminal in fullscreen?
I don't think there's a huge benefit from using a dropdown over a dedicated workspace.
The main reason I use dropdowns instead of dedicated workspaces is because I generally use my dropdown terminals for one-off commands/actions. I don't need fullscreen for this and don't think this usage warrants a dedicated workspace. For example, I may press my dropdown key, run a command to backup my files to a drive I have plugged in, use the same key (which is I think is nice) to get rid of the terminal, and then return to whatever I was doing on the same workspace without altering my workspace switching history.
Another potentially nice feature of tdrop is the ability to automatically hide and show dropdowns. For example, I can configure my tui file manager (ranger) so that dropdowns are automatically hidden when opening window (e.g. image viewer or video player) from them. Upon closing the image viewer, video player, etc., the dropdown reappears. Of course, for that case (file management or media), it might be better to actually have a dedicated workspace. You could still use the automatic-hiding/showing feature, but it wouldn't be as useful since you wouldn't be using a floating window (i.e. you could just use a tabbed/monocle/fullscreen layout so that the current window takes up the full screen size). On the other hand, using a floating dropdown on that workspace might help to prevent clutter if you wanted to have only image viewer windows open, for example.
I'd say that dropdowns may be useful, but it comes down to personal preference/workflow.
why not have a scratchpad window (I use i3wm)?
I admit I've only tried i3's scratchpad functionality briefly. Does it offer anything over tdrop? If so, it's likely the functionality could be added to tdrop. Tdrop works with any window manager and has a lot of other advantages over other solutions that work for only one terminal or one window manager.
You say that it's easily scriptable--in what way, how, and does it require much of a learning curve assuming decent bash scripting skills?
The main thing you need to learn is bspwm's API which isn't all that complicated. You could just as easily use python to make the bspc calls or parse the JSON output of its query commands. That said, you don't need to know too much bash to work with bspwm.
what makes it much better than i3 in your opinion? ... What are some useful/practical things it can do that i3 can't?
i3 and other window managers may be better for other people. I think i3's tabbed/stacked layouts are pretty nice, and I wish bspwm had them instead of the monocle layout. Because I don't usually even have three windows on a desktop, this isn't really an issue in practice for me though.
i3-msg (i3's equivalent of bspc) is also quite nice considering only a few window managers even have a comparable equivalent (i.e. you must script/manage them in a single language). Unlike i3-msg, bspc is the /only/ way of interacting with bspwm. The configuration file is just a shell script with calls to bspc. That said, I'm not against the idea of a window manager being scriptable in the language its written in. I just find that most of the configuration/scripting I've done for window managers is simple enough that it shouldn't require a more powerful/complicated programming language. That option may be nice, but I don't like when it's the only option. For example, stumpwm provides a bspc equivalent and uses a language I like. I might be using it instead if it had floating support and some other features I'd miss from bspwm.
I'll use tdrop as one example of where I prefer bspc. The query functionality of i3-msg and bspc is sufficient for determining the current monitor (which tdrop needs to do for its -m flag to work). On the other hand, the rule system of bspc is arguably more powerful. For example, bspc can be used to add a one-time rule to float the next window of some class. This means that when showing a dropdown in bspwm, it starts out as floating. i3-msg doesn't have this capabilities, so when showing a dropdown in i3, it starts out tiled and is quickly switched to be floating. Note that you can workaround this in i3 and most window managers by having a dedicated floating rule for a class or some window, but bspc doesn't need any special/global configuration.
As another example, I use bspwm's subscribe functionality to switch out my sxhkd configs on empty workspaces so that I can use keybindings without modifiers (e.g. q to start qutebrowser). Maybe this is possible in i3; I don't know.
In general, I don't think window manager choice matters that much as long as your window manager does everything you need it to. Advanced capability for scripting may be completely useless for a lot of people. In the end, my window management setup is fairly basic. I try to only have one window open on a desktop at a time (or maybe 2-3 with monocle layout). While complicated tiling setups look nice in screenshots, I think having a bunch of windows open on the same desktop wastes screen space and requires extra keypresses for navigation.
Most importantly, sway means it's future-proof for when Wayland becomes the norm.
I don't think Wayland is the future. Even if it wins over alternatives (old or new), I'd be surprised if X doesn't last decades more. A lot of people won't switch. Wayland is by design incompatible with a lot of the functionality I use (e.g. sxhkd, xdotool, tdrop, etc. are all impossible in Wayland). I've seen mostly negative sentiment about Wayland recently. If Wayland changes or something else does replace X, I'm not particularly worried about the possibility of having to switch window managers because my window management configuration is fairly minimal.
Is your elisp good and would you dissuade other people from learning examples of elisp code and style from you?
My original elisp was terrible, so definitely don't look at any of my packages that haven't seen recent activity. My current elisp is a lot better, but I'd recommend learning from someone else's work (e.g. abo-abo). As for style, there is an emacs lisp style guide. I learnt elisp by writing it (and by learning common lisp).
At the moment I'm struggling to structure my dotfiles for Emacs.
I use the one big org file approach because I don't feel that it's necessary to split the configuration into multiple files (it's personal preference though). You can use worf-goto or counsel-org-goto to quickly jump to a heading using ivy, or you can use counsel-outline if you'd prefer to use an elisp file with org-style headings (e.g. ;; * Evil). The advantages of org mode really only have to do with markup and pretty export though, so I'd probably recommend using actual elisp files to people instead. You can use polymode to be able to edit the elisp code sections as if you were in an emacs lisp mode buffer, but it's not perfect.
like which packages to autoload
I use (setq use-package-always-defer t). I explicitly demand packages I use immediately (e.g. general and evil) in my configuration file. For packages that provide commands, you generally don't have to do anything besides create keybindings (the package will be loaded on the relevant keypress). For packages that provide a minor mode, you can generally use hooks to load the package. For packages that provide global minor modes (e.g. company), I sometimes defer them using idle time (e.g. :defer 3) since I probably won't need them the second I start emacs.
dependencies
package.el (and straight.el, which is what I use) all handle installing dependencies. If you are talking about how to handle packages that are extensions of others, use the :after keyword. For example:
(use-package company-statistics
:after company
;; :init only run after company is loaded
:init (company-statistics-mode))where to put custom functions related to a package, whether to bind commands related to a package inside that package's use-package declaration or to have a init-bindings.el for all bindings,
I'd recommend doing anything related to a package in the same section.
dustinlacewell
I was reading through your setup/aesthetics/workflow and it's a very interesting read and one that I think I align with. I really appreciate the in-depth description and decision-making you've made to achieve a workflow that works for you--this is something not many people share to that level of detail but is essential before immediately discrediting an aspect of the tools they use. Since you're open to questions regarding anything, I'm sure I will have more in the future, but for now:
1) Why is tdrop or a drop-down terminal so appealing to you? If you wanted something that's persistent (I assume that's an aspect of what a drop-down terminal offers--you get to re-use the same instance and scroll up to your previous commands in the current "session"), why not just have a workspace with a terminal in fullscreen? Or better yet, if you want more accessibility and not have to switch workspaces, why not have a scratchpad window (I use i3wm)?
I can see how a drop-down terminal is useful with traditional stacking window managers because it is much easier to have cluttered windows and it can alleviate that, so I guess I'm trying to see whether tdrop could benefit me as a tiling window manager user.
I believe I ended up choosing i3wm because more stuff worked out of the box, has tabs, excellent documentation, and a subreddit with a large and active community. Most importantly, sway means it's future-proof for when Wayland becomes the norm. It doesn't seem like many other tiling window managers will get ported to Wayland, and if bspwm doesn't, then the time/effort spent on customizing it isn't worth it to me (still curious what it offers over i3 though, to get a sense of what potentially useful features I might be missing out on).
P.S. A completely small and random question--I first noticed you from your Emacs contribution (general.el). Is your elisp good and would you dissuade other people from learning examples of elisp code and style from you? At the moment I'm struggling to structure my dotfiles for Emacs. I've only split my init.el file into smaller init-org.el, init-hydra.el, etc. and I'm trying to look at examples on how to use
use-packageto its potential (like which packages to autoload, dependencies, where to put custom functions related to a package, whether to bind commands related to a package inside that package's use-package declaration or to have a init-bindings.el for all bindings, for example, etc.). Maybe you have a particular user to recommend to explore the structure of his Emacs dotfiles because it's structured in a practical manner.Much appreciated and no rush at all.