freenode/#sicl - IRC Chatlog
Search
16:43:58
beach
So one common complaint about Emacs is that it creates buffers and windows in a way that can neither be predicted nor controlled. Whether that is true or not I don't know, but the default behavior annoys me as well. So suppose we have an IDE with a REPL, and we want to keep the configuration of the different, let's call them panes, way more fixed than Emacs does.
16:43:59
beach
Now suppose I start a compilation (asdf:load-system...) in the REPL, and there are compilation errors/warnings in several files. How should this situation be presented to the programmer? Maybe a tab for each file in *the* pane that shows source code?
16:57:51
splittist
Some IDEs have a compilation results tab in the 'repl' pane that shows errors, warnings etc. There are often also indications against file-names in the project tree pane, and indications in the margin of each buffer at the offending line.
17:00:09
splittist
Sometimes there is a visual/spatial differentiation between interactive 'terminal' areas and editing areas (although obviously one at least 'line edits' in a terminal).
17:00:18
pjb
beach: It's a diffcult question. Basically in emacs, windows belong to the user. In more structured IDE, windows belong to the IDE. Perhaps some people like that, I find it more difficult to work with such IDEs…
17:00:56
pjb
beach: the thing is that emacs is highly non-modal. So, compilation results are not integrated in a work flow. They're just dumped in a buffer, show in a window, and let the user deal with it.
17:01:30
pjb
beach: more structured IDEs impose, or strongly hint at specific workflows, hence a structure of windows. (I keep emacs terminology).
17:02:16
pjb
beach: so perhaps we could start with that, define some workflows, and a set of specfic windows that will be used by the different inputs or outputs of the workflow.
17:03:40
splittist
There's the whole windows in registers thing, too. Although it's always C-x 2 - no wait, I meant C-x 3; C-x 4 'where will this appear'; next window, no, not that one, this one; C-x 0 - start again (:
17:03:45
pjb
Now, tab are a good idea, until they're not. Ie when there is a small number of tabs, they're ok, but soon enough there are a lot of them and they become unmanageable… So be careful with them.
17:04:22
pjb
yes, and there's the split horizontally or vertically, depending on the task or the size (aspect ratio) of the frame!
17:04:49
splittist
Perhaps one should be thinking of multi-monitor from the ground up. If not multi-monitor+multi-virtual-desktop
17:07:36
beach
ACTION is still here because his (admittedly small) family is in a virtual meeting so is unable to serve dinner on schedule.
17:09:44
beach
The other thing I have been thinking of is to structure the workflow around "modules" as defined by ASDF system definitions. Then, the position of files in the file system would be less important. But I suppose not everybody works the way i do with such things, so it would have to be some kind of option.
17:10:57
pjb
I wouldn't mind if a new workflow would create a new frame with its fixed windows inside.
17:11:41
pjb
What people complain is probably when emacs changes the windows they've careful set up for their own workflow.
17:39:34
beach
I guess the way to go would be to let the user configure the different panes. Like we just propose different panes that work in different ways, and the user can build a custom IDE out of those.
17:47:27
pjb
I like when systems have memory. If the user moves a window, next time we can create a similar window in the same place.
18:21:17
jackdaniel
(format-graph-from-roots (list "clim-basic") #'print (lambda (s)(ignore-errors(asdf/system:system-depends-on(asdf/system:find-system s)))))
18:21:38
jackdaniel
this ignore-errors is because I didn't bother to parse dependencies like (:version "flexichain" "1.5.1") or (:require "sb-introspect")