Re: [ELPA] New packages: boxy, boxy-headlines

[Tyler Grinn <tylergrinn@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Defface wasn't working for me when updating the color scheme. Repeated
>> calls to defface don't seem to apply changes, while directly modifying
>> the face-defface-spec does.
>
> AFAIK, same as for `defvar`, this is on-purpose.
> If you want to re-apply the standard definition, the recommended way is
> to use `C-M-x`.
>

That's what I've gathered to, so to get around that is why I'm using
face-spec-set. The behavior I want is this: update the face if a user
has not independently customized it already. If I simply changed the
defface, only new users would get the new theme. Existing users would
have to re-apply the standard definition or restart emacs.

>>> - Your packages have no ;;;###autoload cookie.  The doc of boxy.el
>>>   doesn't make it clear what's a likely entry point (i.e. how to start
>>>   using it), but for `boxy-headings`, it seems at least the
>>>   `boxy-headlines` function should have such a cookie.
>>
>> I think you're right about the boxy-headlines command. boxy.el provides
>> the boxy major mode and related commands, should those be autoloaded?
>
> IIUC `boxy.el` (including the major mode) is not meant to be used
> directly by the end user, so maybe it doesn't need any autoloads because
> the clients will just (require 'boxy) at the top of their file.
> I don't know enough about how `boxy.el` is used by client packages:
> you're in a better position to know.
>

Ok I agree, that is basic use case I was going for.

>>> Oh, I forgot the main question (the one that got me looking more
>>> closely in the first place): why do you use `cl-defmethod` everywhere
>>> yet with only ever a single method defined under the same name?
>> That was so (oref) and (oset) can work without ELC complaining about
>> 'unknown slots'. Is there another macro that uses class specializers?
>
> Hmm... I don't understand why using `cl-defmethod` would silence
> "unknown slot" warnings.  AFAIK those warnings depend solely on whether
> the byte-compiler has seen the corresponding `defclass`.
>

Ah that explains it. I thought it was necessary based on reading the
eieio documentation and I couldn't find any support for the unknown slot
warning. I must've reordered it at some point without realizing that was
what fixed it.

Maybe you can help with a related problem. I tried to define a macro
boxy--inherited:


(defmacro boxy--inherited (fun-name slot default)
  `(defun ,fun-name (box)
     ,(concat "Get the inherited property " (symbol-name slot) " from BOX")
     (if (slot-boundp box ,slot)
         (oref box ,slot)
       (if (slot-boundp box :parent)
           (,fun-name (oref box :parent))
         ,default))))

(boxy--inherited boxy--padding-y :padding-y boxy--default-padding-y)

But this results in
Warning: Unknown slot ‘:padding-y’
Warning: Unknown slot ‘:parent’


>> Also, why not assign custom variables and faces to a group?
>
> Removing those `:group` will not stop them from being assigned to those
> groups (IOW those `:group` args are simply redundant because vars and
> faces are assigned (by default) to the last group defined with `defgroup`).
>
>
>         Stefan

That's neat!

I have two more questions about the patch. First, just to make sure,
would you like to contribute those three diffs and did you sign the FSF
Copyright paperwork?


> +  (let ((inhibit-message t))     ;FIXME: Please report the message as an error.
>      (setq indent-tabs-mode nil)
>      (cursor-sensor-mode t)
>      (toggle-truncate-lines t)))
>

This doesn't even do what I want. I don't want 'Truncate long lines
enabled' to be printed to the minibuffer when entering boxy mode, but it
shows regardless. What exactly does the FIXME mean here and how do I
stop that message?