I want to install a Scribble mode for GNU Emacs. There seem to be two: https://github.com/emacs-pe/scribble-mode https://www.neilvandyke.org/scribble-emacs/ Is one preferred over the other? The former appears to be available via MELPA. A quick look at the code suggests that the latter is maybe more featureful (?).

@eeide Haven’t tried them. However the file size of Neil’s mode is greater than the file size of emacs-pe.

Maybe @pmatos knows more?

Is it just me or is build-path/convention-type not really useful for building paths for the system you’re not on.

For example, on unix, the following fails:

(build-path/convention-type 'windows "foo")

With the error: . . build-path/convention-type: specified convention incompatible with string path element path element: "foo" convention: 'windows

@soegaard2 Thanks anyway.

But I can make a path with (bytes->path #"foo" 'windows)

But I think I remember @mflatt saying a while back that string->path and bytes->path are not as good of a way to create paths as build-path. I could be mis-remembering though.

You are. The quote is: >Roughly, strings don’t work, because they have to be converted to bytes >using the locale’s default encoding. Although strings are allowed for >the current platform’s convention on the assumption that the current >locale’s encoding is the right one, we’ve avoided building in any >assumption about the encoding for the other convention.

So use byte strings with build-path/convention-type.

@soegaard2 but byte string fail to match build-path/convention-type’s contract.

huh?

About the best I’ve got so far is: (build-path/convention-type 'windows (bytes->path #"C:" 'windows) (bytes->path-element #"foo" 'windows) (bytes->path-element #"bar" 'windows)) which is very ugly

@soegaard2 the contract for, say, ‘base’, in build-path is:

(or/c path-string? path-for-some-system? 'up 'same)

Oh. Yeah. The example is: (define (bs->p bs) (bytes->path bs 'unix)) (build-path/convention-type 'unix (bs->p #"/") (bs->p #"foo") (bs->p #"bar"))

Time to make my-build-path !

Makes sense.

I wonder if it would make sense to modify make-path/convention-type to be a little less insane.

File paths are insane.

paths drive me crazy

@soegaard2 and @jesse yes…yes they are…sigh.

Although honestly, this seems like a level up in terms of insanity to me. Like, maybe I’m missing something as to why the following wouldn’t work:

(build-path/convention-type 'windows #"C:" #"foo" #"bar")

Which seems like it should generate #<windows-path:"C:\foo\bar">

sounds…reasonable

(…is windows-path really a thing?)

http://docs.racket-lang.org/reference/windowspaths.html?q=build-path#%28part._windowspathrep%29

utf–16!

yeah that’s the same encoding that you might have known as WTF8

unicode means 16-bit wide chars, right? that’s what we thought in the 90s

@greg it appears that if I start emacs with PLTADDONDIR set, racket-mode doesn’t respect that

@samth I’m not at all familiar with PLTADDONDIR. From reading the docs, I’m not sure what racket-mode ought to do. What would be an example of something racket-mode didn’t do, that you expected?

@greg for example, it needs to look there to find the collections needed by the file I’m running

OK. I’ll see if maybe command-line Racket does this via, what’s it called, racket/init, and also see what DrR does in this regard.

@greg DrRacket works correctly here

but it’s not doing something in racket/init, it’s much lower level

@samth It looks to me like the default value of current-library-collection-paths — which racket-mode does not set otherwise — is supposed to be result of find-library-collection-paths, and that is what is supposed to include (a subdir of) addon-dir: https://docs.racket-lang.org/reference/collects.html#(def._((quote._~23~25kernel)._find-library-collection-paths))

you just want to carry over the environment variable, I think

the alternative would be to read the environment variable and then pass it via -A on the command line

or (maybe) read the environment variable and the set current-library-collection-paths and various other things yourself but that sounds unlikely to be the right approach

I think current-library-collection-paths is supposed to default to find-library-collection-paths.

And racket-mode doesn’t do anything to fubar that, AFAICT.

Running racket-mode with (say) 6.10: Welcome to Racket v6.10. foo.rkt> (find-library-collection-paths) ;(current-library-collection-paths) gives identical result '(#<path:/Users/greg/Library/Racket/6.10/collects> #<path:/Applications/Racket_v6.10/collects>) foo.rkt> (find-system-path 'addon-dir) #<path:/Users/greg/Library/Racket/>

Does that seem correct to you?

With a build of HEAD it’s Welcome to Racket v7.2.0.2. foo.rkt> (find-library-collection-paths) ;(current-library-collection-paths) gives identical result '(#<path:/Users/greg/Library/Racket/development/collects> #<path:/Users/greg/src/racket-lang/racket/collects>) foo.rkt> (find-system-path 'addon-dir) #<path:/Users/greg/Library/Racket/>

@samth What does it look like for you? And, is (find-system-path 'addon-dir) as you expect, does it match the env var?

@greg, sorry, this was a problem with weird package/environment config stuff I did

I fixed that and racket-mode started doing the right thing

although it still does something strange

that might be about sandboxing?

but that problem is less obvious what’s going on so I’ll report more later

@samth No worries, glad to hear the immediate problem is resolved. Curious to hear more later about Stranger Things.