<Shinmera>
nice window handling like in other IDEs is one of my main pain points with emacs
<Shinmera>
*the lack of
<scymtym>
Shinmera: what would qualify as nice window handling? a system with docks and tabs that allows moving windows around? or a well-designed fixed layout? maybe splitting just within the editor window? i'm asking because i have been thinking about what we should do for second climacs in this regard
kagevf has joined #commonlisp
<Shinmera>
Something far more rigorous that lets the user define dedicated areas for "types" of windows. Like a central tabbed pane for source files. A bottom pane for repls and shells and log outputs.
<Shinmera>
As-is emacs just shuffles the layout around willy-nilly and it's very hard to keep things under control
<Shinmera>
things split vertically horizontally whatever which way and replace each other, constantly forcing me to keep rearranging stuff and it's honestly heck
<Shinmera>
I've tried several things that purport to improve the situation but they all end up just making things worse
<scymtym>
i see, thanks
<Shinmera>
because nothing else is designed around that, everything is just assuming the default emacs behaviour of just shooting your layout to fuck anyway
<Shinmera>
it's something that has to be built in from the get go
<Shinmera>
Like if I m-. I don't want my window to suddenly split horizontally and shuffle my crap around and then when I go through options I don't want it to randomly replace one of my open source files just to show a preview
<Shinmera>
it's hell because I lose context
<Shinmera>
and then getting back to where I was is absolutely exhausting when I just wanted to look at a thing
<Shinmera>
sorry, I'm ranting, this is years of built up anger
danse-nr3 has joined #commonlisp
<beach>
I agree it is pretty bad.
<scymtym>
yeah. i work around that a lot myself. when trying to visit sources without losing the debugger or inspecting one xref match without losing the list of matches
<Shinmera>
If I had to say this is far bigger of an issue with emacs than the different default keybinds
<Shinmera>
the keybinds can be worked around or easily learned
<Shinmera>
but this can't be fixed, and it is just demonstrably inferior to how other IDEs work
<Shinmera>
yes yes I know terminal use bla bla history bla bla I don't care, it sucks for your typical graphical desktop use
<scymtym>
right. i think the issue is more "everything is a buffer" than "everything is text". neovim has everything as text too but they have lots of popups, transient dialogs and preview windows nowadays
<Shinmera>
yes
<scymtym>
although we may want to challenge the "everything is text" paradigm as well
<Shinmera>
emacs' popup support still blows chunks even with stuff like posframes
<Shinmera>
which is honestly mind blowing
<pve>
while not proper solutions, window-configuration-to-register or winner-mode can help somewhat
mala has quit [Read error: Connection reset by peer]
mala has joined #commonlisp
reb has quit [Ping timeout: 248 seconds]
King_julian has quit [Ping timeout: 252 seconds]
xlymian has joined #commonlisp
jon_atack has joined #commonlisp
decweb has joined #commonlisp
wacki has quit [Read error: Connection reset by peer]
jonatack has quit [Ping timeout: 264 seconds]
herjazz has quit [Quit: Lost terminal]
wacki has joined #commonlisp
reb has joined #commonlisp
wobbol has left #commonlisp [WeeChat 4.3.5]
reb has quit [Ping timeout: 252 seconds]
JuanDaugherty has joined #commonlisp
X-Scale has joined #commonlisp
yitzi has joined #commonlisp
danse-nr3 has joined #commonlisp
X-Scale has quit [Ping timeout: 256 seconds]
st_aldini has joined #commonlisp
JuanDaugherty has quit [Quit: JuanDaugherty]
john4 has quit [Read error: Connection reset by peer]
alcor has joined #commonlisp
john2 has joined #commonlisp
lucasta has joined #commonlisp
rtypo has joined #commonlisp
reb has joined #commonlisp
<smlckz>
how to have the common lisp functions highlighted in emacs?
donleo has quit [Remote host closed the connection]
pve has joined #commonlisp
donleo has joined #commonlisp
wacki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
vats has joined #commonlisp
uhuh has joined #commonlisp
King_julian has joined #commonlisp
NotThatRPG has quit [Ping timeout: 260 seconds]
<pranav>
smlckz: Not sure what exactly do you want highlighted? The name/text? Or the entire top-level form?
<smlckz>
just the names
Noisytoot has quit [Ping timeout: 252 seconds]
<smlckz>
syntax highlighting elsewhere (outside emacs) for other programming languages, you'd see the built-in and user-defined functions to be clearly discernible
<smlckz>
so something like that
Noisytoot has joined #commonlisp
<dlowe>
lisp-mode exists
<dlowe>
if you want it to be smarter, you install slime or something so it can query a running image about function names
<dlowe>
To start you can type M-x lisp-mode
<pranav>
For defX forms font-lock-keyword-face can be customized using custom-set-faces, assuming you have font-lock-mode enabled.
<smlckz>
for what I can see, I'm already in lisp-mode as well as slime running as well; but there's no difference in highlighting between built-in and user-defined functions
<alcor>
I don't think SLIME is that smart. With SLIME, you can interactive documentation in the modeline area, but it other than that, it does not affect highlighting.
<beach>
smlckz: Emacs doesn't have a sophisticated enough analysis of the contents of the buffer to make such distinctions.
<dlowe>
would be kinda neat if slime colored different based on package contents
<dlowe>
er, based on symbol package I mean
<beach>
We are planning to do even better with Second Climacs.
<bjorkintosh>
it seems from my naive assessment to be a tagging issue.
<dlowe>
continuing the proud tradition of uncomfortably kink program names, I see
<beach>
We want to distinguish the role of symbols as well, so that if (say) PROGN is used as a lexical variable, it should be recognized as such, and we should be able to find all the occurrences.
<dlowe>
yeah, that's some ambitious analysis
<smlckz>
the initial idea I have is to make a list of functions from clhs, detect places where there can be implicit progn, forms or similar but not in quoted forms, check the head symbol of the form in the list of functions and highlight it if found..
larme has joined #commonlisp
<dlowe>
smlckz: that's definitely a possibility
<beach>
smlckz: But it won't take into account the package then.
<dlowe>
it may not be time well spent, though. Whether or not a function is in CL is really not consequential
<dlowe>
well, unless you want to name a variable T :(
uhuh has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
<smlckz>
Now this reminds me of the dilemma of properly perform syntax highlighting for Tcl..
<bjorkintosh>
dlowe: we don't do these things because we want to spend time well, we do these things because "we wonder if ... "
<yitzi>
Highlighting all CL functions & macros seems very unhelpful. CL isn't an Algol-68 style language, so highlighting such isn't as meaningful. I can see special forms, literals, etc.
<bjorkintosh>
smlckz: tcl is The Common man's Lisp. Perhaps the solution you discover will work for both?
<smlckz>
bjorkintosh: no, it won't work. In Tcl, you need to execute the code to know whether a brace enclosed region is a block of text or code...
<bjorkintosh>
surely it can be statically analyzed.
<smlckz>
If I understand this correctly, it is possible to have the standard common lisp macros to have a complete different meaning in another package?
<dlowe>
bjorkintosh: well, sometimes
<dlowe>
smlckz: yes, the common lisp symbols are treated the same as user symbols
<dlowe>
it's quite easy to make your own language within a CL image and write programs that never directly touch CL
<smlckz>
so the syntax highlighting and even indentation can be ''wrong'' for the standard macros depending on the package?
<dlowe>
it's certainly possible
<bjorkintosh>
it's a programmable programming language afterall. with macros.
<dlowe>
and readtables
<beach>
smlckz: You need to execute code in Common Lisp as well in order to figure out the role of the symbols.
<yitzi>
Which is kind of what I was getting at in saying that CL isn't algol-68. highlighting special forms makes sense, but any other CL symbol could be shadows.
<yitzi>
shadowed
<beach>
smlckz: But that is precisely what we are planning to do.
<smlckz>
duh
<paulapatience>
I just highlight forms differently based on nesting
<paulapatience>
With prism-mode
<paulapatience>
This isn't incompatible with making bold the builtin functions, though
<dlowe>
I wonder sometimes how you could tweak CL to be more amenable to static analysis
King_julian has quit [Ping timeout: 264 seconds]
Alfr has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
Alfr has joined #commonlisp
awlygj has quit [Quit: leaving]
reb has quit [Ping timeout: 265 seconds]
<bike>
git status
<bike>
oops
<smlckz>
with arbitrary code being executable in a macro, it won't be possible to have proper static analysis; with the way scheme went with its syntax-rules etc. it might be possible there, but I can not be sure about that..
lagash has quit [Ping timeout: 248 seconds]
<bjorkintosh>
is it essential or a nice to have?
<bike>
you can analyze the macroexpanded code, and cast anyone who writes side effecting macros into the jaws of perdition
NotThatRPG has joined #commonlisp
<dlowe>
I was thinking you could embed a parser grammar into the defmacro form, and the grammar could be used by other systems
<dlowe>
which is kind of like syntax-rules except it wouldn't necessarily make them hygenic
<dlowe>
there's a bit of this already in the destructuring form but it could be taken a lot farther
<random-nick>
smlckz: in scheme, for anything more complicated you need syntax-case, which again lets you execute arbitrary scheme code in the macro
<dlowe>
this concludes my grant proposal
<smlckz>
I don't know, for example with the devotion that Rust people have about their type system and similar ''guardrails'', what has happened with the ideology of expressive syntactic and semantic freedom, seemingly struggling under the excuse of security and safety of industrial systems...
jonatack has joined #commonlisp
jon_atack has quit [Ping timeout: 272 seconds]
larme has left #commonlisp [Using Circe, the loveliest of all IRC clients]
jon_atack has joined #commonlisp
larme has joined #commonlisp
jonatack has quit [Read error: Connection reset by peer]
icebarf_ has joined #commonlisp
<smlckz>
Or the situation Python faced with imposition of the limitation on the string to be converted into its arbitrarily long integers to avoid a ''security'' issue
danse-nr3 has quit []
cage has joined #commonlisp
edgar-rft_ has joined #commonlisp
kamafam has quit [Read error: Connection reset by peer]
edgar-rft has quit [Ping timeout: 260 seconds]
jon_atack has quit [Ping timeout: 264 seconds]
jonatack has joined #commonlisp
reb has joined #commonlisp
edgar-rft_ is now known as edgar-rft
X-Scale has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
vats has quit [Ping timeout: 264 seconds]
anticomputer has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
X-Scale has quit [Ping timeout: 256 seconds]
danse-nr3 has joined #commonlisp
dans61442 has joined #commonlisp
danse-nr3 has quit [Read error: Connection reset by peer]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
NotThatRPG_ has joined #commonlisp
NotThatRPG has quit [Ping timeout: 264 seconds]
lucasta has quit [Quit: Leaving]
wacki has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
NotThatRPG_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lagash has joined #commonlisp
shawnw has joined #commonlisp
dans61442 has quit [Remote host closed the connection]
danse-nr3 has joined #commonlisp
mgl_ has joined #commonlisp
<danse-nr3>
smlckz: "ideology of syn and sem freedom"? I'm not familiar with that
X-Scale has joined #commonlisp
yitzi_ has joined #commonlisp
yitzi has quit [Ping timeout: 272 seconds]
alcor has quit [Remote host closed the connection]
<danse-nr3>
i guess that's something i cared about for a while, maybe. Eventually i appreciated consistency more and more
attila_lendvai has quit [Ping timeout: 245 seconds]
mwnaylor has joined #commonlisp
shawnw has quit [Ping timeout: 252 seconds]
shka has quit [Read error: Connection reset by peer]
X-Scale has quit [Ping timeout: 256 seconds]
shka has joined #commonlisp
mgl_ has joined #commonlisp
Pixel_Outlaw has joined #commonlisp
mgl_ has quit [Ping timeout: 272 seconds]
varjag has joined #commonlisp
rtypo has quit [Quit: WeeChat 4.3.5]
jonatack has quit [Ping timeout: 265 seconds]
mgl_ has joined #commonlisp
JuanDaugherty has joined #commonlisp
reb has joined #commonlisp
Inline has joined #commonlisp
pve has quit [Quit: leaving]
<aeth>
Actually, I think that highlighting every function and macro name, in separate colors, could be useful in some niche situations, especially if the highlighter is smart enough to see MACROLETs and FLETs. Also, there are symbol macros (mostly seen in WITH-ACCESSORS), which could be distinguished from variables by having colors.
<aeth>
You could even e.g. highlight things in the CL package separately from those that aren't.
<aeth>
But why just colors, too? Consider e.g. putting the vector arrow on top of vectors (however, the actual Unicode combining symbol for this is designed for math notation where variables are single-letter)
<aeth>
Since CL is dynamically typed, it wouldn't be too useful in CL in particular because it would rarely show up, but I don't think I've ever seen syntax highlighting for a statically typed language do that, either.
jonatack has joined #commonlisp
contrapunctus has quit [Ping timeout: 272 seconds]
<bjorkintosh>
but I don't think I've ever seen syntax highlighting for a statically typed language do that, either. <-- perhaps smlckz has come from the future to guide us.
xlymian has quit [Ping timeout: 276 seconds]
<aeth>
I don't think smlckz brought symbols up, it's just that if you run out of colors you have to start adding symbols above/below (sort of like what flyspell-prog-mode does for spelling it doesn't recognize in comments/strings).
contrapunctus has joined #commonlisp
<aeth>
Adding a symbol (maybe just an underline or something) for in CL package vs not in CL package would probably help keep the color count low, too.
<aeth>
I have actually seen underlines... GitLab syntax underlines :keywords recently (past few years?), but I don't like it.
reb has quit [Remote host closed the connection]
reb has joined #commonlisp
thonkpod_ has quit [Remote host closed the connection]
thonkpod_ has joined #commonlisp
<NotThatRPG>
sbcl debugger question: I am trying to look at the value of a stack variable that is a list, and the debugger keeps displaying it with ellipses. Using `prin1` and binding `*print-readably*` and `*print-length*` aren't helping. What am I doing wrong?
mgl_ has quit [Ping timeout: 252 seconds]
<mrcom>
NotThatRPG: sly, slime, straight sbcl in a terminal window?
<NotThatRPG>
straight SBCL in a terminal
<mrcom>
Try setting *print-lines* and *print-level* to nil
<mrcom>
Is the variable a structure, list, array, or ?
<mrcom>
sb-ext:*debug-print-variable-alist*.
<mrcom>
Initially empty, *debug-print-variable-alist* is typically used to provide bindings for printer control variables
<NotThatRPG>
mrcom: but it says "When evaluating arbitrary expressions in the debugger, the normal values of the printer control variables are in effect. "
<NotThatRPG>
setting the entry for `*print-length*` there doesn't prevent sbcl from printing ellipses.
attila_lendvai has joined #commonlisp
<NotThatRPG>
I'll post a gist or a pastebin...
<mrcom>
Hmm. Are you using something lilke aclrepl, or the standard horrible repl?
<NotThatRPG>
oh, yes, I think I have aclrepl in there
<mrcom>
Don't think that should actually have anything to do with the repl.
<NotThatRPG>
I even tried writing the variable to a file, and *still* got the ellipses
<mrcom>
Does prin1 do pretty printing? Can't remember.
<mrcom>
Did you try WRITE or FORMAT?
<NotThatRPG>
There's something VERY hinky here. I can print the variable by putting its name into the debugger prompt, but if I try to DESCRIBE it, I get no printout.
<mrcom>
It's a local variable, right?
<NotThatRPG>
Yes, that's right.
<NotThatRPG>
I can access values in the suppressed part, but if I try to loop over the list and print each element, I get nothing.
<NotThatRPG>
It's almost like it's some kind of weird symbol macro or something...
<smlckz>
Which is more performant: (write-output-to-string (s) ... passing s as explicit argument), or (write-output-to-string (*standard-output*) ...) ?
<mrcom>
You should see the list in full twice.
istewart has joined #commonlisp
xlymian has joined #commonlisp
<mrcom>
NotThatRPG: In trame 18 you're down in the UIOP weeds. It does stuff to standardize I/O settings; you may be hitting that.
<NotThatRPG>
mrcom: I suppose that's possible, thanks!
<NotThatRPG>
But I think there's something the debugger is doing, too, otherwise my loops over the list variables wouldn't be failing in such odd ways
<mrcom>
NotThatRPG: Try this also, in that frame: (let ((*print-limit* nil) (*print-lines* nil) (*print-length* nil)) (write uiop/run-program::command))
jon_atack has joined #commonlisp
<NotThatRPG>
mrcom: I'll have to try later. I busted something misspelling a variable name and lost my context. :-(
shka has quit [Ping timeout: 272 seconds]
<mrcom>
OK. There's also PRINT-OBJECT that could be overriding stuff.
jonatack has quit [Ping timeout: 252 seconds]
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dino_tutter has quit [Ping timeout: 265 seconds]
jon_atack has quit [Read error: Connection reset by peer]
jonatack has joined #commonlisp
wacki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
attila_lendvai has quit [Remote host closed the connection]
wacki has joined #commonlisp
attila_lendvai has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
<smlckz>
How to send an eof for a read-line inside slime repl?
attila_lendvai has quit [Ping timeout: 264 seconds]
<mrcom>
NotThatRPG: I think I've recreated what you're seeing, not uiop involved.