freenode/#sicl - IRC Chatlog
Search
14:12:20
jackdaniel
Bike: yes, but you must specify :report that-function; it is hard to expect i.e alexandria to depend on acclimation to specify that report function
14:12:42
beach
Right. But if (say) Alexandria does not respect this protocol, then we can't create condition reporters for Alexandria conditions in other languages.
14:13:26
jackdaniel
alternatively expand :report foo to something like (lambda (c s) (if *lang* (that-function c s *lang*) (foo c s))
14:14:38
beach
I.e., does the standard say that the :REPORT results in a call to PRINT-OBJECT? Or is it more vague about it.
14:15:06
jackdaniel
there is even: specyfing (:report foo) in the definition is equivalent to (and the code snippet)
14:16:17
jackdaniel
so it seems that a more conforming solution would be adding an around method to the print-object
14:29:42
jackdaniel
another way which I'm not sure about is using the pretty printer dispatch; however I've never used it extensively
14:30:14
Bike
i think you're supposed to be able to print conditions human-readably even when *print-pretty* is false.
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")