search

greghendershott / racket-mode

Emacs major and minor modes for Racket: edit, REPL, check-syntax, debug, profile, packages, and more.
https://www.racket-mode.com/
GNU General Public License v3.0
683 stars 93 forks source link

print-as-expression in buffer has no effect #645

Closed EvgenyMakarov closed 2 years ago

EvgenyMakarov commented 2 years ago

I have a file test.rkt with the following content.

#lang racket

(print-as-expression #f)
(print-mpair-curly-braces #f)

(define lst (mcons 1 (mcons 2 '())))

I expect that after pressing F5 and typing lst in REPL it prints {1 2}. However, it prints (mcons 1 (mcons 2 '())). If I type (print-as-expression #f) in REPL and then type lst, REPL prints {1 2}, as expected. So it seems that the instruction (print-as-expression #f) in the file has no effect when this file is loaded into REPL.

In contrast, (print-mpair-curly-braces #f) is respected by REPL: after I load the file above and type (print-as-expression #f) in REPL, lists formed with mcons are printed using round parentheses rather than curly braces, which are used by default.

When I run racket from shell (not in Emacs) and type (enter! "test.rkt") at the prompt, both flags are set to #f according to the instructions in the file, and lst prints (1 2). Since it works in shell, the problem is probably in the Emacs mode.

I have Emacs 26.3 and racket-mode version 20221107.1846 from MELPA.

greghendershott commented 2 years ago

It looks like this is due to evaluating configure-runtime after requiring your user program. Apparently I'd changed that in commit 3ed2ac6, to avoid duplicated Typed Racket error messages (TR directly calls error-display-handler for each of possibly numerous type-check failures, before finally raising an actual single exn:fail:syntax which has a summary error message.)

The fix for the problem you're reporting seems to be to move configure-runtime first. (So e.g. if the configure-runtime for #lang racket sets some of these print parameters, your program will run later, and its settings will "win".)

Although that will break what I tried to do in commit 3ed2ac6, I think I can achieve the desired result simply by parameterizing error-display-handler to void during the configure-runtime.

All that seems to test out fine, so far, but before committing much less merging I'd like to think about this some more.

greghendershott commented 2 years ago

Indeed after thinking about this more, I wasn't satisfied with hiding duplicate type-check messages. More important: Prevent duplicate type-checking, i.e. expansion. Especially as that can be so slow.

I have a commit which I think handles this better (while still fixing your reported bug).

Will probably still sleep on it a bit, before merging.