Opened 12 years ago

Closed 10 years ago

#144 closed defect (invalid)

Hemlock windows initially show wrong package

Reported by: alms Owned by: gb
Priority: minor Milestone:
Component: IDE Version:
Keywords: Cc:

Description

Hemlock initially shows the wrong package when it opens files that begin with an IN-PACKAGE form rather than a modeline. If you click in the text area of the file, it updates the package display to show the correct package.

For example: if you open "ccl:examples;cocoa;easygui;currency-converter.lisp" the window's modeline will initially show CL-USER as the package, even though the file begins with (IN-PACKAGE :EASYGUI-DEMO).

Change History (3)

comment:1 Changed 12 years ago by alms

This is not just a display problem. The window actually does not have its package set. So, for example, if you open the current-converter problem and then immediately type command-a (select all) followed by enter, all the forms in the package get evaluated in the CL-USER package rather than the EASYGUI-DEMO package.

comment:2 Changed 12 years ago by gb

The buffer-init code (maybe it's lisp-mode init) sets the buffer's package to CL-USER if it can't parse a modeline. It should presumably try looking for an IN-PACKAGE form, and we can argue whether the IN-PACKAGE should override the modeline or not.

After the buffer's initialized, it looks for an IN-PACKAGE that precedes the selection every time the selection changes.

comment:3 Changed 10 years ago by gb

  • Resolution set to invalid
  • Status changed from new to closed

If there was a bug here, I don't understand what it was.

The editor's notion of the buffer's "current package" at a given mark/position is determined by:

  1. the most recent IN-PACKAGE form that precedes that position, if any
  2. the package specifed on the attribute line, if any
  3. the global value of *PACKAGE* (in the event thread, typically CL-USER)

so seeing different values in the modeline depending on where the insertion point is is intended behavior.

There has been a bug that caused a package (package name) referenced in an IN-PACKAGE form to be used as the current package even if the insertion point was before the first IN-PACKAGE); this didn't work too well if the package didn't yet exist, but that's not what this ticket seems to be describing.

If there's a valid bug here, please reopen this.

Note: See TracTickets for help on using tickets.