Blunderbuss ".dir-locals.el" raises everything in its path!!

Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Emacs!

IMAO, the ".dir-locals.el" facility needs fixing.  It is a blunderbuss
weapon of mass destruction, totally sweeping away careful, well
considered, delicately crafted settings made by hackers in other ways.

In particular, it hit Jan Djärv, see:
    bug#3808: 23.1.50; CC-mode: Impossible to set c-cleanup-list.

He set `c-cleanup-list' in his .emacs, but this was obliterated by the

    (c-mode . ((c-file-style . "GNU")))

line in .dir-locals.el.

Ladies and Gentleman, `c-file-style' is for use ONLY in a local variable
list at the end of a file.  This is even documented.  OK, it's only
documented in the CC Mode manual, not the doc string.  `c-file-style'
has the effect of setting lots of CC Mode config stuff, but when it's a
a file local variable list, the hacker can override these implicit
settings with her own explicit ones.

I wasn't aware of .dir-locals.el until today, which is my fault.  But it
seems like a facility thrown in without being properly thought through.
Its settings take priority over everything else, including the user's
hooks, top level setq's, etc.  This is suboptimal in the extreme.

Surely .dir-locals.el should, in some fashion, supply defaults which may
be overridden by mode hooks and the like.  It is almost, but not quite,
entirely unlike file local settings, a rarely used precision instrument.

To emphasise: this thing has caused a real problem to a pretester.  It
needs fixing.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> Surely .dir-locals.el should, in some fashion, supply defaults which may
> be overridden by mode hooks and the like.  It is almost, but not quite,
> entirely unlike file local settings, a rarely used precision instrument.

I'm not sure I understand.  Directory-local variables are processed
right before file-local variables, and can be overridden by them.  See
`hack-local-variables'---the code merely adds extra variables to the
file-local-variables-alist, defined in .dir-locals.el files, before
Emacs adds those defined in the visited file itself.  The local
variables are then processed in order, wrapped by
before/after-hack-local-variables-hook.

Could you try to dig deeper and figure out the problem?

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

On Sun, Jul 12, 2009 at 12:39:29PM -0400, Chong Yidong wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Surely .dir-locals.el should, in some fashion, supply defaults which
> > may be overridden by mode hooks and the like.  It is almost, but not
> > quite, entirely unlike file local settings, a rarely used precision
> > instrument.

> I'm not sure I understand.  Directory-local variables are processed
> right before file-local variables, and can be overridden by them.

Sorry, yes.  But that's the only thing they can be overridden by.  That
is surely not the right thing.  Consider the variable c-cleanup-list
which Jan though he was setting.  Here is a list of the ways of setting

it (taken from the CC Mode manual, page "Config Basics"), disregarding
for now .dir-locals.el:

    Style
    Top-level command or "customization interface"
    Hook
    File Style
    [Explicit setting in file local variables]

, in increasing order of precedence.  This order seems sensible, IMO.
In particular, the File Style and local variables settings are rarely
used precision instruments, for configuring unusual files unusually.

Now add .dir-locals into the mix:

    Style
    Top-level command or "customization interface"
    Hook
    .dir-locals.el             <=====================
    File Style
    [Explicit setting in file local variables]

Why on earch does .dir-locals.el take precedence over values set in a
top-level `setq' or `c-mode-hook'?  This is surely the Wrong Thing to
do.  Jan hat set his own desired value of c-cleanup-list (as a top-level
command), only to have it obliterated by this line:

    (c-mode . ((c-file-style . "GNU")))

in .dir-locals.el.

> See `hack-local-variables'---the code merely adds extra variables to
> the file-local-variables-alist, defined in .dir-locals.el files,
> before Emacs adds those defined in the visited file itself.  The local
> variables are then processed in order, wrapped by
> before/after-hack-local-variables-hook.

> Could you try to dig deeper and figure out the problem?

Yes, we both agree on what is happening.  My point is that the contents
of .dir-locals.el should not override explicit values given by the user
in his .emacs.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[David De La Harpe Golden]

Alan Mackenzie wrote:


> Yes, we both agree on what is happening.  My point is that the contents
> of .dir-locals.el should not override explicit values given by the user
> in his .emacs.
> 

Sorry, but isn't the point of .dir-locals.el to override settings on a 
project tree specific basis, like file locals only for whole directory 
trees? Wouldn't it'd be weird if .emacs "won" ?

I mean, I can see that yes, one might ALSO want a different kind of 
.dir-local.el or file-local setting that doesn't (In the common lisp 
case that could be handled by defvar vs. defparameter, say...)

(The thing that irritates me about dir-locals is their syntactic 
incompatiblity with file-locals.   If I want to promote a file local
I've been setting on a bunch of files to directory local, AFAIK I need 
to rejig the syntax.)

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, David!

On Sun, Jul 12, 2009 at 07:30:57PM +0100, David De La Harpe Golden wrote:
> Alan Mackenzie wrote:

> >Yes, we both agree on what is happening.  My point is that the
> >contents of .dir-locals.el should not override explicit values given
> >by the user in his .emacs.

> Sorry, but isn't the point of .dir-locals.el to override settings on a
> project tree specific basis, like file locals only for whole directory
> trees? Wouldn't it'd be weird if .emacs "won" ?

Please have a look at Jan's bug#3808 to see the exact problem he hit.

One of the more subtle problems of CC Mode is that it "styles" contain
preferences as well as settings.

I find myself opposed to the .dir-locals.el mechanism.  Unlike the file
local variables mechanism, which is used for a definite purpose and is
under the control of the hacker editing the file, .dir-locals.el takes
control away from hackers, it's surreptitious (ls won't list it unless
you give it -a, and often it's not even in the same directory), and it
tends to lead hackers on a frustrating, time wasting search for why their
Emacs is doing strange things, as it just has done for Jan.  Kudos to Jan
for taking the time and trouble to track the problem down.

I think project settings would be better done in the traditional manner
by putting lisp functions into major mode hooks.  Both require elisp
skills after all, so I can't really see what .dir-locals.el saves.

> I mean, I can see that yes, one might ALSO want a different kind of 
> .dir-local.el or file-local setting that doesn't (In the common lisp 
> case that could be handled by defvar vs. defparameter, say...)

AARRRGGGGHHHH!!!  As if we don't don't have enough complexity as it is.

> (The thing that irritates me about dir-locals is their syntactic
> incompatiblity with file-locals.   If I want to promote a file local
> I've been setting on a bunch of files to directory local, AFAIK I need
> to rejig the syntax.)

I'm not convinced this is a bad thing.  They're utterly different things,
even though their implementation is almost the same.  File locals are an
exquisite precision weapon.  Dir locals are a blunderbuss.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Sun, Jul 12, 2009 at 11:39 PM, Alan Mackenzie<acm@muc.de> wrote:
> I find myself opposed to the .dir-locals.el mechanism.  Unlike the file
> local variables mechanism, which is used for a definite purpose and is
> under the control of the hacker editing the file, .dir-locals.el takes
> control away from hackers, it's surreptitious (ls won't list it unless
> you give it -a, and often it's not even in the same directory), and it
> tends to lead hackers on a frustrating, time wasting search for why their
> Emacs is doing strange things, as it just has done for Jan.  Kudos to Jan
> for taking the time and trouble to track the problem down.

It looks to me that many want some kind of project settings and is not
that what .dir-locals.el is supposed to contain? (But why does the
name start with a dot?)


> I think project settings would be better done in the traditional manner
> by putting lisp functions into major mode hooks.  Both require elisp
> skills after all, so I can't really see what .dir-locals.el saves.

Maybe I do not understand what you mean, but is not the real trouble
that those things can be confused? Major mode settings and project
settings are of course two different dimensions. Orthogonal.

However Emacs does not impose that orthogonality. Kind of lack of
typing mechanism. I am surprised that anything local to a major mode
is placed in the project file, but that be just because I do not
understand exactly the things here.


> AARRRGGGGHHHH!!!  As if we don't don't have enough complexity as it is.

We are supposed to grow with it...

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Lennart!

On Mon, Jul 13, 2009 at 12:22:03AM +0200, Lennart Borgman wrote:
> On Sun, Jul 12, 2009 at 11:39 PM, Alan Mackenzie<acm@muc.de> wrote:
> > I find myself opposed to the .dir-locals.el mechanism.  Unlike the
> > file local variables mechanism, which is used for a definite purpose
> > and is under the control of the hacker editing the file,
> > .dir-locals.el takes control away from hackers, it's surreptitious
> > (ls won't list it unless you give it -a, and often it's not even in
> > the same directory), and it tends to lead hackers on a frustrating,
> > time wasting search for why their Emacs is doing strange things, as
> > it just has done for Jan.  Kudos to Jan for taking the time and
> > trouble to track the problem down.

> It looks to me that many want some kind of project settings and is not
> that what .dir-locals.el is supposed to contain? (But why does the
> name start with a dot?)

Yes.  But it differs from all other Emacs configuration in that it is
strangely outwith the control of the person running Emacs.  There isn't
even a flag to disable it.  Or have I missed this option?

> > I think project settings would be better done in the traditional
> > manner by putting lisp functions into major mode hooks.  Both
> > require elisp skills after all, so I can't really see what
> > .dir-locals.el saves.

> Maybe I do not understand what you mean, but is not the real trouble
> that those things can be confused? Major mode settings and project
> settings are of course two different dimensions. Orthogonal.

Are they?  The following (from page "Config Basics" in the CC Mode
manual) shows what I mean:

      (defun my-c-mode-hook ()
        (c-set-style
         (if (and (buffer-file-name)
                  (string-match "/usr/src/linux" (buffer-file-name)))
             "linux"
           "free-group-style")))
      (add-hook 'c-mode-hook 'my-c-mode-hook)

[ .... ]

> > AARRRGGGGHHHH!!!  As if we don't don't have enough complexity as it is.

> We are supposed to grow with it...

We're supposed to fight it on the beaches, ......  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Mon, Jul 13, 2009 at 9:36 AM, Alan Mackenzie<acm@muc.de> wrote:
> Hi, Lennart!

Hi Alan!

>> Maybe I do not understand what you mean, but is not the real trouble
>> that those things can be confused? Major mode settings and project
>> settings are of course two different dimensions. Orthogonal.
>
> Are they?  The following (from page "Config Basics" in the CC Mode
> manual) shows what I mean:
>
>      (defun my-c-mode-hook ()
>        (c-set-style
>         (if (and (buffer-file-name)
>                  (string-match "/usr/src/linux" (buffer-file-name)))
>             "linux"
>           "free-group-style")))
>      (add-hook 'c-mode-hook 'my-c-mode-hook)

Yes, you can mix them and you of course do. But that does not mean
that they are not orthogonal before you do that...

This is a clever example but this way of doing things has
disadvantages that other here has pointed out.

>> > AARRRGGGGHHHH!!!  As if we don't don't have enough complexity as it is.
>
>> We are supposed to grow with it...
>
> We're supposed to fight it on the beaches, ......  ;-)

Yes, we are ...

Add file-locals and dir-locals (was: Blunderbuss ".dir-locals.el" raises everything in its path!!)

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

> (The thing that irritates me about dir-locals is their syntactic
> incompatiblity with file-locals.   If I want to promote a file local
> I've been setting on a bunch of files to directory local, AFAIK I need to
> rejig the syntax.)

It is possible to blur the difference between formats of file-locals and
dir-locals with the help of new commands.  The file etc/TODO has the
following entry:

** Add a command to make a "Local Variables" section in the current buffer
  and/or add a variable to the list.

Below is an initial version of two commands that will close this TODO entry.

`add-file-local-variable' adds file-local variable with its value to the
Local Variables list.  `add-dir-local-variable' adds directory-local
variable with its value and mode to the .dir-locals.el file.  Based on
this implementation another commands could be added later that will
move file-local variables to .dir-locals.el and vice versa.


[-- Attachment #2: add-local.el --]
[-- Type: application/emacs-lisp, Size: 3583 bytes --]

[-- Attachment #3: Type: text/plain, Size: 45 bytes --]


-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[martin rudalics]

 > `add-file-local-variable' adds file-local variable with its value to the
 > Local Variables list.  `add-dir-local-variable' adds directory-local
 > variable with its value and mode to the .dir-locals.el file.  Based on
 > this implementation another commands could be added later that will
 > move file-local variables to .dir-locals.el and vice versa.

Sometimes we also want to replace the old value of a local variable with
a new one here.  So maybe functions like `set-file-local-variable' and
`set-dir-local-variable' seem more appropriate.

martin

Re: Add file-locals and dir-locals

[Juri Linkov]

>> `add-file-local-variable' adds file-local variable with its value to the
>> Local Variables list.  `add-dir-local-variable' adds directory-local
>> variable with its value and mode to the .dir-locals.el file.  Based on
>> this implementation another commands could be added later that will
>> move file-local variables to .dir-locals.el and vice versa.
>
> Sometimes we also want to replace the old value of a local variable with
> a new one here.  So maybe functions like `set-file-local-variable' and
> `set-dir-local-variable' seem more appropriate.

Actually a function `add-file-local-variable' posted already replaces
the existing old value with a new one.  I think to have one function is
better than two (to add and to replace) because from the user's point of
view when the user wants to add a variable we should not require from
the user to check whether this variable already exists in the Local
Variables list.

Since `add-file-local-variable' does both "add" and "replace" operations
it makes sense to rename it to `set-file-local-variable'.  But isn't "set"
rather connotes with an operation that reads a variable's value and sets
it to the variable with setq?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[martin rudalics]

 > Actually a function `add-file-local-variable' posted already replaces
 > the existing old value with a new one.

Sorry, I missed these at a first glance.

 > I think to have one function is
 > better than two (to add and to replace) because from the user's point of
 > view when the user wants to add a variable we should not require from
 > the user to check whether this variable already exists in the Local
 > Variables list.

Obviously.

 > Since `add-file-local-variable' does both "add" and "replace" operations
 > it makes sense to rename it to `set-file-local-variable'.  But isn't "set"
 > rather connotes with an operation that reads a variable's value and sets
 > it to the variable with setq?

I don't care about the name.  But please fix the doc-strings accordingly ;-)

martin

Re: Add file-locals and dir-locals

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

>> Since `add-file-local-variable' does both "add" and "replace" operations
>> it makes sense to rename it to `set-file-local-variable'.  But isn't "set"
>> rather connotes with an operation that reads a variable's value and sets
>> it to the variable with setq?
>
> I don't care about the name.  But please fix the doc-strings accordingly ;-)

This is fixed below.  A new non-interactive function
`modify-file-local-variable' for dealing with internal processing of the
Local Variables list accepts two possible values of the new argument `op':
`add-or-replace' and `delete'.  It is possible to easily change this
function to accept more operations such as `add' that will only add
a new variable but never delete old values and so on.

But I think currently two operations are enough.  From the user's POV
there are two commands `add-file-local-variable' and
`delete-file-local-variable' that rely on the internal function
`modify-file-local-variable'.  The user might want either add a new
variable instead of all its old settings or delete it.


[-- Attachment #2: add-local.el --]
[-- Type: application/emacs-lisp, Size: 4695 bytes --]

[-- Attachment #3: Type: text/plain, Size: 45 bytes --]


-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[martin rudalics]

 > But I think currently two operations are enough.

So do I.

 > From the user's POV
 > there are two commands `add-file-local-variable' and
 > `delete-file-local-variable' that rely on the internal function
 > `modify-file-local-variable'.  The user might want either add a new
 > variable instead of all its old settings or delete it.

I don't quite catch the idea behind

		  (and (search-backward "Local Variables:" nil t)
		       (search-forward "Local Variables:" nil t)))

Do you search the entire buffer here?

Also I didn't find a functionality to remove the headers and trailers as
soon as all settings have been removed.

martin

Re: Add file-locals and dir-locals

[Juri Linkov]

> I don't quite catch the idea behind
>
> 		  (and (search-backward "Local Variables:" nil t)
> 		       (search-forward "Local Variables:" nil t)))
>
> Do you search the entire buffer here?

I had the same doubt that this is sub-ideal.  Thanks, fixed.

> Also I didn't find a functionality to remove the headers and trailers as
> soon as all settings have been removed.

I intentionally omitted this functionality because I think it should
leave a harmless empty placeholder for the user's convenience.

Below is the final patch that I find useful enough to commit.
I invite you and other developers to improve this further as you wish.

Index: etc/TODO
===================================================================
RCS file: /sources/emacs/emacs/etc/TODO,v
retrieving revision 1.205
diff -u -r1.205 TODO
--- etc/TODO	18 Jul 2009 21:04:15 -0000	1.205
+++ etc/TODO	19 Jul 2009 18:05:50 -0000
@@ -202,9 +202,6 @@
 ** Implement something better than the current Refill mode.  This
   probably needs some primitive support.
 
-** Add a command to make a "Local Variables" section in the current buffer
-  and/or add a variable to the list.
-
 ** Implement primitive and higher-level functions to allow filling
   properly with variable-pitch faces.
 
Index: etc/NEWS
===================================================================
RCS file: /sources/emacs/emacs/etc/NEWS,v
retrieving revision 1.2046
diff -c -r1.2046 NEWS
*** etc/NEWS	19 Jul 2009 00:29:52 -0000	1.2046
--- etc/NEWS	19 Jul 2009 18:05:32 -0000
***************
*** 58,63 ****
--- 58,72 ----
  `process-kill-buffer-query-function' from `kill-buffer-query-functions' or
  setting the appropriate process flag with `set-process-query-on-exit-flag'.
  
+ ** New command to add a file-local variable to the "Local Variables" list
+ in the current buffer is `add-file-local-variable'.  New command to remove
+ a file-local variable from the "Local Variables" list is
+ `delete-file-local-variable'.  New commands to add/remove
+ a directory-local variable to/from the .dir-locals.el file are
+ `add-dir-local-variable' and `delete-dir-local-variable'.  New commands to
+ copy file-local variables to directory-local variables and vice versa are
+ `copy-file-locals-to-dir-locals' and `copy-dir-locals-to-file-locals'.
+ 
  \f
  * Changes in Specialized Modes and Packages in Emacs 23.2
  
Index: lisp/files.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/files.el,v
retrieving revision 1.1059
diff -c -r1.1059 files.el
*** lisp/files.el	19 Jul 2009 16:55:16 -0000	1.1059
--- lisp/files.el	19 Jul 2009 18:04:44 -0000
***************
*** 3407,3412 ****
--- 3407,3699 ----
  	    (hack-local-variables-filter variables dir-name)))))))
  
  \f
+ ;;; Commands to add/delete file-local/directory-local variables.
+ 
+ (defun read-file-local-variable (prompt)
+   "Read file-local variable using PROMPT and completion.
+ Intended to be used in the `interactive' spec of
+ `add-file-local-variable', `delete-file-local-variable',
+ `add-dir-local-variable', `delete-dir-local-variable'."
+   (let (default variable)
+     (setq default (variable-at-point))
+     (setq default (and (symbolp default) (boundp default)
+ 		       (symbol-name default)))
+     (setq variable
+ 	  (completing-read
+ 	   (if default
+ 	       (format "%s (default %s): " prompt default)
+ 	     (format "%s: " prompt))
+ 	   obarray
+ 	   (lambda (sym)
+ 	     (or (user-variable-p sym)
+ 		 (memq sym '(mode eval coding unibyte))))
+ 	   nil nil nil default nil))
+     (and (stringp variable) (intern variable))))
+ 
+ (defun read-file-local-variable-value (variable)
+   "Read value of file-local VARIABLE using completion.
+ Intended to be used in the `interactive' spec of
+ `add-file-local-variable' and `add-dir-local-variable'."
+   (let (default value)
+     (cond
+      ((eq variable 'mode)
+       (setq default (and (symbolp major-mode) (symbol-name major-mode)))
+       (setq value
+ 	    (completing-read
+ 	     (if default
+ 		 (format "Add %s with value (default %s): " variable default)
+ 	       (format "Add %s with value: " variable))
+ 	     obarray
+ 	     (lambda (sym)
+ 	       (and (string-match-p "-mode\\'" (symbol-name sym))
+ 		    (not (string-match-p "-minor-mode\\'" (symbol-name sym)))))
+ 	     nil nil nil default nil))
+       (and (stringp value)
+ 	   (intern (replace-regexp-in-string "-mode\\'" "" value))))
+      ((eq variable 'eval)
+       (let ((minibuffer-completing-symbol t))
+ 	(read-from-minibuffer (format "Add %s with expression: " variable)
+ 			      nil read-expression-map t
+ 			      'read-expression-history)))
+      ((eq variable 'coding)
+       (setq default (and (symbolp buffer-file-coding-system)
+ 			 (symbol-name buffer-file-coding-system)))
+       (read-coding-system
+        (if default
+ 	   (format "Add %s with value (default %s): " variable default)
+ 	 (format "Add %s with value: " variable))
+        default))
+      (t
+       (read (read-string (format "Add %s with value: " variable)
+ 			 nil 'set-variable-value-history
+ 			 (format "%S" (symbol-value variable))))))))
+ 
+ (defun read-file-local-variable-mode ()
+   "Read per-directory file-local variable's mode using completion.
+ Intended to be used in the `interactive' spec of
+ `add-dir-local-variable', `delete-dir-local-variable'."
+   (let* ((default (and (symbolp major-mode) (symbol-name major-mode)))
+ 	 (mode
+ 	  (completing-read
+ 	   (if default
+ 	       (format "Mode or subdirectory (default %s): " default)
+ 	     (format "Mode or subdirectory: "))
+ 	   obarray
+ 	   (lambda (sym)
+ 	     (and (string-match-p "-mode\\'" (symbol-name sym))
+ 		  (not (string-match-p "-minor-mode\\'" (symbol-name sym)))))
+ 	   nil nil nil default nil)))
+     (cond
+      ((equal mode "nil") nil)
+      ((and (stringp mode) (fboundp (intern mode))) (intern mode))
+      (t mode))))
+ 
+ (defun modify-file-local-variable (variable value op)
+   "Modify file-local VARIABLE in Local Variables depending on operation OP.
+ 
+ If OP is `add-or-replace' then delete all existing settings of
+ VARIABLE (except `eval') and add a new file-local VARIABLE with VALUE
+ to the Local Variables list.
+ 
+ If there is no Local Variables list in the current file buffer and OP
+ is not `delete' then this function adds the first line containing the
+ string `Local Variables:' and the last line containing the string `End:'.
+ 
+ If OP is `delete' then delete all existing settings of VARIABLE
+ from the Local Variables list ignoring the input argument VALUE."
+   (catch 'exit
+     (let ((startpos (point)) endpos replaced-p)
+       (unless enable-local-variables
+ 	(throw 'exit (message "File-local variables are disabled")))
+ 
+       ;; Look for "Local variables:" line in last page.
+       (goto-char (point-max))
+       (search-backward "\n\^L" (max (- (point-max) 3000) (point-min))
+ 		       'move)
+ 
+       ;; Add "Local variables:" list if not found.
+       (unless (let ((case-fold-search t))
+ 		(search-forward "Local Variables:" nil t))
+ 
+ 	;; Don't add "Local variables:" list for the deletion operation.
+ 	(when (eq op 'delete)
+ 	  (throw 'exit (progn (goto-char startpos)
+ 			      (message "Local Variables not found"))))
+ 
+ 	(goto-char (point-max))
+ 	(let ((comment-style 'plain)
+ 	      (comment-start (or comment-start ";;; ")))
+ 	  (comment-region
+ 	   (prog1 (setq startpos (point))
+ 	     (insert "\nLocal Variables:\nEnd:\n"))
+ 	   (point)))
+ 
+ 	(unless (let ((case-fold-search t))
+ 		  (goto-char startpos)
+ 		  (search-forward "Local Variables:" nil t))
+ 	  (throw 'exit (message "Can't add file-local variables"))))
+ 
+       ;; suffix is what comes after "local variables:" in its line.
+       ;; prefix is what comes before "local variables:" in its line.
+       (let* ((suffix (buffer-substring (point) (line-end-position)))
+ 	     (prefix (buffer-substring (line-beginning-position)
+ 				       (match-beginning 0)))
+ 	     (suffix-re (concat (regexp-quote suffix) "$"))
+ 	     (prefix-re (concat "^" (regexp-quote prefix))))
+ 
+ 	;; Find or add missing "End:".
+ 	(forward-line 1)
+ 	(setq startpos (point))
+ 	(save-excursion
+ 	  (unless (let ((case-fold-search t))
+ 		    (re-search-forward
+ 		     (concat prefix-re "[ \t]*End:[ \t]*" suffix-re)
+ 		     nil t))
+ 	    (save-excursion
+ 	      (insert (format "%sEnd:%s\n" prefix suffix))))
+ 	  (beginning-of-line)
+ 	  (setq endpos (point-marker)))
+ 
+ 	;; Find and delete all existing variable/value pairs.
+ 	(when (member op '(add-or-replace delete))
+ 	  (if (and (eq variable 'eval) (eq op 'add-or-replace))
+ 	      (goto-char endpos)
+ 	    (goto-char startpos)
+ 	    (while (re-search-forward
+ 		    (format "%s%S:.*%s" prefix-re variable suffix-re) endpos t)
+ 	      (delete-region (match-beginning 0) (1+ (match-end 0)))
+ 	      (setq replaced-p t))))
+ 
+ 	;; Add a new variable/value pair.  Add `mode' to the start, add new
+ 	;; variable to the end, and add a replaced variable to its last location.
+ 	(when (eq op 'add-or-replace)
+ 	  (cond
+ 	   ((eq variable 'mode) (goto-char startpos))
+ 	   ((null replaced-p) (goto-char endpos)))
+ 	  (insert (format "%s%S: %S%s\n" prefix variable value suffix)))))))
+ 
+ (defun add-file-local-variable (variable value)
+   "Add file-local VARIABLE with its VALUE to the Local Variables list.
+ 
+ This command deletes all existing settings of VARIABLE (except `eval')
+ and adds a new file-local VARIABLE with VALUE to the Local Variables list.
+ 
+ If there is no Local Variables list in the current file buffer
+ then this function adds the first line containing the string
+ `Local Variables:' and the last line containing the string `End:'."
+   (interactive
+    (let ((variable (read-file-local-variable "Add file-local variable")))
+      (list variable (read-file-local-variable-value variable))))
+   (modify-file-local-variable variable value 'add-or-replace))
+ 
+ (defun delete-file-local-variable (variable)
+   "Delete all settings of file-local VARIABLE from the Local Variables list."
+   (interactive
+    (list (read-file-local-variable "Delete file-local variable")))
+   (modify-file-local-variable variable nil 'delete))
+ 
+ (defun modify-dir-local-variable (mode variable value op)
+   "Modify directory-local VARIABLE in .dir-locals.el depending on operation OP.
+ 
+ If OP is `add-or-replace' then delete all existing settings of
+ VARIABLE (except `eval') and add a new directory-local VARIABLE with VALUE
+ to the MODE alist where MODE can be a mode name symbol or a subdirectory name.
+ 
+ If .dir-locals.el was not found and OP is not `delete' then create
+ this file in the current directory.
+ 
+ If OP is `delete' then delete all existing settings of VARIABLE
+ from the the MODE alist ignoring the input argument VALUE."
+   (catch 'exit
+     (let (replaced-p)
+       (unless enable-local-variables
+ 	(throw 'exit (message "Directory-local variables are disabled")))
+ 
+       (let ((variables-file (or (and (buffer-file-name)
+ 				     (not (file-remote-p (buffer-file-name)))
+ 				     (dir-locals-find-file (buffer-file-name)))
+ 				dir-locals-file))
+ 	    variables)
+ 
+ 	;; Don't create ".dir-locals.el" for the deletion operation.
+ 	(when (and (eq op 'delete)
+ 		   (not (file-exists-p variables-file)))
+ 	  (throw 'exit (message "File .dir-locals.el not found")))
+ 
+ 	(let ((auto-insert nil))
+ 	  (find-file variables-file))
+ 	(goto-char (point-min))
+ 
+ 	;; Read alist of directory-local variables.
+ 	(ignore-errors
+ 	  (delete-region
+ 	   (prog1 (point)
+ 	     (setq variables (let ((read-circle nil))
+ 			       (read (current-buffer)))))
+ 	   (point)))
+ 
+ 	;; Add or replace variable in alist of directory-local variables.
+ 	(let ((mode-assoc (assoc mode variables)))
+ 	  (if mode-assoc
+ 	      (setq variables
+ 		    (cons (cons mode
+ 				(if (eq op 'delete)
+ 				    (assq-delete-all variable (cdr mode-assoc))
+ 				  (cons
+ 				   (cons variable value)
+ 				   (if (eq variable 'eval)
+ 				       (cdr mode-assoc)
+ 				     (assq-delete-all variable (cdr mode-assoc))))))
+ 			  (assq-delete-all mode variables)))
+ 	    (setq variables
+ 		  (cons `(,mode . ((,variable . ,value)))
+ 			variables))))
+ 
+ 	;; Insert modified alist of directory-local variables.
+ 	(insert ";;; Directory Local Variables\n")
+ 	(insert ";;; See (info \"(emacs) Directory Variables\")\n\n")
+ 	(pp (sort variables
+ 		  (lambda (a b)
+ 		    (cond
+ 		     ((null (car a)) t)
+ 		     ((null (car b)) nil)
+ 		     ((and (symbolp (car a)) (stringp (car b))) t)
+ 		     ((and (symbolp (car b)) (stringp (car a))) nil)
+ 		     (t (string< (car a) (car b))))))
+ 	    (current-buffer))))))
+ 
+ (defun add-dir-local-variable (mode variable value)
+   "Add directory-local VARIABLE with its VALUE and MODE to .dir-locals.el."
+   (interactive
+    (let (variable)
+      (list
+       (read-file-local-variable-mode)
+       (setq variable (read-file-local-variable "Add directory-local variable"))
+       (read-file-local-variable-value variable))))
+   (modify-dir-local-variable mode variable value 'add-or-replace))
+ 
+ (defun delete-dir-local-variable (mode variable)
+   "Delete all MODE settings of file-local VARIABLE from .dir-locals.el."
+   (interactive
+    (list
+     (read-file-local-variable-mode)
+     (read-file-local-variable "Delete directory-local variable")))
+   (modify-dir-local-variable mode variable nil 'delete))
+ 
+ (defun copy-file-locals-to-dir-locals ()
+   "Copy file-local variables to .dir-locals.el."
+   (interactive)
+   (dolist (elt file-local-variables-alist)
+     (unless (assq (car elt) dir-local-variables-alist)
+       (add-dir-local-variable major-mode (car elt) (cdr elt)))))
+ 
+ (defun copy-dir-locals-to-file-locals ()
+   "Copy directory-local variables to the Local Variables list."
+   (interactive)
+   (dolist (elt dir-local-variables-alist)
+     (add-file-local-variable (car elt) (cdr elt))))
+ 
+ \f
  (defcustom change-major-mode-with-file-name t
    "Non-nil means \\[write-file] should set the major mode from the file name.
  However, the mode will not be changed if

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[Leo]

On 2009-07-19 19:12 +0100, Juri Linkov wrote:
> Below is the final patch that I find useful enough to commit. I invite
> you and other developers to improve this further as you wish.

Does this patch support adding local variables both in the beginning and
end of buffers?

I'd love to see this applied in trunk so that it can easily tested.
Thanks for the patch.

-- 
Leo's Emacs uptime: 39 days, 22 hours, 49 minutes, 6 seconds

Re: Add file-locals and dir-locals

[Juri Linkov]

>> Below is the final patch that I find useful enough to commit. I invite
>> you and other developers to improve this further as you wish.
>
> Does this patch support adding local variables both in the beginning and
> end of buffers?
>
> I'd love to see this applied in trunk so that it can easily tested.
> Thanks for the patch.

Right, adding local variables to the first line is necessary too.
This requires designing a good UI for that.  One idea is after
executing `M-x add-file-local-variable RET' ask a question like:

  Add variable to the beginning or end of buffer (yes or no)

which obviously always implies "yes".  The problem that the prompt should
mention both alternatives, but yes-or-no-p accepts only "y" or "n".
Using `map-y-or-n-p' to accept other keys will complicate the prompt.
Do you have any better idea?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[Leo]

On 2009-07-22 01:21 +0100, Juri Linkov wrote:
>>> Below is the final patch that I find useful enough to commit. I invite
>>> you and other developers to improve this further as you wish.
>>
>> Does this patch support adding local variables both in the beginning and
>> end of buffers?
>>
>> I'd love to see this applied in trunk so that it can easily tested.
>> Thanks for the patch.
>
> Right, adding local variables to the first line is necessary too.
> This requires designing a good UI for that. 

I forgot to mention in the last post that there is also directory-local
variables, which I think should also be supported. But we can get
support for file local variables first and worry about that later.

> One idea is after executing `M-x add-file-local-variable RET' ask a
> question like:
>
>   Add variable to the beginning or end of buffer (yes or no)
>
> which obviously always implies "yes".  The problem that the prompt should
> mention both alternatives, but yes-or-no-p accepts only "y" or "n".
> Using `map-y-or-n-p' to accept other keys will complicate the prompt.
> Do you have any better idea?

I'd prefer the default to add to the end of a buffer, because file local
variables at the end of a file is more difficult to get right manually.

With one C-u, add to the header

With two C-u, add to .dir-locals.el

Another approach is to give the user a list to select:

 1. head 2. foot 3. dir

-- 
Leo's Emacs uptime: 41 days, 13 hours, 58 minutes, 31 seconds

Re: Add file-locals and dir-locals

[Juri Linkov]

> I forgot to mention in the last post that there is also directory-local
> variables, which I think should also be supported. But we can get
> support for file local variables first and worry about that later.

This was implemented already.

> I'd prefer the default to add to the end of a buffer, because file local
> variables at the end of a file is more difficult to get right manually.
>
> With one C-u, add to the header
>
> With two C-u, add to .dir-locals.el

This requires from the user leaning and remembering
how many C-u to type.

> Another approach is to give the user a list to select:
>
>  1. head 2. foot 3. dir

This is not convenient to use.

Meanwhile I implemented new commands `add-file-local-variable-prop-line'
and `delete-file-local-variable-prop-line'.  The suffix `-prop-line'
is by analogy with the pair of functions `hack-local-variables' and
`hack-local-variables-prop-line'.

As not frequently used commands, it's not difficult for the user to
select the necessary command using completions for M-x:

M-x add-file-local-variable RET
M-x add-file-local-variable-prop-line RET
M-x add-dir-local-variable RET

Please try these commands and tell what do you think.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[Leo]

On 2009-08-05 00:59 +0100, Juri Linkov wrote:
[...]
>> I'd prefer the default to add to the end of a buffer, because file local
>> variables at the end of a file is more difficult to get right manually.
>>
>> With one C-u, add to the header
>>
>> With two C-u, add to .dir-locals.el
>
> This requires from the user leaning and remembering how many C-u to
> type.

On a second thought, this is indeed pretty bad.

>> Another approach is to give the user a list to select:
>>
>>  1. head 2. foot 3. dir
>
> This is not convenient to use.
>
> Meanwhile I implemented new commands `add-file-local-variable-prop-line'
> and `delete-file-local-variable-prop-line'.  The suffix `-prop-line'
> is by analogy with the pair of functions `hack-local-variables' and
> `hack-local-variables-prop-line'.
>
> As not frequently used commands, it's not difficult for the user to
> select the necessary command using completions for M-x:
>
> M-x add-file-local-variable RET
> M-x add-file-local-variable-prop-line RET
> M-x add-dir-local-variable RET
>
> Please try these commands and tell what do you think.

I have tried these commands briefly and they seem to work fine.

For the first two commands, if they are called interactively, do you
think the file variables should be evaled after being added?

-- 
Leo's Emacs uptime: 1 day, 1 hour, 48 minutes, 43 seconds

Re: Add file-locals and dir-locals

[Juri Linkov]

>> As not frequently used commands, it's not difficult for the user to
>> select the necessary command using completions for M-x:
>>
>> M-x add-file-local-variable RET
>> M-x add-file-local-variable-prop-line RET
>> M-x add-dir-local-variable RET
>>
>> Please try these commands and tell what do you think.
>
> I have tried these commands briefly and they seem to work fine.
>
> For the first two commands, if they are called interactively, do you
> think the file variables should be evaled after being added?

Interesting question.  Formally speaking, evaluating them seems right to
keep local variables consistent with real values in the current buffer.

But such evaluation requires also executing all safety mechanisms that
also may ask a question whether a variable is safe.

Since there is no such associated burden while adding local variables
manually I don't think this is the right thing to do when adding them
automatically.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[Leo]

On 2009-08-05 22:52 +0100, Juri Linkov wrote:
>> For the first two commands, if they are called interactively, do you
>> think the file variables should be evaled after being added?
>
> Interesting question. Formally speaking, evaluating them seems right
> to keep local variables consistent with real values in the current
> buffer.
>
> But such evaluation requires also executing all safety mechanisms that
> also may ask a question whether a variable is safe.

By executing all safety mechanisms, do you mean calling
`hack-local-variables' or `hack-local-variables-prop-line'?

The question whether a variable is safe or not will be asked anyway i.e.
the next time the file is opened. And it is probably better be asked
when it is added since at this time the user has better idea what to do
with it.

There are local variables that can not be activated easily except by
re-opening the file.

> Since there is no such associated burden while adding local variables
> manually I don't think this is the right thing to do when adding them
> automatically.

-- 
Leo's Emacs uptime: 1 day, 22 hours, 51 minutes, 33 seconds

Re: Add file-locals and dir-locals

[Juri Linkov]

>>> For the first two commands, if they are called interactively, do you
>>> think the file variables should be evaled after being added?
>>
>> Interesting question. Formally speaking, evaluating them seems right
>> to keep local variables consistent with real values in the current
>> buffer.
>>
>> But such evaluation requires also executing all safety mechanisms that
>> also may ask a question whether a variable is safe.
>
> By executing all safety mechanisms, do you mean calling
> `hack-local-variables' or `hack-local-variables-prop-line'?

Yes, these and `hack-local-variables-confirm'.

> The question whether a variable is safe or not will be asked anyway
> i.e.  the next time the file is opened. And it is probably better be
> asked when it is added since at this time the user has better idea
> what to do with it.

The value is not applied and the question is not asked when the user
manually types the settings in the Local Variables section.  New commands
are just more convenient way to do the same.  So I think applying the
value immediately would be unexpected for users.

Another reason not to apply settings immediately are commands that
delete local variables: delete-file-local-variable(-prop-line) and
delete-dir-local-variable.  For consistency it would be logical
for these commands to unset the value after deleting the corresponding
setting from local variables.  But what is the value to revert
the variable after deleting its value to?  nil?  Some of previous
old values?  There is no certain answer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[Leo]

On 2009-08-06 21:36 +0100, Juri Linkov wrote:
>> The question whether a variable is safe or not will be asked anyway
>> i.e.  the next time the file is opened. And it is probably better be
>> asked when it is added since at this time the user has better idea
>> what to do with it.
>
> The value is not applied and the question is not asked when the user
> manually types the settings in the Local Variables section.  New commands
> are just more convenient way to do the same.  So I think applying the
> value immediately would be unexpected for users.
>
> Another reason not to apply settings immediately are commands that
> delete local variables: delete-file-local-variable(-prop-line) and
> delete-dir-local-variable.  For consistency it would be logical
> for these commands to unset the value after deleting the corresponding
> setting from local variables.  But what is the value to revert
> the variable after deleting its value to?  nil?  Some of previous
> old values?  There is no certain answer.

OK in this case let's leave it as is.

-- 
Leo's Emacs uptime: 3 days, 1 hour, 15 minutes, 31 seconds

Re: Add file-locals and dir-locals

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > > I forgot to mention in the last post that there is also directory-local
  > > variables, which I think should also be supported. But we can get
  > > support for file local variables first and worry about that later.
  > 
  > This was implemented already.
  > 
  > > I'd prefer the default to add to the end of a buffer, because file local
  > > variables at the end of a file is more difficult to get right manually.
  > >
  > > With one C-u, add to the header
  > >
  > > With two C-u, add to .dir-locals.el
  > 
  > This requires from the user leaning and remembering
  > how many C-u to type.
  > 
  > > Another approach is to give the user a list to select:
  > >
  > >  1. head 2. foot 3. dir
  > 
  > This is not convenient to use.
  > 
  > Meanwhile I implemented new commands `add-file-local-variable-prop-line'
  > and `delete-file-local-variable-prop-line'.  The suffix `-prop-line'
  > is by analogy with the pair of functions `hack-local-variables' and
  > `hack-local-variables-prop-line'.
  > 
  > As not frequently used commands, it's not difficult for the user to
  > select the necessary command using completions for M-x:
  > 
  > M-x add-file-local-variable RET
  > M-x add-file-local-variable-prop-line RET
  > M-x add-dir-local-variable RET

These are nice and useful, but do they need to be in files.el?
files.el is in the dumped image, and these functions are not going to be
used all the often, so putting them in a separate file seems more in
line with the way they will be used.  WDYT?

Re: Add file-locals and dir-locals

[Juri Linkov]

>   > As not frequently used commands, it's not difficult for the user
>   > to select the necessary command using completions for M-x:
>   >
>   > M-x add-file-local-variable RET
>   > M-x add-file-local-variable-prop-line RET
>   > M-x add-dir-local-variable RET
>
> These are nice and useful, but do they need to be in files.el?
> files.el is in the dumped image, and these functions are not going to be
> used all the often, so putting them in a separate file seems more in
> line with the way they will be used.  WDYT?

I completely agree.

The usual convention for a file with additional functionality is to add
the prefix "-x" to the file name.  This means creating a new file with the
name "files-x.el" and putting here all code that should not be in the
dumped image.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[Stefan Monnier]

>> These are nice and useful, but do they need to be in files.el?
> I completely agree.

Agreed.

> The usual convention for a file with additional functionality is to add
> the prefix "-x" to the file name.  This means creating a new file with the
> name "files-x.el" and putting here all code that should not be in the
> dumped image.

I'm not really excited about putting just those 3 new commands all on
their own in a separate file, tho.  Maybe we could find other commands
to go along?  Or maybe it could be moved elsewhere (not sure where,
tho.  Conceptually it's related to customization, so maybe it could fit
into one of the cus*.el file).


        Stefan

Re: Add file-locals and dir-locals

[Juri Linkov]

>>> These are nice and useful, but do they need to be in files.el?
>> I completely agree.
>
> Agreed.
>
>> The usual convention for a file with additional functionality is to add
>> the prefix "-x" to the file name.  This means creating a new file with the
>> name "files-x.el" and putting here all code that should not be in the
>> dumped image.
>
> I'm not really excited about putting just those 3 new commands all on
> their own in a separate file, tho.

Actually, 9 commands and 6 functions.  There are many files in the lisp
directory with less functions (but I don't support such partitioning to
small files).

> Maybe we could find other commands to go along?

Yes, there are more infrequently used file-related commands like
e.g. `read-file-modes' etc.  That's why I proposed a general name
"files-x.el" to open it for wider file-related additions.

> Or maybe it could be moved elsewhere (not sure where, tho.

I can't find a better place.

> Conceptually it's related to customization, so maybe it could fit
> into one of the cus*.el file).

All cus*.el files contain code strictly for the Customization UI.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Add file-locals and dir-locals

[Leo]

On 2009-08-08 21:43 +0100, Juri Linkov wrote:
> Yes, there are more infrequently used file-related commands like e.g.
> `read-file-modes' etc. That's why I proposed a general name
> "files-x.el" to open it for wider file-related additions.

There are not many file names with '-x'. Why not use a proper file name?

-- 
Leo's Emacs uptime: 4 days, 21 hours, 11 minutes, 0 seconds

Re: Add file-locals and dir-locals

[Juri Linkov]

>> Yes, there are more infrequently used file-related commands like e.g.
>> `read-file-modes' etc. That's why I proposed a general name
>> "files-x.el" to open it for wider file-related additions.
>
> There are not many file names with '-x'.

As I already explained, with a general name files-x.el is intended to
contain more file-related functions that don't fit into the dumped image.

I hesitate to create a special file only for the functionality of
adding local variables.

> Why not use a proper file name?

files-x.el is a quite proper name even for adding file local variables:
a mnemonics for files-x.el could be "files extended".  That's what new
commands do: they extend files with file local variables :)

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Add file-locals and dir-locals

[Drew Adams]

Question from ignorance - ignore if irrelevant.

When dumping, is the granularity necessarily a complete file? Would it be
feasible and worthwhile to have some kind of macro that could be wrapped around
only those forms to be used when dumping (or only those forms not to be used for
dumping)?

IOW, instead of splitting a file in two purely for the sake of dumping only part
of it, would it be feasible and useful to have an Lisp construct that declares
certain forms for dumping (or for not dumping)?

Again, ignore if this makes no sense. Splitting a file for only this reason just
seems a bit weird on the face of it.

--------

> As I already explained, with a general name files-x.el is intended to
> contain more file-related functions that don't fit into the 
> dumped image.
> 
> I hesitate to create a special file only for the functionality of
> adding local variables.

Re: Add file-locals and dir-locals

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 8 Aug 2009 14:58:30 -0700
> Cc: emacs-devel@gnu.org
> 
> When dumping, is the granularity necessarily a complete file? Would it be
> feasible and worthwhile to have some kind of macro that could be wrapped around
> only those forms to be used when dumping (or only those forms not to be used for
> dumping)?

Dumping creates an Emacs executable that includes everything that was
loaded prior to dumping.  Technically, it's a more-or-less exact image
of the memory Emacs had.  So the only way to remove parts of the
loaded packages would be to unload those parts from memory.  We
currently have only unload-feature, which is not granular enough.  I
don't know how hard it would be to do what you suggest, but it doesn't
seem easy to me.  Maybe I'm missing some infrastructure.

Re: Add file-locals and dir-locals

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Dumping creates an Emacs executable that includes everything that was
 > loaded prior to dumping.  Technically, it's a more-or-less exact image
 > of the memory Emacs had.  So the only way to remove parts of the
 > loaded packages would be to unload those parts from memory.  We
 > currently have only unload-feature, which is not granular enough.

And in any case, that's only half-done.  Then you need to successfully
garbage-collect the space containing dead data (unloaded features), or
you're doing nobody any favors.

For this proposal to make practical sense, you'd need a compacting
garbage collector, but that's difficult (except for special cases like
string data where you expect there should be exactly one reference).

Re: Add file-locals and dir-locals

[Stefan Monnier]

> Yes, there are more infrequently used file-related commands like
> e.g. `read-file-modes' etc.  That's why I proposed a general name
> "files-x.el" to open it for wider file-related additions.

I guess it's OK, then.


        Stefan

Re: Add file-locals and dir-locals

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> (The thing that irritates me about dir-locals is their syntactic
>> incompatiblity with file-locals.   If I want to promote a file local
>> I've been setting on a bunch of files to directory local, AFAIK I need to
>> rejig the syntax.)
>
> It is possible to blur the difference between formats of file-locals and
> dir-locals with the help of new commands.  The file etc/TODO has the
> following entry:
>
> ** Add a command to make a "Local Variables" section in the current buffer
>   and/or add a variable to the list.
>
> Below is an initial version of two commands that will close this TODO
> entry.

Wouldn't it be easier if any file variables in the .dir-locals file
would count as dir-local?  Then copying them around would be much more
natural.  Obvious disadvantages:

a) if different line prefixes are used in different files, when
combining them, one has to massage them.

b) file-locals for the .dir-locals.el file are not feasible.

-- 
David Kastrup

Re: Add file-locals and dir-locals

[Juri Linkov]

> Wouldn't it be easier if any file variables in the .dir-locals file
> would count as dir-local?  Then copying them around would be much more
> natural.  Obvious disadvantages:
>
> a) if different line prefixes are used in different files, when
> combining them, one has to massage them.
>
> b) file-locals for the .dir-locals.el file are not feasible.

Generally would be good, but a stopper is the need to add mode names
to subsets of mode-specific file-locals.  Currently .dir-locals.el
groups them by modes like:

((c-mode . ((c-file-style . "GNU")))
 (change-log-mode . ((add-log-time-zone-rule . t)
		     (fill-column . 74))))

I already proposed the following format for the dir-locals file
syntactically compatible with the file-locals format:

-*- mode: c -*-
Local variables:
c-file-style: "GNU"
End:

-*- mode: change-log -*-
Local variables:
add-log-time-zone-rule: t
fill-column: 74
End:

But this syntax is not Lispish.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

>> I'm not sure I understand.  Directory-local variables are processed
>> right before file-local variables, and can be overridden by them.
>
> Sorry, yes.  But that's the only thing they can be overridden by.  That
> is surely not the right thing.
>
> Why on earth does .dir-locals.el take precedence over values set in a
> top-level `setq' or `c-mode-hook'?  This is surely the Wrong Thing to
> do.

Because setting a directory-local variable is supposed to have the same
effect as setting a file-local variable inside every file in that
directory.  Thus, instead of putting c-fill-style inside every .c file
in the Emacs source tree, you can simply write a .dir-locals.el file.

> In particular, the File Style and local variables settings are rarely
> used precision instruments, for configuring unusual files unusually.

This indicates that we should not set c-file-style in the .dir-locals.el
file of the Emacs source tree.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Yidong!

On Sun, Jul 12, 2009 at 02:37:05PM -0400, Chong Yidong wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> I'm not sure I understand.  Directory-local variables are processed
> >> right before file-local variables, and can be overridden by them.

> > Sorry, yes.  But that's the only thing they can be overridden by.  That
> > is surely not the right thing.

> > Why on earth does .dir-locals.el take precedence over values set in a
> > top-level `setq' or `c-mode-hook'?  This is surely the Wrong Thing to
> > do.

> Because setting a directory-local variable is supposed to have the same
> effect as setting a file-local variable inside every file in that
> directory.  Thus, instead of putting c-fill-style inside every .c file
> in the Emacs source tree, you can simply write a .dir-locals.el file.

> > In particular, the File Style and local variables settings are rarely
> > used precision instruments, for configuring unusual files unusually.

> This indicates that we should not set c-file-style in the .dir-locals.el
> file of the Emacs source tree.

That's fine by me!  As well as amending that file, I've juiced up the doc
strings in the two pertinent CC Mode variables, and put some stuff into
the Emacs and Elisp manuals.

I'd be grateful for somebody checking my prose.

Incidentally, I've expanded the inane sentence that says that (project)
files are kept in directories.  I think most people knew that already.
;-)


Index: .dir-locals.el
===================================================================
RCS file: /cvsroot/emacs/emacs/.dir-locals.el,v
retrieving revision 1.6
diff -c -r1.6 .dir-locals.el
*** .dir-locals.el	14 Jan 2009 23:16:12 -0000	1.6
--- .dir-locals.el	12 Jul 2009 21:09:42 -0000
***************
*** 1,6 ****
  ((nil . ((tab-width . 8)
           (fill-column . 70)))
-  (c-mode . ((c-file-style . "GNU")))
   (change-log-mode . ((add-log-time-zone-rule . t)
  		     (fill-column . 74)
  		     (bug-reference-url-format
--- 1,5 ----
Index: doc/emacs/custom.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/doc/emacs/custom.texi,v
retrieving revision 1.22
diff -c -r1.22 custom.texi
*** doc/emacs/custom.texi	4 Jun 2009 03:13:28 -0000	1.22
--- doc/emacs/custom.texi	12 Jul 2009 21:09:44 -0000
***************
*** 1267,1279 ****
  @cindex per-directory local variables
  
    A @dfn{project} is a collection of files on which you work together.
! Usually, the project's files are kept in one or more directories.
! Occasionally, you may wish to define Emacs settings that are common to
! all the files that belong to the project.
  
    Emacs provides two ways to specify settings that are applicable to
  files in a specific directory: you can put a special file in that
! directory, or you can define a @dfn{project class} for that directory.
  
  @cindex @file{.dir-locals.el} file
    If you put a file with a special name @file{.dir-locals.el}@footnote{
--- 1267,1288 ----
  @cindex per-directory local variables
  
    A @dfn{project} is a collection of files on which you work together.
! Usually, the project's files are kept in one or more directories of
! their own.  Occasionally, you may wish to define Emacs settings that
! are common to all the files that belong to the project.
  
    Emacs provides two ways to specify settings that are applicable to
  files in a specific directory: you can put a special file in that
! directory, or you can define a @dfn{project class} for that
! directory.
! 
! Note that Emacs applies these settings for each file it loads, after
! having initialized the file's major mode and run the mode hook.  These
! settings can override those made by a user in his .emacs, possibly in
! a mode hook, so you should be careful not to set variables which are a
! matter of personal choice.  You should probably not set
! @code{c-file-syle} and @code{c-file-offsets} here (@pxref{File
! Styles,,,ccmode}).
  
  @cindex @file{.dir-locals.el} file
    If you put a file with a special name @file{.dir-locals.el}@footnote{
***************
*** 1302,1309 ****
  ((nil . ((indent-tabs-mode . t)
           (tab-width . 4)
           (fill-column . 80)))
-  (c-mode . ((c-file-style . "BSD")))
-  (java-mode . ((c-file-style . "BSD")))
   ("src/imported"
    . ((nil . ((change-log-default-name . "ChangeLog.local"))))))
  @end example
--- 1311,1316 ----
Index: doc/lispref/variables.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/doc/lispref/variables.texi,v
retrieving revision 1.19
diff -c -r1.19 variables.texi
*** doc/lispref/variables.texi	17 Jun 2009 02:58:57 -0000	1.19
--- doc/lispref/variables.texi	12 Jul 2009 21:09:53 -0000
***************
*** 1703,1708 ****
--- 1703,1716 ----
  variables: by putting them in a special file, or by defining a
  @dfn{project class} for that directory.
  
+ Note that Emacs applies these settings for each file it loads, after
+ having initialized the file's major mode and run the mode hook
+ (@pxref{Mode Hooks}).  These settings can override those made by a
+ user in his .emacs, possibly in a mode hook, so you should be careful
+ not to set variables which are a matter of personal choice.  You
+ should probably not set @code{c-file-syle} and @code{c-file-offsets}
+ here (@pxref{File Styles,,,ccmode}).
+ 
  @defvr Constant dir-locals-file
  This constant is the name of the file where Emacs expects to find the
  directory-local variables.  The name of the file is
Index: lisp/progmodes/cc-vars.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/cc-vars.el,v
retrieving revision 1.73
diff -c -r1.73 cc-vars.el
*** lisp/progmodes/cc-vars.el	30 Apr 2009 10:36:24 -0000	1.73
--- lisp/progmodes/cc-vars.el	12 Jul 2009 21:09:55 -0000
***************
*** 1608,1613 ****
--- 1608,1618 ----
  string suitable for `c-set-style'.  When the file is visited, CC Mode
  will set the style of the file to this value automatically.
  
+ Don't use this variable anywhere but a file's Local Variable section.
+ You probably don't want to use this in a .dir-locals.el file, since
+ this would nullify any explicit settings of style variables at the
+ top level or in hooks.
+ 
  Note that file style settings are applied before file offset settings
  as designated in the variable `c-file-offsets'.")
  (make-variable-buffer-local 'c-file-style)
***************
*** 1620,1625 ****
--- 1625,1635 ----
  When the file is visited, CC Mode will institute these offset settings
  automatically.
  
+ Don't use this variable anywhere but a file's Local Variable section.
+ You probably don't want to use this in a .dir-locals.el file, since
+ this would nullify any explicit settings of style variables at the
+ top level or in hooks.
+ 
  Note that file offset settings are applied after file style settings
  as designated in the variable `c-file-style'.")
  (make-variable-buffer-local 'c-file-offsets)


Goodnight!
 
-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Sun, Jul 12, 2009 at 11:21 PM, Alan Mackenzie<acm@muc.de> wrote:
> *** doc/emacs/custom.texi       4 Jun 2009 03:13:28 -0000       1.22
>    A @dfn{project} is a collection of files on which you work together.
> ! Usually, the project's files are kept in one or more directories of
> ! their own.  Occasionally, you may wish to define Emacs settings that
> ! are common to all the files that belong to the project.

Shouldn't it be "directory trees"?

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Lennart!

On Sun, Jul 12, 2009 at 11:33:46PM +0200, Lennart Borgman wrote:

> On Sun, Jul 12, 2009 at 11:21 PM, Alan Mackenzie<acm@muc.de> wrote:

> > *** doc/emacs/custom.texi       4 Jun 2009 03:13:28 -0000       1.22
> >    A @dfn{project} is a collection of files on which you work together.
> > ! Usually, the project's files are kept in one or more directories of
> > ! their own.  Occasionally, you may wish to define Emacs settings that
> > ! are common to all the files that belong to the project.

> Shouldn't it be "directory trees"?

I don't think it should.  It adds verbiage without really adding
meaning.  All directories are in trees, even a single directory on a
floppy disk being a (somewhat degenerate) tree.  I think you're thinking
about .dir-locals.el applying recursively to its subdirectories, but I
don't think using "directory tree" at this point in the text would help
people understand that subtelty.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Sun, Jul 12, 2009 at 11:45 PM, Alan Mackenzie<acm@muc.de> wrote:
> Hi, Lennart!
>
> On Sun, Jul 12, 2009 at 11:33:46PM +0200, Lennart Borgman wrote:
>
>> On Sun, Jul 12, 2009 at 11:21 PM, Alan Mackenzie<acm@muc.de> wrote:
>
>> > *** doc/emacs/custom.texi       4 Jun 2009 03:13:28 -0000       1.22
>> >    A @dfn{project} is a collection of files on which you work together.
>> > ! Usually, the project's files are kept in one or more directories of
>> > ! their own.  Occasionally, you may wish to define Emacs settings that
>> > ! are common to all the files that belong to the project.
>
>> Shouldn't it be "directory trees"?
>
> I don't think it should.  It adds verbiage without really adding
> meaning.  All directories are in trees, even a single directory on a
> floppy disk being a (somewhat degenerate) tree.  I think you're thinking
> about .dir-locals.el applying recursively to its subdirectories, but I
> don't think using "directory tree" at this point in the text would help
> people understand that subtelty.

Hi Alan!

Yes, I think of that, but it is essential, not a subtelty. (Compare
for example lgrep/rgrep.)

Adding that single word "tree" clarifies that difference. Why don't
you think it would help.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stephen J. Turnbull]

Lennart Borgman writes:

 > Adding that single word "tree" clarifies that difference. Why don't
 > you think it would help.

Because the recursive nature is already indicated by the phrase "all
files of".

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Mon, Jul 13, 2009 at 5:23 AM, Stephen J. Turnbull<stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>
>  > Adding that single word "tree" clarifies that difference. Why don't
>  > you think it would help.
>
> Because the recursive nature is already indicated by the phrase "all
> files of".

That assumes that the user already knows that a project can store
files in sub directories of the project directory tree root. I do not
think we can assume that for all users.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jul 12, 2009 at 09:45:52PM +0000, Alan Mackenzie wrote:
> Hi, Lennart!
> 
> On Sun, Jul 12, 2009 at 11:33:46PM +0200, Lennart Borgman wrote:
> 
> > On Sun, Jul 12, 2009 at 11:21 PM, Alan Mackenzie<acm@muc.de> wrote:
> 
> > > *** doc/emacs/custom.texi       4 Jun 2009 03:13:28 -0000       1.22
> > >    A @dfn{project} is a collection of files on which you work together.
> > > ! Usually, the project's files are kept in one or more directories of
> > > ! their own.  Occasionally, you may wish to define Emacs settings that
> > > ! are common to all the files that belong to the project.
> 
> > Shouldn't it be "directory trees"?
> 
> I don't think it should [...]

FWIW yes, it would give me a little clue. Without the little word (and
without knowing in advance ;) I would be left asking whether this
settings only apply to this directory level or recursively downtree.

But I see that it's definitely a matter of taste.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKWsEDBcgs9XrR2kYRAsgZAJ9ikEQQbF0eoC3mT14zoEm1UroilQCdEbg8
thjVeZaJ+xFC+WUMdpY2Fw8=
=APT0
-----END PGP SIGNATURE-----

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Giorgos Keramidas]

On Sun, 12 Jul 2009 21:21:03 +0000, Alan Mackenzie <acm@muc.de> wrote:
> That's fine by me!  As well as amending that file, I've juiced up the doc
> strings in the two pertinent CC Mode variables, and put some stuff into
> the Emacs and Elisp manuals.

> Index: doc/emacs/custom.texi
> ===================================================================
...
> --- 1267,1288 ----
...
> ! Note that Emacs applies these settings for each file it loads, after
> ! having initialized the file's major mode and run the mode hook.  These
> ! settings can override those made by a user in his .emacs, possibly in
> ! a mode hook, so you should be careful not to set variables which are a
> ! matter of personal choice.  You should probably not set
> ! @code{c-file-syle} and @code{c-file-offsets} here (@pxref{File
> ! Styles,,,ccmode}).

That seems like a good and useful note.  Thanks :)

There's a tiny typo in the new text.  `c-file-syle' should be
`c-file-style'.  The same typo is repeated in the new text of
`doc/lispref/variables.texi'.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

On Mon, Jul 13, 2009 at 06:23:21AM +0300, Giorgos Keramidas wrote:
> On Sun, 12 Jul 2009 21:21:03 +0000, Alan Mackenzie <acm@muc.de> wrote:
> > That's fine by me!  As well as amending that file, I've juiced up the doc
> > strings in the two pertinent CC Mode variables, and put some stuff into
> > the Emacs and Elisp manuals.

> > Index: doc/emacs/custom.texi
> > ===================================================================
> ...
> > --- 1267,1288 ----
> ...
> > ! Note that Emacs applies these settings for each file it loads, after
> > ! having initialized the file's major mode and run the mode hook.  These
> > ! settings can override those made by a user in his .emacs, possibly in
> > ! a mode hook, so you should be careful not to set variables which are a
> > ! matter of personal choice.  You should probably not set
> > ! @code{c-file-syle} and @code{c-file-offsets} here (@pxref{File
> > ! Styles,,,ccmode}).

> That seems like a good and useful note.  Thanks :)

> There's a tiny typo in the new text.  `c-file-syle' should be
> `c-file-style'.  The same typo is repeated in the new text of
> `doc/lispref/variables.texi'.

Thanks!  I've corrected it here, ready for being committed.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> ! Note that Emacs applies these settings for each file it loads, after
> ! having initialized the file's major mode and run the mode hook.  These
> ! settings can override those made by a user in his .emacs
> ! so you should be careful not to set variables which are a
> ! matter of personal choice.  You should probably not set
> ! @code{c-file-syle} and @code{c-file-offsets} here (@pxref{File
> ! Styles,,,ccmode}).

The manual should say "init file" rather than ".emacs".

But I think we have a basic disagreement here.  A user should feel free
to set directory local variables that override his or her .emacs
settings---exactly like he or she should feel free to write file-local
variables.  The manual has no purpose telling people what to do with
their own files.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
>> ! These settings can override those made by a user in his .emacs so
>> ! you should be careful not to set variables which are a matter of
>> ! personal choice.  You should probably not set @code{c-file-syle}
>> ! and @code{c-file-offsets} here (@pxref{File Styles,,,ccmode}).
>
> But I think we have a basic disagreement here.  A user should feel
> free to set directory local variables that override his or her .emacs
> settings---exactly like he or she should feel free to write file-local
> variables.  The manual has no purpose telling people what to do with
> their own files.

It also seems downright bizarre to tell people not to set c-file-style
in .dir-settings.el -- my sense is that most developers would agree that
if a project has C style conventions, they should override the user's
personal preferences...

[and painful memories of source code where basic things like indentation
levels varied line-to-line within functions makes me grateful for any
method that helps automate project conventions!]

-Miles

-- 
Future, n. That period of time in which our affairs prosper, our friends
are true and our happiness is assured.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stephen J. Turnbull]

Miles Bader writes:
 > Chong Yidong <cyd@stupidchicken.com> writes:
 > >> ! These settings can override those made by a user in his .emacs so
 > >> ! you should be careful not to set variables which are a matter of
 > >> ! personal choice.  You should probably not set @code{c-file-syle}
 > >> ! and @code{c-file-offsets} here (@pxref{File Styles,,,ccmode}).
 > >
 > > But I think we have a basic disagreement here.  A user should feel
 > > free to set directory local variables that override his or her .emacs
 > > settings---exactly like he or she should feel free to write file-local
 > > variables.  The manual has no purpose telling people what to do with
 > > their own files.

I don't understand what you are saying.  The manual has done that
forever!  There is specific advice *not* to set auto-fill mode in
local variables, for example.

And there is good reason for that.  Files are *not* "of the user".
Files are a means of communication.  Sometimes indeed they are memos
to oneself in the future, but more often they are for communicating
with others.

The issue Alan is raising is precisely that *somebody else* is
overriding the user's settings.  I agree with Miles:

 > It also seems downright bizarre to tell people not to set c-file-style
 > in .dir-settings.el -- my sense is that most developers would agree that
 > if a project has C style conventions, they should override the user's
 > personal preferences...

Indeed.  I think that needs to be sorted out here is Alan's intuition
that C style conventions are a matter of personal preference.  IMO if
they are, that's because the user himself is the Benevolent Dictator
for his project, and "everybody has a right to choose to follow
personal preferences, as long as that person is the dictator". :)  Now
that's only my opinion, but it seems to be Miles's, and whoever wrote
the .dir-locals.el in question, and .... :)

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Morning, Stephen!

On Mon, Jul 13, 2009 at 03:22:17PM +0900, Stephen J. Turnbull wrote:
> Miles Bader writes:
>  > Chong Yidong <cyd@stupidchicken.com> writes:
>  > >> ! These settings can override those made by a user in his .emacs so
>  > >> ! you should be careful not to set variables which are a matter of
>  > >> ! personal choice.  You should probably not set @code{c-file-syle}
>  > >> ! and @code{c-file-offsets} here (@pxref{File Styles,,,ccmode}).

>  > > But I think we have a basic disagreement here.  A user should feel
>  > > free to set directory local variables that override his or her .emacs
>  > > settings---exactly like he or she should feel free to write file-local
>  > > variables.  The manual has no purpose telling people what to do with
>  > > their own files.

> I don't understand what you are saying.  The manual has done that
> forever!  There is specific advice *not* to set auto-fill mode in
> local variables, for example.

> And there is good reason for that.  Files are *not* "of the user".
> Files are a means of communication.  Sometimes indeed they are memos
> to oneself in the future, but more often they are for communicating
> with others.

> The issue Alan is raising is precisely that *somebody else* is
> overriding the user's settings.

Thank you!  That is EXACTLY what I'm raising.  What's more, the
overriding is surreptitious - it took Jan some time to find out what was
going wrong.  How do you turn off this .dir-locals.el thingy?

I agree with Miles:

>  > It also seems downright bizarre to tell people not to set
>  > c-file-style in .dir-settings.el -- my sense is that most developers
>  > would agree that if a project has C style conventions, they should
>  > override the user's personal preferences...

No.  They should act as a project wide default, which a user can
occasionally vary as he sees fit.  The problem is not that .dir-locals.el
exists, but that it takes precedence over a user's c-mode-hook, or a
top-level (setq c-cleanup-list) in .emacs.  Jan complained that he was
left with no way to set c-cleanup-list.  (M-: (setq ....) doesn't count
as "a way" here.)

> Indeed.  I think that needs to be sorted out here is Alan's intuition
> that C style conventions are a matter of personal preference.

Hey, that's not fair!

c-cleanup-list is partly project conventions (in that it can implement
formatting rules), partly personal preference (in that it enables
electric action in a C buffer).  For example, a project may specify the
'brace-else-brace' convention (see page "Clean-ups" in the CC Mode
manual), but a hacker may not want this to be done electrically in his
Emacs.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
>>  > It also seems downright bizarre to tell people not to set
>>  > c-file-style in .dir-settings.el -- my sense is that most developers
>>  > would agree that if a project has C style conventions, they should
>>  > override the user's personal preferences...
>
> They should act as a project wide default, which a user can
> occasionally vary as he sees fit.  The problem is not that
> .dir-locals.el exists, but that it takes precedence over a user's
> c-mode-hook, or a top-level (setq c-cleanup-list) in .emacs.  Jan
> complained that he was left with no way to set c-cleanup-list.  (M-:
> (setq ....) doesn't count as "a way" here.)

Certainly if users were very careful about writing their hooks, and knew
about the situation, they could write code in their hooks like
"(when (no-project-setting 'c-file-style) ...do-my-generic-settings...)".
_If_ they did that, then your suggestion of always giving hooks
precedence could work.  But of course, they _don't_, and even if they
could, they almost certainly wouldn't (because people are generally a
bit lazy and do the simplest thing that seems to work at first).

For those settings for which there's general agreement that project
settings should override personal general preferences (indentation
style, tabs-or-none, etc), then, the current arrangement does the right
thing in most cases.

Of course it would be nice to have _some_ way a user could force the
issue, some hook run after dir-settings are process, should he feel
extremely strongly about some issue.  Hmm, could one not use
`hack-local-variables-hook' to do this?

-Miles

-- 
Bore, n. A person who talks when you wish him to listen.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> Of course it would be nice to have _some_ way a user could force the
> issue,

(setq enable-local-variables nil)

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
>> Of course it would be nice to have _some_ way a user could force the
>> issue,
>
> (setq enable-local-variables nil)

Well, I meant with a bit more finesse... :)

[But wouldn't appropriate use of `hack-local-variables-hook' work?
E.g., in your normal c-mode-hook, add a local hack-local-variables-hook
entry that sets the offending option.]

-Miles

-- 
Youth, n. The Period of Possibility, when Archimedes finds a fulcrum,
Cassandra has a following and seven cities compete for the honor of endowing a
living Homer.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Ken Raeburn]

On Jul 13, 2009, at 04:19, Alan Mackenzie wrote:
> No.  They should act as a project wide default, which a user can
> occasionally vary as he sees fit.  The problem is not that .dir- 
> locals.el
> exists, but that it takes precedence over a user's c-mode-hook, or a
> top-level (setq c-cleanup-list) in .emacs.  Jan complained that he was
> left with no way to set c-cleanup-list.  (M-: (setq ....) doesn't  
> count
> as "a way" here.)

Isn't it just as much a problem if c-cleanup-list is set in file local  
variables?

> c-cleanup-list is partly project conventions (in that it can implement
> formatting rules), partly personal preference (in that it enables
> electric action in a C buffer).  For example, a project may specify  
> the
> 'brace-else-brace' convention (see page "Clean-ups" in the CC Mode
> manual), but a hacker may not want this to be done electrically in his
> Emacs.

Maybe the formatting rules and electric actions need to be better  
separated, so a project can control formatting and let the user  
dictate electric action (or, which actions should be done  
electrically, when they're enabled at all).  Maybe c-cleanup-list  
should never be set in either .dir-locals.el or in file local  
variables in a shared and published project.

On the other hand, the first message in this thread was more about c- 
file-style, which seems to me to be entirely appropriate for  
either .dir-locals.el or file local variables, in shared code where  
different people may have different personal styles that should not be  
imposed on the project.  It can't force them to obey the project style  
guidelines, but it can make it more easy and natural to do so.

I haven't experimented much with .dir-locals.el, but browsing the  
documentation and code suggests that the application and "safeness"  
tests apply to the combination of file local variables and .dir- 
locals.el settings, so I don't see much difference conceptually as to  
whether certain variables should or should not be set in one but not  
the other.

Ken

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Jason Rumney]

Ken Raeburn wrote:

> Maybe the formatting rules and electric actions need to be better 
> separated

Maybe that would help avoid the problem for this case. I'm not sure it 
gets to the bottom of the problem though, which seems to be the timing 
of when hooks and .dir-locals.el (and maybe file local variables) are 
applied, and when the checking of the value of c-cleanup-list against 
set-from-style is done.

> Maybe c-cleanup-list should never be set in either .dir-locals.el or 
> in file local variables in a shared and published project.

The problem seems to be setting c-file-style from those places and 
c-cleanup-list from a hook.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > sjt wrote:

 > > The issue Alan is raising is precisely that *somebody else* is
 > > overriding the user's settings.
 > 
 > Thank you!  That is EXACTLY what I'm raising.  What's more, the
 > overriding is surreptitious - it took Jan some time to find out what was
 > going wrong.  How do you turn off this .dir-locals.el thingy?

I thought .dir-locals.el was an abbreviated way of setting the same
file-locals in every file, and turned off the same way, with
`enable-local-variables'.

But really, you don't want to turn that off.  You want to fix the
.dir-locals.el file.

 > > I agree with Miles:
 > 
 > >  > It also seems downright bizarre to tell people not to set
 > >  > c-file-style in .dir-settings.el -- my sense is that most developers
 > >  > would agree that if a project has C style conventions, they should
 > >  > override the user's personal preferences...
 > 
 > No.  They should act as a project wide default, which a user can
 > occasionally vary as he sees fit.  The problem is not that .dir-locals.el
 > exists, but that it takes precedence over a user's c-mode-hook, or a
 > top-level (setq c-cleanup-list) in .emacs.

That's no bug, that's a feature.  I'm sorry, Alan, but it's totally
unrealistic to hope that average users will take special care to write
hook functions or customizations that worry about projects (that "they
don't even know what they is", to borrow an old Bill Cosby line) that
have special needs.  Most users don't bother to read style guides, and
even fewer would be willing to write conditionals in their hooks.
There needs to be a way to override user globals, per-project, or
per-file.

Now, if `enable-local-variables' doesn't control .dir-locals.el, for
those cases where the user really wants to re-override, that's a bug
IMHO.  If there's no way to control it, then both the author and
committer involved should be sentenced to use Emacs with their keymaps
rot13'd until they get used to it, then rot13'd back. :-)

 > Jan complained that he was left with no way to set c-cleanup-list.
 > (M-: (setq ....) doesn't count as "a way" here.)

Of course it does.  If something that users would often reasonably
want to change, then projects have no business setting it.  The bug is
in the usage by whoever put a setting for c-cleanup-list in a file
local context, not in the precedence.

Ie, the problem is that `c-cleanup-list' controls a bunch of electric
behaviors, and those should never be enabled or disabled in a file
local variable (including dir-locals).  `c-cleanup-list' should be
strictly for the user.

Of course it should be possible for a project to specify a preferred
style to "clean up to", and to enable a "write-region-pre-hook" which
style-checks the buffer, and if it fails, does a "your buffer's style
stinks!  Save anyway? [yes/no] " prompt.  But the project must not try
to enforce a particular way to achieve that style.

 > > Indeed.  I think that needs to be sorted out here is Alan's intuition
 > > that C style conventions are a matter of personal preference.
 > 
 > Hey, that's not fair!

:-)  Did I get your attention?

 > c-cleanup-list is partly project conventions (in that it can implement
 > formatting rules), partly personal preference (in that it enables
 > electric action in a C buffer).

It certainly is fair.  If you confound project conventions with
personal preferences, either conceptually or in the design of your
software, that's not just your problem, it becomes the users' and
projects' problem.  Project conventions must be separated from
personal preferences or you end up with the kind of precedence
deadlock, user vs. project, that we see here.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Mon, Jul 13, 2009 at 1:42 PM, Stephen J. Turnbull<stephen@xemacs.org> wrote:
>
> Now, if `enable-local-variables' doesn't control .dir-locals.el, for
> those cases where the user really wants to re-override, that's a bug
> IMHO.

A small note: The doc string for enable-local-variables does not
define "remembered" in "when you say yes to certain values, they are
remembered as safe".

Does "remember" mean for current Emacs session or something else? I
think that should be clarified.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Morning, Miles!

On Mon, Jul 13, 2009 at 01:37:31PM +0900, Miles Bader wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
> >> ! These settings can override those made by a user in his .emacs so
> >> ! you should be careful not to set variables which are a matter of
> >> ! personal choice.  You should probably not set @code{c-file-syle}
> >> ! and @code{c-file-offsets} here (@pxref{File Styles,,,ccmode}).

> > But I think we have a basic disagreement here.  A user should feel
> > free to set directory local variables that override his or her .emacs
> > settings---exactly like he or she should feel free to write file-local
> > variables.  The manual has no purpose telling people what to do with
> > their own files.

> It also seems downright bizarre to tell people not to set c-file-style
> in .dir-settings.el

c-file-style is documented as being for use only in file local variables.

> -- my sense is that most developers would agree that if a project has C
> style conventions, they should override the user's personal
> preferences...

Hmmm.  I think most hackers would agree they should be able to override
project defaults in their Emacs sessions.  How do you override a setting
which is in dir-locals.el?

> [and painful memories of source code where basic things like indentation
> levels varied line-to-line within functions makes me grateful for any
> method that helps automate project conventions!]

Straw man!

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
>> [and painful memories of source code where basic things like indentation
>> levels varied line-to-line within functions makes me grateful for any
>> method that helps automate project conventions!]
>
> Straw man!

How is that a straw man?  Granted, .dir-locals.el wouldn't do the whole
job (it's only supported in recent emacs, and many people don't use
Emacs), but every little bit helps...

-Miles

-- 
Idiot, n. A member of a large and powerful tribe whose influence in human
affairs has always been dominant and controlling.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Chad Brown]

I apologize for asking when I could check/suggest code, but would it  
help Alan's situation if there were an indication that a .dir- 
locals.el was being used?  Perhaps in the mode line, or another  
section in describe-mode?

*Chad

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Juri Linkov]

> I apologize for asking when I could check/suggest code,
> but would it help Alan's situation if there were an indication
> that a .dir-locals.el was being used?  Perhaps in the mode line,
> or another section in describe-mode?

`C-h v' prints "Local in buffer", but maybe it should also add a source
of its value, e.g. "a file-local variable" or "a directory-local variable
from the file .../.dir-locals.el"?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Mon, Jul 13, 2009 at 10:03 PM, Juri Linkov<juri@jurta.org> wrote:
>> I apologize for asking when I could check/suggest code,
>> but would it help Alan's situation if there were an indication
>> that a .dir-locals.el was being used?  Perhaps in the mode line,
>> or another section in describe-mode?
>
> `C-h v' prints "Local in buffer", but maybe it should also add a source
> of its value, e.g. "a file-local variable" or "a directory-local variable
> from the file .../.dir-locals.el"?

Yes, displaying such information makes it much easier to understand
what is happening.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stefan Monnier]

> `C-h v' prints "Local in buffer", but maybe it should also add a source
> of its value, e.g. "a file-local variable" or "a directory-local variable
> from the file .../.dir-locals.el"?

Patch welcome,


        Stefan

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Juri Linkov]

>> `C-h v' prints "Local in buffer", but maybe it should also add a source
>> of its value, e.g. "a file-local variable" or "a directory-local variable
>> from the file .../.dir-locals.el"?
>
> Patch welcome,

The patch below adds this information to the output of `C-h v'.
It distinguishes file-local variables from dir-local variables
by subtracting `file-local-variables-alist' from `dir-local-variables-alist',
i.e. a file-local variable with its value is a member of only
`file-local-variables-alist', but a dir-local variable with its value
is a member of both.

`dir-local-variables-alist' is a new function refactored from
`hack-dir-local-variables'.  It seems it should not be a variable
since it is required now only for documentation purposes.

Removed (declare-function c-postprocess-file-styles "cc-mode" ())
that are remains of the old code.

Index: lisp/help-fns.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/help-fns.el,v
retrieving revision 1.133
diff -c -r1.133 help-fns.el
*** lisp/help-fns.el	28 Jun 2009 05:06:59 -0000	1.133
--- lisp/help-fns.el	16 Jul 2009 00:27:09 -0000
***************
*** 685,690 ****
--- 685,691 ----
                              (error variable)))
                     (obsolete (get variable 'byte-obsolete-variable))
  		   (use (car obsolete))
+ 		   (file-local (member (cons variable val) file-local-variables-alist))
  		   (safe-var (get variable 'safe-local-variable))
                     (doc (or (documentation-property variable 'variable-documentation)
                              (documentation-property alias 'variable-documentation)))
***************
*** 710,715 ****
--- 711,728 ----
  			     (use (format ";\n  use `%s' instead." (car obsolete)))
  			     (t ".")))
                  (terpri))
+ 
+ 	      (when file-local
+ 		(setq extra-line t)
+ 		(let* ((elt (car (dir-local-variables-alist)))
+ 		       (dir-name (car elt))
+ 		       (variables (cdr elt)))
+ 		  (if (member (cons variable val) variables)
+ 		      (princ (concat
+ 			      "  This variable is a directory-local variable\n"
+ 			      "  from the file \"" dir-name dir-locals-file "\".\n"))
+ 		    (princ "  This variable is a file-local variable.\n"))))
+ 
  	      (when safe-var
                  (setq extra-line t)
  		(princ "  This variable is safe as a file local variable ")

Index: lisp/files.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/files.el,v
retrieving revision 1.1055
diff -c -r1.1055 files.el
*** lisp/files.el	5 Jul 2009 22:15:37 -0000	1.1055
--- lisp/files.el	16 Jul 2009 00:27:28 -0000
***************
*** 3362,3368 ****
  				      (nth 5 (file-attributes file)))
        class-name)))
  
! (declare-function c-postprocess-file-styles "cc-mode" ())
  
  (defun hack-dir-local-variables ()
    "Read per-directory local variables for the current buffer.
--- 3372,3399 ----
  				      (nth 5 (file-attributes file)))
        class-name)))
  
! (defun dir-local-variables-alist ()
!   "Return an alist of directory-local variable settings in the current buffer.
! Each element in this list has the form (DIR-NAME . VARIABLES),
! where DIR-NAME is a directory name and VARIABLES is an alist of
! directory-local variable settings from this directory with the same
! format as in the variable `file-local-variables-alist'."
!   ;; Find the variables file.
!   (let ((variables-file (dir-locals-find-file (buffer-file-name)))
! 	(class nil)
! 	(dir-name nil))
!     (cond
!      ((stringp variables-file)
!       (setq dir-name (file-name-directory (buffer-file-name)))
!       (setq class (dir-locals-read-from-file variables-file)))
!      ((consp variables-file)
!       (setq dir-name (nth 0 variables-file))
!       (setq class (nth 1 variables-file))))
!     (when class
!       (list
!        (cons dir-name
! 	     (dir-locals-collect-variables
! 	      (dir-locals-get-class-variables class) dir-name nil))))))
  
  (defun hack-dir-local-variables ()
    "Read per-directory local variables for the current buffer.
***************
*** 3371,3393 ****
    (when (and enable-local-variables
  	     (buffer-file-name)
  	     (not (file-remote-p (buffer-file-name))))
!     ;; Find the variables file.
!     (let ((variables-file (dir-locals-find-file (buffer-file-name)))
! 	  (class nil)
! 	  (dir-name nil))
!       (cond
!        ((stringp variables-file)
! 	(setq dir-name (file-name-directory (buffer-file-name)))
! 	(setq class (dir-locals-read-from-file variables-file)))
!        ((consp variables-file)
! 	(setq dir-name (nth 0 variables-file))
! 	(setq class (nth 1 variables-file))))
!       (when class
! 	(let ((variables
! 	       (dir-locals-collect-variables
! 		(dir-locals-get-class-variables class) dir-name nil)))
! 	  (when variables
! 	    (hack-local-variables-filter variables dir-name)))))))
  
  \f
  (defcustom change-major-mode-with-file-name t
--- 3402,3412 ----
    (when (and enable-local-variables
  	     (buffer-file-name)
  	     (not (file-remote-p (buffer-file-name))))
!     (let* ((elt (car (dir-local-variables-alist)))
! 	   (dir-name (car elt))
! 	   (variables (cdr elt)))
!       (when variables
! 	(hack-local-variables-filter variables dir-name)))))
  
  \f
  (defcustom change-major-mode-with-file-name t

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stefan Monnier]

> The patch below adds this information to the output of `C-h v'.
> It distinguishes file-local variables from dir-local variables
> by subtracting `file-local-variables-alist' from `dir-local-variables-alist',
> i.e. a file-local variable with its value is a member of only
> `file-local-variables-alist', but a dir-local variable with its value
> is a member of both.

If the variable is set in both, we should be careful to say it's
"file-local" and not "dir-local".

> `dir-local-variables-alist' is a new function refactored from
> `hack-dir-local-variables'.  It seems it should not be a variable
> since it is required now only for documentation purposes.

The problem with that is that if the dir-local.el file changes between
the time you open the file and the C-h v, you'll get incorrect results.


        Stefan

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Juri Linkov]

>> The patch below adds this information to the output of `C-h v'.
>> It distinguishes file-local variables from dir-local variables
>> by subtracting `file-local-variables-alist' from `dir-local-variables-alist',
>> i.e. a file-local variable with its value is a member of only
>> `file-local-variables-alist', but a dir-local variable with its value
>> is a member of both.
>
> If the variable is set in both, we should be careful to say it's
> "file-local" and not "dir-local".

Sorry, I don't understand.  If the variable is set in both
`file-local-variables-alist' and `(dir-local-variables-alist)',
then it's "dir-local" and not "file-local".

For a file-local variable, C-h v will say:

  This variable is a file-local variable.

For a directory-local variable, C-h v will say:

  This variable is a directory-local variable
  from the file ".../.dir-locals.el".

>> `dir-local-variables-alist' is a new function refactored from
>> `hack-dir-local-variables'.  It seems it should not be a variable
>> since it is required now only for documentation purposes.
>
> The problem with that is that if the dir-local.el file changes between
> the time you open the file and the C-h v, you'll get incorrect results.

The main purpose of adding an information about .dir-locals.el in C-h v
is to warn the user about a new dir-local mechanism that s?he might
not be aware of.  This warning is less useful when the user already
has dealt with dir-local.el files.

Or do you think a new variable `dir-local-variables-alist'
would be better?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Thu, Jul 16, 2009 at 10:48 PM, Juri Linkov<juri@jurta.org> wrote:
>> The problem with that is that if the dir-local.el file changes between
>> the time you open the file and the C-h v, you'll get incorrect results.
>
> The main purpose of adding an information about .dir-locals.el in C-h v
> is to warn the user about a new dir-local mechanism that s?he might
> not be aware of.  This warning is less useful when the user already
> has dealt with dir-local.el files.

Why not simply tell in C-h v if you find a dir/file local variable
what it means? Mayby a link to relavant info/help?

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stefan Monnier]

>> If the variable is set in both, we should be careful to say it's
>> "file-local" and not "dir-local".

> Sorry, I don't understand.  If the variable is set in both
> `file-local-variables-alist' and `(dir-local-variables-alist)',
> then it's "dir-local" and not "file-local".

No, if it's set both in dir-locals.el and in file-local, then it's
file-local.

>> The problem with that is that if the dir-local.el file changes between
>> the time you open the file and the C-h v, you'll get incorrect results.

> The main purpose of adding an information about .dir-locals.el in C-h v
> is to warn the user about a new dir-local mechanism that s?he might
> not be aware of.  This warning is less useful when the user already
> has dealt with dir-local.el files.

I know, but if you use a function like you have, you're reporting the
dir-locals that would be aplied if the file was re-opened at that point,
rather than the dir-locals that was in effect when the file was opened.

> Or do you think a new variable `dir-local-variables-alist'
> would be better?

Yes, we need to remember the dir-locals that were found when the file
was opened since they may disappear afterwards,


        Stefan

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Juri Linkov]

>>> If the variable is set in both, we should be careful to say it's
>>> "file-local" and not "dir-local".
>
>> Sorry, I don't understand.  If the variable is set in both
>> `file-local-variables-alist' and `(dir-local-variables-alist)',
>> then it's "dir-local" and not "file-local".
>
> No, if it's set both in dir-locals.el and in file-local, then it's
> file-local.

IIUC, there are three possible cases:

1. if it's set in file-local but not in dir-locals.el
   then (variable . value) is stored in `file-local-variables-alist'
   but not in `dir-local-variables-alist'

2. if it's set in dir-locals.el but not in file-local
   then (variable . value) is stored both in `file-local-variables-alist'
   and in `dir-local-variables-alist'

3. if it's set both in file-local and in dir-locals.el
   then (variable . value) is stored both in `file-local-variables-alist'
   and in `dir-local-variables-alist'

The problem is that the 3rd case doesn't seem correct.  I think we should
fix `hack-local-variables-filter' to remove (variable . value) from
`dir-local-variables-alist' when it comes from file-locals and thus
overrides dir-locals.

So the 3rd case will be:

3. if it's set both in file-local and in dir-locals.el
   then (variable . value) is stored in `file-local-variables-alist'
   but not in `dir-local-variables-alist'

I could implement this with adding a new variable `dir-local-variables-alist'
after Yidong installs his patch in the same part of code that removes
duplicates from `file-local-variables-alist'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Juri Linkov]

> The problem is that the 3rd case doesn't seem correct.  I think we should
> fix `hack-local-variables-filter' to remove (variable . value) from
> `dir-local-variables-alist' when it comes from file-locals and thus
> overrides dir-locals.
>
> So the 3rd case will be:
>
> 3. if it's set both in file-local and in dir-locals.el
>    then (variable . value) is stored in `file-local-variables-alist'
>    but not in `dir-local-variables-alist'
>
> I could implement this with adding a new variable `dir-local-variables-alist'
> after Yidong installs his patch in the same part of code that removes
> duplicates from `file-local-variables-alist'.

This is implemented in the following patch:

Index: lisp/files.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/files.el,v
retrieving revision 1.1057
diff -c -r1.1057 files.el
*** lisp/files.el	18 Jul 2009 20:41:32 -0000	1.1057
--- lisp/files.el	18 Jul 2009 21:48:54 -0000
***************
*** 2637,2643 ****
  
  (defvar ignored-local-variables
    '(ignored-local-variables safe-local-variable-values
!     file-local-variables-alist)
    "Variables to be ignored in a file's local variable spec.")
  
  (defvar hack-local-variables-hook nil
--- 2637,2643 ----
  
  (defvar ignored-local-variables
    '(ignored-local-variables safe-local-variable-values
!     file-local-variables-alist dir-local-variables-alist)
    "Variables to be ignored in a file's local variable spec.")
  
  (defvar hack-local-variables-hook nil
***************
*** 2760,2765 ****
--- 2760,2774 ----
  if it is changed by the major or minor modes, or by the user.")
  (make-variable-buffer-local 'file-local-variables-alist)
  
+ (defvar dir-local-variables-alist nil
+   "Alist of directory-local variable settings in the current buffer.
+ Each element in this list has the form (VAR . VALUE), where VAR
+ is a directory-local variable (a symbol) found in .dir-locals.el
+ and VALUE is the value specified.  The actual value in the buffer
+ may differ from VALUE, if it is changed by the major or minor modes,
+ or by the user.")
+ (make-variable-buffer-local 'dir-local-variables-alist)
+ 
  (defvar before-hack-local-variables-hook nil
    "Normal hook run before setting file-local variables.
  It is called after checking for unsafe/risky variables and
***************
*** 2963,2969 ****
  	      (let ((var (car elt)))
  		(unless (eq var 'eval)
  		  (setq file-local-variables-alist
! 			(assq-delete-all var file-local-variables-alist)))
  		(push elt file-local-variables-alist))))
  	;; Query, unless all are known safe or the user wants no
  	;; querying.
--- 2972,2981 ----
  	      (let ((var (car elt)))
  		(unless (eq var 'eval)
  		  (setq file-local-variables-alist
! 			(assq-delete-all var file-local-variables-alist))
! 		  (unless dir-name
! 		    (setq dir-local-variables-alist
! 			  (assq-delete-all var dir-local-variables-alist))))
  		(push elt file-local-variables-alist))))
  	;; Query, unless all are known safe or the user wants no
  	;; querying.
***************
*** 2977,2983 ****
  	      (let ((var (car elt)))
  		(unless (eq var 'eval)
  		  (setq file-local-variables-alist
! 			(assq-delete-all var file-local-variables-alist)))
  		(push elt file-local-variables-alist))))))))
  
  
--- 2989,2998 ----
  	      (let ((var (car elt)))
  		(unless (eq var 'eval)
  		  (setq file-local-variables-alist
! 			(assq-delete-all var file-local-variables-alist))
! 		  (unless dir-name
! 		    (setq dir-local-variables-alist
! 			  (assq-delete-all var dir-local-variables-alist))))
  		(push elt file-local-variables-alist))))))))
  
  
***************
*** 3372,3383 ****
  				      (nth 5 (file-attributes file)))
        class-name)))
  
- (declare-function c-postprocess-file-styles "cc-mode" ())
- 
  (defun hack-dir-local-variables ()
    "Read per-directory local variables for the current buffer.
! Store the directory-local variables in `file-local-variables-alist',
! without applying them."
    (when (and enable-local-variables
  	     (buffer-file-name)
  	     (not (file-remote-p (buffer-file-name))))
--- 3387,3396 ----
  				      (nth 5 (file-attributes file)))
        class-name)))
  
  (defun hack-dir-local-variables ()
    "Read per-directory local variables for the current buffer.
! Store the directory-local variables in `dir-local-variables-alist'
! and `file-local-variables-alist', without applying them."
    (when (and enable-local-variables
  	     (buffer-file-name)
  	     (not (file-remote-p (buffer-file-name))))
***************
*** 3397,3402 ****
--- 3410,3421 ----
  	       (dir-locals-collect-variables
  		(dir-locals-get-class-variables class) dir-name nil)))
  	  (when variables
+ 	    (dolist (elt variables)
+ 	      (let ((var (car elt)))
+ 		(unless (eq var 'eval)
+ 		  (setq dir-local-variables-alist
+ 			(assq-delete-all var dir-local-variables-alist)))
+ 		(push elt dir-local-variables-alist)))
  	    (hack-local-variables-filter variables dir-name)))))))
  
  \f

Index: lisp/help-fns.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/help-fns.el,v
retrieving revision 1.133
diff -c -r1.133 help-fns.el
*** lisp/help-fns.el	28 Jun 2009 05:06:59 -0000	1.133
--- lisp/help-fns.el	18 Jul 2009 21:49:33 -0000
***************
*** 710,715 ****
--- 710,727 ----
  			     (use (format ";\n  use `%s' instead." (car obsolete)))
  			     (t ".")))
                  (terpri))
+ 
+ 	      (when (member (cons variable val) file-local-variables-alist)
+ 		(setq extra-line t)
+ 		(if (member (cons variable val) dir-local-variables-alist)
+ 		    (let ((file (and (buffer-file-name)
+ 				     (not (file-remote-p (buffer-file-name)))
+ 				     (dir-locals-find-file (buffer-file-name)))))
+ 		      (princ "  This variable is a directory local variable")
+ 		      (if file (princ (concat "\n  from the file \"" file "\"")))
+ 		      (princ ".\n"))
+ 		  (princ "  This variable is a file local variable.\n")))
+ 
  	      (when safe-var
                  (setq extra-line t)
  		(princ "  This variable is safe as a file local variable ")

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Ken Raeburn]

On Jul 13, 2009, at 04:25, Alan Mackenzie wrote:
>> It also seems downright bizarre to tell people not to set c-file- 
>> style
>> in .dir-settings.el
>
> c-file-style is documented as being for use only in file local  
> variables.

Was that documentation written before or after the introduction of per- 
directory local variables?  My guess is before, and it should be  
updated to make this permissible as well.

>> -- my sense is that most developers would agree that if a project  
>> has C
>> style conventions, they should override the user's personal
>> preferences...
>
> Hmmm.  I think most hackers would agree they should be able to  
> override
> project defaults in their Emacs sessions.

Sure, and file defaults too.

>  How do you override a setting
> which is in dir-locals.el?

(setq enable-local-variables nil)

Now, if you want to override dir-locals.el but *not* override file  
local variables, that looks a bit trickier.  But if you look at the  
former as just a project-wide version of the latter, I don't see the  
need.

Ken

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Alan Mackenzie <acm@muc.de> writes:
  > 
  > >> I'm not sure I understand.  Directory-local variables are processed
  > >> right before file-local variables, and can be overridden by them.
  > >
  > > Sorry, yes.  But that's the only thing they can be overridden by.  That
  > > is surely not the right thing.
  > >
  > > Why on earth does .dir-locals.el take precedence over values set in a
  > > top-level `setq' or `c-mode-hook'?  This is surely the Wrong Thing to
  > > do.
  > 
  > Because setting a directory-local variable is supposed to have the same
  > effect as setting a file-local variable inside every file in that
  > directory.  Thus, instead of putting c-fill-style inside every .c file
  > in the Emacs source tree, you can simply write a .dir-locals.el file.
  > 
  > > In particular, the File Style and local variables settings are rarely
  > > used precision instruments, for configuring unusual files unusually.
  > 
  > This indicates that we should not set c-file-style in the .dir-locals.el
  > file of the Emacs source tree.


The problem that c-file-style in .dir-locals.el tries to solve is to
make sure that anyone that edits files in emacs will use the GNU style
regardless of what the user sets in his .emacs.

Say one works on projects that have very strong code style requirements,
and the styles are different for different projects, say for example the
GNU toolchain and Linux.   

If all these projects set the correct style in their .dir-locals.el file
then the user does not have to do anything in order to always use the
correct style.

The above is an example of a concrete problem solved by .dir-locals.el. 
What is the problem in bug#3808 ?  Is it a real problem, or it's just
.dir-locals.el working exactly as expected.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Jason Rumney]

Chong Yidong wrote:
> This indicates that we should not set c-file-style in the .dir-locals.el
> file of the Emacs source tree.
>   

I think it points to a bug in the handling of c-file-style.  The 
documentation of c-cleanup-list (which is the variable that Jan was 
surprised about) says that it should only be affected by the style when 
it is set to set-from-style.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

On Mon, Jul 13, 2009 at 01:09:24PM +0800, Jason Rumney wrote:
> Chong Yidong wrote:
> >This indicates that we should not set c-file-style in the
> >.dir-locals.el file of the Emacs source tree.


> I think it points to a bug in the handling of c-file-style.  The
> documentation of c-cleanup-list (which is the variable that Jan was
> surprised about) says that it should only be affected by the style when
> it is set to set-from-style.

Very good point!  I'll have a look at this.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Jason, Jan, Stefan!

On Mon, Jul 13, 2009 at 01:09:24PM +0800, Jason Rumney wrote:
> Chong Yidong wrote:
> >This indicates that we should not set c-file-style in the .dir-locals.el
> >file of the Emacs source tree.

> I think it points to a bug in the handling of c-file-style.  The 
> documentation of c-cleanup-list (which is the variable that Jan was 
> surprised about) says that it should only be affected by the style when 
> it is set to set-from-style.

I think you're right here, and that the bug is that the function handling
c-file-style forgets to check that its value is 'set-from-style.  The
complexity of all the interacting features is far too high IMAO, and my
brain is right at the limits of what it can grasp; even though I'm
currently the custodian for a great deal of this complexity.

I've thought a lot about this, and think I now understand the problem.
The CC Mode manual (on page "Config Basics") lists the various ways of
setting a style variable in order of precedence, like this:

      If you make conflicting settings in several of these ways, the way
    that takes precedence is the one that appears latest in this list:

        Style
        Top-level command or "customization interface"
        Hook
        File Style

I confused myself by pompous language.  If instead of "If you make
conflicting settings ..." I had written "If you set a style variable in
several of these ways ...", I don't think I would have got this feature
wrong.

However, this fails to mention directly setting a style variable in the
Local Variables section, or to distinguish that from a File Style.  The
list, perhaps, should look like this, with the code being change
accordingly:

	Style
	File Style                  <-------------
	Top-level command or "customization interface"
	Hook
	File local variable setting <-------------

As I say, I'm not totally unconfused about all this at the moment, but
I'm confident that you (Jason) have identified the problem.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stefan Monnier]

> The complexity of all the interacting features is far too high IMAO,
> and my brain is right at the limits of what it can grasp;

I'm glad to hear you say that.


        Stefan

Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Jan, Jason, Stefan!

On Tue, Jul 14, 2009 at 04:22:06PM +0000, Alan Mackenzie wrote:
> Hi, Jason, Jan, Stefan!

> On Mon, Jul 13, 2009 at 01:09:24PM +0800, Jason Rumney wrote:

> > I think it points to a bug in the handling of c-file-style.  The
> > documentation of c-cleanup-list (which is the variable that Jan was
> > surprised about) says that it should only be affected by the style
> > when it is set to set-from-style.

> I think you're right here, and that the bug is that the function
> handling c-file-style forgets to check that its value is
> 'set-from-style.

Here's a preliminary patch which I think fixes the code, though I've only
tested it briefly.  It seems to work for the case you (Jan) were hit by.

Now, any CC Mode style set by `c-file-style' will leave unchanged those
style variables (e.g. `c-cleanup-list') which have already been given
real values.

I expect and intend that if the `c-file-style' mechanism is used twice,
the second one (in the file's Local Variable section) will prevail over
the first one (in some .dir-locals.el), whilst respecting the non-default
value of `c-cleanup-list'.

Jan, please try it out!

Thanks!


Index: cc-mode.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/cc-mode.el,v
retrieving revision 1.84
diff -c -r1.84 cc-mode.el
*** cc-mode.el	19 May 2009 22:35:07 -0000	1.84
--- cc-mode.el	14 Jul 2009 19:53:20 -0000
***************
*** 670,676 ****
  	  (offsets (cdr (assq 'c-file-offsets file-local-variables-alist))))
        (when stile
  	(or (stringp stile) (error "c-file-style is not a string"))
! 	(c-set-style stile))
        (when offsets
  	(mapc
  	 (lambda (langentry)
--- 670,676 ----
  	  (offsets (cdr (assq 'c-file-offsets file-local-variables-alist))))
        (when stile
  	(or (stringp stile) (error "c-file-style is not a string"))
! 	(c-set-style stile 'respect-defaults))
        (when offsets
  	(mapc
  	 (lambda (langentry)
***************
*** 741,747 ****
      (when c-file-style
        (or (stringp c-file-style)
  	  (error "c-file-style is not a string"))
!       (c-set-style c-file-style))
  
      (and c-file-offsets
  	 (mapc
--- 741,747 ----
      (when c-file-style
        (or (stringp c-file-style)
  	  (error "c-file-style is not a string"))
!       (c-set-style c-file-style 'respect-defaults))
  
      (and c-file-offsets
  	 (mapc

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Jan Djärv]

Alan Mackenzie skrev:
> Hi, Jan, Jason, Stefan!
> 
> 
> Here's a preliminary patch which I think fixes the code, though I've only
> tested it briefly.  It seems to work for the case you (Jan) were hit by.
> 
> Now, any CC Mode style set by `c-file-style' will leave unchanged those
> style variables (e.g. `c-cleanup-list') which have already been given
> real values.
> 
> I expect and intend that if the `c-file-style' mechanism is used twice,
> the second one (in the file's Local Variable section) will prevail over
> the first one (in some .dir-locals.el), whilst respecting the non-default
> value of `c-cleanup-list'.
> 
> Jan, please try it out!
> 

It works if I set c-cleanup-list with customize, but not if it is set in the 
c-common-mode-hook (using add-to-list).

	Jan D.

Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Jan, Yidong,

On Wed, Jul 15, 2009 at 09:55:43AM +0200, Jan Djärv wrote:

> Alan Mackenzie skrev:

> >Here's a preliminary patch which I think fixes the code, though I've
> >only tested it briefly.  It seems to work for the case you (Jan) were
> >hit by.

> >Now, any CC Mode style set by `c-file-style' will leave unchanged
> >those style variables (e.g. `c-cleanup-list') which have already been
> >given real values.

> >I expect and intend that if the `c-file-style' mechanism is used
> >twice, the second one (in the file's Local Variable section) will
> >prevail over the first one (in some .dir-locals.el), whilst
> >respecting the non-default value of `c-cleanup-list'.

> >Jan, please try it out!

> It works if I set c-cleanup-list with customize, but not if it is set in 
> the c-common-mode-hook (using add-to-list).

Yes.  Sorry.  I think we agree that a setting for c-cleanup-list made in
a hook function should take priority over any (semi-implicitly) requested
by c-file-style.  I think I can see how to do this, now.

I tried the following settings, at the same time:

(i) In .dir-locals.el:
     (c-mode . ((c-file-style . "Linux")
                (c-basic-offset . 7)))

(ii) In .../src/xftfont.c:
    /*
     * Local Variables:
     * c-file-style: "BSD"
     * c-basic-offset: 10
     * End:
     */

In xftfont.c, I got the style as "Linux" and c-basic-offset as 10, i.e.
a mixture of these two.  This happens because the CC Mode routine does 

    (assq 'c-file-style file-local-variables-alist)

, hence finding the earliest entry for c-file-style, whilst the other
variables are just bashed through, causing the latest entry to prevail
over earlier ones.

Yidong, hack-local-variables desperately needs refactoring.  It was sort
of tolerable when only file local variables were involved, but now it's
all but unreadable and ununderstandable (should this just be
derstandable?)

In particular, there's no great care taken about how the local variable
settings from the two sources get combined.  How about the following
idea: when a setting from the Local Variables: section is to be pushed
onto file-local-variables-alist, any exisiting element for the same
variable is first removed?

This way, a file's Local Variables section will prevail over
.dir-locals.el.

> 	Jan D.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stefan Monnier]

> Yidong, hack-local-variables desperately needs refactoring.

A refactoring would not be unwelcome.

> It was sort of tolerable when only file local variables were involved,
> but now it's all but unreadable and ununderstandable

I'd agree.

> (should this just be derstandable?)

Depends if you're constructivist or classicist.

> In particular, there's no great care taken about how the local variable
> settings from the two sources get combined.  How about the following
> idea: when a setting from the Local Variables: section is to be pushed
> onto file-local-variables-alist, any exisiting element for the same
> variable is first removed?

That would make a lot of sense, since it reflects what happens to the
variable's value in the end.  Also it does correspond to the behavior we
want that file-local should take precedence over dir-local.


        Stefan

Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> In particular, there's no great care taken about how the local variable
> settings from the two sources get combined.

This has little to do with directory-local variables; if you specify a
file-local variable more than once in the file, the same thing occurs.

> How about the following idea: when a setting from the Local Variables:
> section is to be pushed onto file-local-variables-alist, any exisiting
> element for the same variable is first removed?

This sounds reasonable.  Something like this should work:

*** trunk/lisp/files.el.~1.1055.~	2009-07-12 13:32:43.000000000 -0400
--- trunk/lisp/files.el	2009-07-15 16:43:59.000000000 -0400
***************
*** 2960,2966 ****
  	  (dolist (elt variables)
  	    (unless (or (member elt unsafe-vars)
  			(member elt risky-vars))
! 	      (push elt file-local-variables-alist)))
  	;; Query, unless all are known safe or the user wants no
  	;; querying.
  	(if (or (and (eq enable-local-variables t)
--- 2960,2970 ----
  	  (dolist (elt variables)
  	    (unless (or (member elt unsafe-vars)
  			(member elt risky-vars))
! 	      (let ((var (car elt)))
! 		(unless (eq var 'eval)
! 		  (setq file-local-variables-alist
! 			(assq-delete-all var file-local-variables-alist)))
! 		(push elt file-local-variables-alist))))
  	;; Query, unless all are known safe or the user wants no
  	;; querying.
  	(if (or (and (eq enable-local-variables t)
***************
*** 2970,2976 ****
  		(hack-local-variables-confirm
  		 variables unsafe-vars risky-vars dir-name))
  	    (dolist (elt variables)
! 	      (push elt file-local-variables-alist)))))))
  
  (defun hack-local-variables (&optional mode-only)
    "Parse and put into effect this buffer's local variables spec.
--- 2974,2985 ----
  		(hack-local-variables-confirm
  		 variables unsafe-vars risky-vars dir-name))
  	    (dolist (elt variables)
! 	      (let ((var (car elt)))
! 		(unless (eq var 'eval)
! 		  (setq file-local-variables-alist
! 			(assq-delete-all var file-local-variables-alist)))
! 		(push elt file-local-variables-alist))))))))
! 
  
  (defun hack-local-variables (&optional mode-only)
    "Parse and put into effect this buffer's local variables spec.

Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Jan!

On Wed, Jul 15, 2009 at 09:55:43AM +0200, Jan Djärv wrote:

> >Here's a preliminary patch which I think fixes the code, though I've only
> >tested it briefly.  It seems to work for the case you (Jan) were hit by.

> >Now, any CC Mode style set by `c-file-style' will leave unchanged those
> >style variables (e.g. `c-cleanup-list') which have already been given
> >real values.

> >I expect and intend that if the `c-file-style' mechanism is used twice,
> >the second one (in the file's Local Variable section) will prevail over
> >the first one (in some .dir-locals.el), whilst respecting the non-default
> >value of `c-cleanup-list'.

> >Jan, please try it out!


> It works if I set c-cleanup-list with customize, but not if it is set in 
> the c-common-mode-hook (using add-to-list).

Here's a better patch, incorporating Yidong's amendments to the
manipulations of `file-local-variables-alist'.  Please try this out!

> 	Jan D.


Index: files.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/files.el,v
retrieving revision 1.1055
diff -c -r1.1055 files.el
*** files.el	5 Jul 2009 22:15:37 -0000	1.1055
--- files.el	18 Jul 2009 12:43:40 -0000
***************
*** 2960,2966 ****
  	  (dolist (elt variables)
  	    (unless (or (member elt unsafe-vars)
  			(member elt risky-vars))
! 	      (push elt file-local-variables-alist)))
  	;; Query, unless all are known safe or the user wants no
  	;; querying.
  	(if (or (and (eq enable-local-variables t)
--- 2960,2970 ----
  	  (dolist (elt variables)
  	    (unless (or (member elt unsafe-vars)
  			(member elt risky-vars))
! 	      (let ((var (car elt)))
! 		(unless (eq var 'eval)
! 		  (setq file-local-variables-alist
! 			(assq-delete-all var file-local-variables-alist)))
! 		(push elt file-local-variables-alist))))
  	;; Query, unless all are known safe or the user wants no
  	;; querying.
  	(if (or (and (eq enable-local-variables t)
***************
*** 2970,2976 ****
  		(hack-local-variables-confirm
  		 variables unsafe-vars risky-vars dir-name))
  	    (dolist (elt variables)
! 	      (push elt file-local-variables-alist)))))))
  
  (defun hack-local-variables (&optional mode-only)
    "Parse and put into effect this buffer's local variables spec.
--- 2974,2985 ----
  		(hack-local-variables-confirm
  		 variables unsafe-vars risky-vars dir-name))
  	    (dolist (elt variables)
! 	      (let ((var (car elt)))
! 		(unless (eq var 'eval)
! 		  (setq file-local-variables-alist
! 			(assq-delete-all var file-local-variables-alist)))
! 		(push elt file-local-variables-alist))))))))
! 
  
  (defun hack-local-variables (&optional mode-only)
    "Parse and put into effect this buffer's local variables spec.
***************
*** 3073,3078 ****
--- 3082,3088 ----
  	  (enable-local-variables
  	   (hack-local-variables-filter result nil)
  	   (when file-local-variables-alist
+ 	     ;; Any 'evals must run in the Right sequence.
  	     (setq file-local-variables-alist
  		   (nreverse file-local-variables-alist))
  	     (run-hooks 'before-hack-local-variables-hook)
Index: progmodes/cc-mode.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/cc-mode.el,v
retrieving revision 1.84
diff -c -r1.84 cc-mode.el
*** progmodes/cc-mode.el	19 May 2009 22:35:07 -0000	1.84
--- progmodes/cc-mode.el	18 Jul 2009 12:43:41 -0000
***************
*** 670,676 ****
  	  (offsets (cdr (assq 'c-file-offsets file-local-variables-alist))))
        (when stile
  	(or (stringp stile) (error "c-file-style is not a string"))
! 	(c-set-style stile))
        (when offsets
  	(mapc
  	 (lambda (langentry)
--- 670,676 ----
  	  (offsets (cdr (assq 'c-file-offsets file-local-variables-alist))))
        (when stile
  	(or (stringp stile) (error "c-file-style is not a string"))
! 	(c-set-style stile t))
        (when offsets
  	(mapc
  	 (lambda (langentry)
***************
*** 741,747 ****
      (when c-file-style
        (or (stringp c-file-style)
  	  (error "c-file-style is not a string"))
!       (c-set-style c-file-style))
  
      (and c-file-offsets
  	 (mapc
--- 741,747 ----
      (when c-file-style
        (or (stringp c-file-style)
  	  (error "c-file-style is not a string"))
!       (c-set-style c-file-style t))
  
      (and c-file-offsets
  	 (mapc



-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Jan Djärv]

Alan Mackenzie skrev:
> Hi, Jan!
> 
> On Wed, Jul 15, 2009 at 09:55:43AM +0200, Jan Djärv wrote:
> 
>>> Here's a preliminary patch which I think fixes the code, though I've only
>>> tested it briefly.  It seems to work for the case you (Jan) were hit by.
> 
>>> Now, any CC Mode style set by `c-file-style' will leave unchanged those
>>> style variables (e.g. `c-cleanup-list') which have already been given
>>> real values.
> 
>>> I expect and intend that if the `c-file-style' mechanism is used twice,
>>> the second one (in the file's Local Variable section) will prevail over
>>> the first one (in some .dir-locals.el), whilst respecting the non-default
>>> value of `c-cleanup-list'.
> 
>>> Jan, please try it out!
> 
> 
>> It works if I set c-cleanup-list with customize, but not if it is set in 
>> the c-common-mode-hook (using add-to-list).
> 
> Here's a better patch, incorporating Yidong's amendments to the
> manipulations of `file-local-variables-alist'.  Please try this out!
> 

It works fine.  Setting c-cleanup-list in a hook or by customize does the same 
thing now.

	Jan D.

Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Jan!

On Mon, Jul 20, 2009 at 11:40:22AM +0200, Jan Djärv wrote:

> Alan Mackenzie skrev:

> >Here's a better patch, incorporating Yidong's amendments to the
> >manipulations of `file-local-variables-alist'.  Please try this out!

> It works fine.  Setting c-cleanup-list in a hook or by customize does
> the same thing now.

Good!  I committed it to the Emacs-23.1 branch, but Yidong asked me to
take it out again, quite justifiably.  We are too close to the release.
So 23.1 will be going out without that patch.  :-(

However, I think you'd agree that it's not really a critical bug, no
matter how annoying it is.  The fix is in the trunk for Emacs 23.2.

> 	Jan D.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Jan Djärv]

Alan Mackenzie skrev:
> Hi, Jan!
> 
> On Mon, Jul 20, 2009 at 11:40:22AM +0200, Jan Djärv wrote:
> 
>> Alan Mackenzie skrev:
> 
>>> Here's a better patch, incorporating Yidong's amendments to the
>>> manipulations of `file-local-variables-alist'.  Please try this out!
> 
>> It works fine.  Setting c-cleanup-list in a hook or by customize does
>> the same thing now.
> 
> Good!  I committed it to the Emacs-23.1 branch, but Yidong asked me to
> take it out again, quite justifiably.  We are too close to the release.
> So 23.1 will be going out without that patch.  :-(

Since dir-locals.el is quite new, few if any will get bitten by this I think.

> 
> However, I think you'd agree that it's not really a critical bug, no
> matter how annoying it is.  The fix is in the trunk for Emacs 23.2.

That is good.  Nice work by all who sorted this out.

	Jan D.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stefan Monnier]

>> In particular, the File Style and local variables settings are rarely
>> used precision instruments, for configuring unusual files unusually.
> This indicates that we should not set c-file-style in the .dir-locals.el
> file of the Emacs source tree.

Actually, I wonder: why would it be correct to use another style than GNU
for C files inside the Emacs source tree?

I don't think it's a feature that dir-locals.el takes precedence over
mode-hooks (it's more of an accident that we consider sufficiently
harmless not to fix it, especially since a fix would probably be
difficult/inconvenient/buggy), but in this case it seems to provide just
the behavior we want.  I mean we do want to "impose" the GNU style in
our files, no matter what the user usually prefers.

What am I missing?


        Stefan

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stephen J. Turnbull]

Stefan Monnier writes:

 > I don't think it's a feature that dir-locals.el takes precedence over
 > mode-hooks

FWIW, I think it *is* a feature.  mode-hooks are globals, and having
globals override more local configuration makes those local
configurations unreliable and much less useful.

Yes, we should give user tastes precedence unless we have very good
reasons otherwise.  That's a reason to be very careful about what one
puts in dir-locals, not a reason to change the precedence of
dir-locals vs. mode-hooks.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Jan Djärv]

Stefan Monnier skrev:
>>> In particular, the File Style and local variables settings are rarely
>>> used precision instruments, for configuring unusual files unusually.
>> This indicates that we should not set c-file-style in the .dir-locals.el
>> file of the Emacs source tree.
> 
> Actually, I wonder: why would it be correct to use another style than GNU
> for C files inside the Emacs source tree?
> 
> I don't think it's a feature that dir-locals.el takes precedence over
> mode-hooks (it's more of an accident that we consider sufficiently
> harmless not to fix it, especially since a fix would probably be
> difficult/inconvenient/buggy), but in this case it seems to provide just
> the behavior we want.  I mean we do want to "impose" the GNU style in
> our files, no matter what the user usually prefers.
> 
> What am I missing?
> 
> 

That setting space-before-funcall in c-cleanup-list is a very reasonable thing 
to do in the context of the GNU-style (why isn't it on by default for GNU?), 
and in no way breaks the imposed style.  But the old ways of doing that in the 
Emacs source tree doesn't work anymore, and there is nothing in NEWS, and 
AFAIK, no discussion about it has taken place.  It is just one of those 
frustrating WTF-discoveries.

	Jan D.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Davis Herring]

>> I don't think it's a feature that dir-locals.el takes precedence over
>> mode-hooks (it's more of an accident that we consider sufficiently
>> harmless not to fix it, especially since a fix would probably be
>> difficult/inconvenient/buggy), but in this case it seems to provide just
>> the behavior we want.  I mean we do want to "impose" the GNU style in
>> our files, no matter what the user usually prefers.
>>
>> What am I missing?
>
> That setting space-before-funcall in c-cleanup-list is a very
> reasonable thing to do in the context of the GNU-style (why isn't it
> on by default for GNU?), and in no way breaks the imposed style.  But
> the old ways of doing that in the Emacs source tree doesn't work
> anymore, and there is nothing in NEWS, and AFAIK, no discussion about
> it has taken place.  It is just one of those frustrating
> WTF-discoveries.

That's the specific case that started this, yes.  But I think the general
point (that Stephen has made) bears another statement: the variable
`c-file-style' controls both things that ought to be the decision of a
project (like indentation and brace placement) and things that ought to be
the decision of each individual user (like what sort of cleanup to do
automatically).  Once we realize that, the problem is obvious: that
coupling of choices (that are properly made by different people) prevents
_any_ order of precedence from being correct.

There is the separate issue that .dir-locals.el is harder to notice than
true file-local variables, and so confusion is likely when it does
unexpected things (like this).  The proposed addition to the output of C-h
v would go a long way towards fixing that; my implementation suggestion is
to have `hack-local-variables' make (buffer-local) lists `file-locals' and
`dir-locals' of symbols that have been made local for the appropriate
reason.  (Of course, a later `setq' or `kill-local-variable' can render
these lists inaccurate.  The latter doesn't matter, since C-h v would see
that it wasn't local anyway.  The lists could contain their original local
values as well to detect the former case.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Alan Mackenzie]

Hi, Davis!

On Tue, Jul 14, 2009 at 07:05:20AM -0700, Davis Herring wrote:
> >> I don't think it's a feature that dir-locals.el takes precedence
> >> over mode-hooks (it's more of an accident that we consider
> >> sufficiently harmless not to fix it, especially since a fix would
> >> probably be difficult/inconvenient/buggy), but in this case it seems
> >> to provide just the behavior we want.  I mean we do want to "impose"
> >> the GNU style in our files, no matter what the user usually prefers.

> >> What am I missing?

> > That setting space-before-funcall in c-cleanup-list is a very
> > reasonable thing to do in the context of the GNU-style (why isn't it
> > on by default for GNU?), and in no way breaks the imposed style.  But
> > the old ways of doing that in the Emacs source tree doesn't work
> > anymore, and there is nothing in NEWS, and AFAIK, no discussion about
> > it has taken place.  It is just one of those frustrating
> > WTF-discoveries.

> That's the specific case that started this, yes.  But I think the general
> point (that Stephen has made) bears another statement: the variable
> `c-file-style' controls both things that ought to be the decision of a
> project (like indentation and brace placement) and things that ought to be
> the decision of each individual user (like what sort of cleanup to do
> automatically).  Once we realize that, the problem is obvious: that
> coupling of choices (that are properly made by different people) prevents
> _any_ order of precedence from being correct.

I don't quite agree.  The distinction between project things (e.g. brace
placement) and personal things isn't all that clear cut.  For example,
within c-cleanup-list, the effect of 'brace-else-brace (when "}\n  else
\n  {" has the \ns removed) might well be a project formatting standard,
yet 'space-before-funcall (inserts space into "foo()") might be personal.

How often do coding standards with such stupid finnicky formatting things
get observed at all?  ;-)

> There is the separate issue that .dir-locals.el is harder to notice than
> true file-local variables, and so confusion is likely when it does
> unexpected things (like this).  The proposed addition to the output of C-h
> v would go a long way towards fixing that;

How about (message "~/emacs/.dir-locals.el" loaded for %s"
                   (buffer-file-name))
?  There's a very good chance a hacker would notice this.

> my implementation suggestion is to have `hack-local-variables' make
> (buffer-local) lists `file-locals' and `dir-locals' of symbols that
> have been made local for the appropriate reason.  (Of course, a later
> `setq' or `kill-local-variable' can render these lists inaccurate.  The
> latter doesn't matter, since C-h v would see that it wasn't local
> anyway.  The lists could contain their original local values as well to
> detect the former case.)

How about a flag for {en,dis}abling .dir-locals, independent from
anything to do with file local variables?

> Davis

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Davis Herring]

> I don't quite agree.  The distinction between project things (e.g. brace
> placement) and personal things isn't all that clear cut.  For example,
> within c-cleanup-list, the effect of 'brace-else-brace (when "}\n  else
> \n  {" has the \ns removed) might well be a project formatting standard,
> yet 'space-before-funcall (inserts space into "foo()") might be personal.

My understanding is that people don't want _automatic_ cleanup forced on
them (so that they can edit as they're used to without having it change
things unexpectedly) even though they will follow the convention
eventually.  For indentation, though, it seems that no one wants their own
indentation style "until they're ready to apply the project conventions".

> How often do coding standards with such stupid finnicky formatting things
> get observed at all?  ;-)

Depends on the quality of the maintainer's coffee (and of their fire breath).

> How about (message "~/emacs/.dir-locals.el" loaded for %s"
>                    (buffer-file-name))
> ?  There's a very good chance a hacker would notice this.

My feeling is that there are too many messages that show up when visiting
a file (many of which have to do with optional packages), and so such a
message is likely to get lost.  It would be in *Messages*, though, which
might be enough once our hacker notices that something is amiss.

> How about a flag for {en,dis}abling .dir-locals, independent from
> anything to do with file local variables?

Sure, why not; it's trivial to implement and to understand.  But it has to
default to t, because otherwise you'll never even know that there are
directory-locals that you're supposed to be seeing.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Miles Bader]

"Davis Herring" <herring@lanl.gov> writes:
> My understanding is that people don't want _automatic_ cleanup forced on
> them (so that they can edit as they're used to without having it change
> things unexpectedly) even though they will follow the convention
> eventually.

If I understand the documentation, c-cleanup-list doesn't apply anyway
unless you have electric mode enabled -- and if you have that enabled,
all sorts of stuff starts to happen "automatically".  So it seems a bit
of a stretch to say it "forces" anything.

-Miles

-- 
Arrest, v. Formally to detain one accused of unusualness.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Juri Linkov]

>> How about (message "~/emacs/.dir-locals.el" loaded for %s"
>>                    (buffer-file-name))
>> ?  There's a very good chance a hacker would notice this.
>
> My feeling is that there are too many messages that show up when visiting
> a file (many of which have to do with optional packages), and so such a
> message is likely to get lost.  It would be in *Messages*, though, which
> might be enough once our hacker notices that something is amiss.

I think `message' should be improved to collect all messages coming
in quick succession and display all of them appended to the echo area.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Drew Adams]

> I think `message' should be improved to collect all messages coming
> in quick succession and display all of them appended to the echo area.

Certainly not as the default behavior. Perhaps as an alternative behavior.

There is lots of code, I'm sure, that depends on one message supplanting a
previous message. That is, the user is _supposed_ to see only the latest
message, not a concatenation of the last several messages.

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stefan Monnier]

>> I think `message' should be improved to collect all messages coming
>> in quick succession and display all of them appended to the echo area.

> Certainly not as the default behavior. Perhaps as an alternative behavior.

> There is lots of code, I'm sure, that depends on one message supplanting a
> previous message. That is, the user is _supposed_ to see only the latest
> message, not a concatenation of the last several messages.

Agreed, it needs to be a new function.

Maybe we could create a new function (notify-user MSG &rest ARGS) which
would return immediately but display something in the echo area (or at
the end of the minibuffer) for (at least?) notify-user-time seconds.

Several successive calls to it would just queue up messages that are
later displayed in turn (probably with some sort of "compaction" feature
so repeated messages don't bore the user to death).

Maybe it should be integrated/combined with the display-warning facility.


        Stefan

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Thu, Jul 16, 2009 at 8:38 PM, Stefan Monnier<monnier@iro.umontreal.ca> wrote:
>>> I think `message' should be improved to collect all messages coming
>>> in quick succession and display all of them appended to the echo area.
>
>> Certainly not as the default behavior. Perhaps as an alternative behavior.
>
>> There is lots of code, I'm sure, that depends on one message supplanting a
>> previous message. That is, the user is _supposed_ to see only the latest
>> message, not a concatenation of the last several messages.
>
> Agreed, it needs to be a new function.
>
> Maybe we could create a new function (notify-user MSG &rest ARGS) which
> would return immediately but display something in the echo area (or at
> the end of the minibuffer) for (at least?) notify-user-time seconds.
>
> Several successive calls to it would just queue up messages that are
> later displayed in turn (probably with some sort of "compaction" feature
> so repeated messages don't bore the user to death).
>
> Maybe it should be integrated/combined with the display-warning facility.


This is a quite difficult problem. I think messages should be
classified someway. Now we have warning/message which are displayed
quite differently. We also have debug messages which does not appear
in the message buffer ("entered debugger ...").

- I think it should be integrated.
- Showing important messages as Juri suggested seems good, but
displaying everything that way is probably not good.
- Using colors for classified messages is probably useful. (They
should be kept in colors in the messages buffer too.)

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Juri Linkov]

> This is a quite difficult problem. I think messages should be
> classified someway. Now we have warning/message which are displayed
> quite differently. We also have debug messages which does not appear
> in the message buffer ("entered debugger ...").
>
> - I think it should be integrated.
> - Showing important messages as Juri suggested seems good, but
> displaying everything that way is probably not good.
> - Using colors for classified messages is probably useful. (They
> should be kept in colors in the messages buffer too.)

`display-warning' is too intrusive because it changes the current
window configuration.  I'd rather display a tail of the *Messages*
buffer in the echo area.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Drew Adams]

> `display-warning' is too intrusive because it changes the current
> window configuration.  I'd rather display a tail of the *Messages*
> buffer in the echo area.

Quelle horreur.

Nothing wrong with something that shows the *Messages* tail somewhere. But,
please, not in the echo area.

If you want, add a mode/option that displays the end of *Messages* (keeps it on
top) and scrolls it automatically, so it always shows the tail. But show that
separately from the echo area.

(I just keep *Messages* visible when I want that - it does exactly that, but I
can imagine a mode that does a bit more than that.)

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Lennart Borgman]

On Thu, Jul 16, 2009 at 11:19 PM, Drew Adams<drew.adams@oracle.com> wrote:
>> `display-warning' is too intrusive because it changes the current
>> window configuration.  I'd rather display a tail of the *Messages*
>> buffer in the echo area.
>
> Quelle horreur.
>
> Nothing wrong with something that shows the *Messages* tail somewhere. But,
> please, not in the echo area.
>
> If you want, add a mode/option that displays the end of *Messages* (keeps it on
> top) and scrolls it automatically, so it always shows the tail. But show that
> separately from the echo area.
>
> (I just keep *Messages* visible when I want that - it does exactly that, but I
> can imagine a mode that does a bit more than that.)

A simple idea that (maybe) does not give more complexity, but merges
messages/warnings/errors/tracebacks:

- Show it all in the message buffer.
- Color those differently there.
- Get rid of the warnings buffer. Instead, if it is desired to do so,
open the message buffer like the warnings buffer is opened today. At
least that is not more intrusive than today...
- Errors are more severe than warnigns so do at least that much for
errors too. (But a lot of code in Emacs gives errors instead of using
catch/throw as they should. Also a catch label to just jump out of a
command without having to add a label internally would be very good...
- hope that is not more complexity...)

I think this would be a good start toward making the complexity in
this area less than today because with such a structure we could
invent common ways to make a certain message more visible.

There are complexities like that an important message might be hidden
by a later less important message (a rather common problem) but with a
structure like the one above we can try to handle it in a general way
that both programmers and users understand, recognizes and remember.

RE: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Drew Adams]

> A simple idea that (maybe) does not give more complexity, but merges
> messages/warnings/errors/tracebacks:
> 
> - Show it all in the message buffer.
> - Color those differently there.
> - Get rid of the warnings buffer. Instead, if it is desired to do so,
> open the message buffer like the warnings buffer is opened today. At
> least that is not more intrusive than today...
> - Errors are more severe than warnigns so do at least that much for
> errors too. (But a lot of code in Emacs gives errors instead of using
> catch/throw as they should. Also a catch label to just jump out of a
> command without having to add a label internally would be very good...
> - hope that is not more complexity...)
> 
> I think this would be a good start toward making the complexity in
> this area less than today because with such a structure we could
> invent common ways to make a certain message more visible.
> 
> There are complexities like that an important message might be hidden
> by a later less important message (a rather common problem) but with a
> structure like the one above we can try to handle it in a general way
> that both programmers and users understand, recognizes and remember.

There are too many things (solutions, in particular) in your mail.

I take this suggestion as noteworthy: color different message types differently.
That sounds reasonable to me.

Let's worry about one thing at at time. Later, we can worry about whether
*Messages* should have some structure (e.g. like outline mode or whatever). But
if the main problem being pointed to is having things stand out in *Messages*,
then yes, fontifying it could be a good start.

Infrastructural complexity. [Was: Blunderbuss ".dir-locals.el" raises everything in its path!!]

[Alan Mackenzie]

Hi, everybody!

On Thu, Jul 16, 2009 at 02:38:35PM -0400, Stefan Monnier wrote:
> >> I think `message' should be improved to collect all messages coming
> >> in quick succession and display all of them appended to the echo area.

> > Certainly not as the default behavior. Perhaps as an alternative behavior.

> > There is lots of code, I'm sure, that depends on one message supplanting a
> > previous message. That is, the user is _supposed_ to see only the latest
> > message, not a concatenation of the last several messages.

> Agreed, it needs to be a new function.

> Maybe we could create a new function (notify-user MSG &rest ARGS) which
> would return immediately but display something in the echo area (or at
> the end of the minibuffer) for (at least?) notify-user-time seconds.

> Several successive calls to it would just queue up messages that are
> later displayed in turn (probably with some sort of "compaction"
> feature so repeated messages don't bore the user to death).

> Maybe it should be integrated/combined with the display-warning
> facility.

I think I have to step in and ask what are we doing and why.

<Rant mode>

The suggested functionality would be fine and dandy, but who really cares
about queueing up successive messages for pretty display?  How many
not-yet users would say "here's something neat I really want to learn
Emacs for!"?

It would add complexity to Emacs, and I suggest the increase in
flexibility is not enough to justify this.  I hope I'm not sounding too
cynical, but I started this thread almost defeated by complexity which
seems questionable.  Each little added facility feels compelling at the
time it's made, but somehow all the little bits gradually mutate into a
monster.  I ought to know, I'm maintaining CC Mode.  ;-(

Here's what seems to have happened with CC Mode style variables:
1/- Styles in CC Modes are a great idea.
2/- But some users still want to put "(setq c-basic-offset 3)" at the top
  level.
3/- Some users have been setting c-basic-offset in `c-mode-hook', and
  want to carry on doing so.
4/- File local variables are great.
5/- But surely users should be able to set a CC Mode style in file local
  variables.
6/- (Just recently) A project should be able to set "directory local"
  variables.
7/- But hey, we should be able to set a CC Mode style directorily
  locally.
8/- .....

Bit by bit, another "good idea" gets added in.  Where does all this stop?
Who needs all this complexity?  The interaction of all these features has
gone past the point where my poor little brain can confortably grasp
them, and I think Stefan's admitted the same for him.  Do any users
really, really care about all this flexibility?  Are we enhancing a world
beating editor, or are we really just contemplating our collective
navals?

Tracking down all the ways a CC Mode style variable can be initialised
stop being fun for me quite some while ago.  I'd love to get rid of some
of the complexity.

Why are we spending time talking about "intelligent" queueing up of
different categories of message?  Why aren't we, say, getting ECB
integrated instead?  Why aren't we writing refactoring functions?  Why
aren't we writing an ODF word processor mode?  You know, Open Office
Writer, using key sequences taken from Microsoft Word, just isn't nice to
use.

Just as an aside, I've been working on several difficult CC Mode problems
the last few weeks; difficult, but interesting and essential.  The
distraction to fix this little frippery hasn't been welcome, even though
the buggy code is largely in my area.

When considering new "infrastructure" features (as contrasted with
"feature" features, such as new modes like ECB), could we, perhaps,
change the focus from "is this useful?" to "is this something we can't
manage without?"

</Rant mode>

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Infrastructural complexity. [Was: Blunderbuss ".dir-locals.el" raises everything in its path!!]

[Lennart Borgman]

On Thu, Jul 16, 2009 at 10:09 PM, Alan Mackenzie<acm@muc.de> wrote:
> Hi, everybody!
>
> On Thu, Jul 16, 2009 at 02:38:35PM -0400, Stefan Monnier wrote:
>> >> I think `message' should be improved to collect all messages coming
>> >> in quick succession and display all of them appended to the echo area.
>
>> > Certainly not as the default behavior. Perhaps as an alternative behavior.
>
>> > There is lots of code, I'm sure, that depends on one message supplanting a
>> > previous message. That is, the user is _supposed_ to see only the latest
>> > message, not a concatenation of the last several messages.
>
>> Agreed, it needs to be a new function.
>
>> Maybe we could create a new function (notify-user MSG &rest ARGS) which
>> would return immediately but display something in the echo area (or at
>> the end of the minibuffer) for (at least?) notify-user-time seconds.
>
>> Several successive calls to it would just queue up messages that are
>> later displayed in turn (probably with some sort of "compaction"
>> feature so repeated messages don't bore the user to death).
>
>> Maybe it should be integrated/combined with the display-warning
>> facility.
>
> I think I have to step in and ask what are we doing and why.
>
> <Rant mode>
>
> The suggested functionality would be fine and dandy, but who really cares
> about queueing up successive messages for pretty display?  How many
> not-yet users would say "here's something neat I really want to learn
> Emacs for!"?
>
> It would add complexity to Emacs, and I suggest the increase in
> flexibility is not enough to justify this.  I hope I'm not sounding too
> cynical, but I started this thread almost defeated by complexity which
> seems questionable.  Each little added facility feels compelling at the
> time it's made, but somehow all the little bits gradually mutate into a
> monster.  I ought to know, I'm maintaining CC Mode.  ;-(


I think that making message/error/warning/traceback  better together
decreases the overall complexity.

It adds complexity to this part but lessens that in other parts where
you need the integrated functionality. And getting better feedback
about problems in the ui catches problems earlier and that reduces
complexity when trying to find a problem.

Re: Infrastructural complexity.

[Juri Linkov]

> Why are we spending time talking about "intelligent" queueing up of
> different categories of message?  Why aren't we, say, getting ECB
> integrated instead?  Why aren't we writing refactoring functions?

Because messages missing by the user is a real problem in Emacs.
Most modern IDEs has no such problem since they have a special
`Log' tab/window.  We are gearing towards IDE so our efforts
will count for this goal.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> Because messages missing by the user is a real problem in Emacs.
> Most modern IDEs has no such problem since they have a special
> `Log' tab/window.  We are gearing towards IDE so our efforts
> will count for this goal.

I'm not sure this argument is valid, since one can set up a dedicated
*Messages* window in Emacs, if desired.

Re: Infrastructural complexity.

[Lennart Borgman]

On Thu, Jul 16, 2009 at 11:28 PM, Chong Yidong<cyd@stupidchicken.com> wrote:
> Juri Linkov <juri@jurta.org> writes:
>
>> Because messages missing by the user is a real problem in Emacs.
>> Most modern IDEs has no such problem since they have a special
>> `Log' tab/window.  We are gearing towards IDE so our efforts
>> will count for this goal.
>
> I'm not sure this argument is valid, since one can set up a dedicated
> *Messages* window in Emacs, if desired.

Why does that help? Don't we need the protected window feature that
will (hopefully) be included (for ECB)?

RE: Infrastructural complexity.

[Drew Adams]

> >> Because messages missing by the user is a real problem in Emacs.
> >> Most modern IDEs has no such problem since they have a special
> >> `Log' tab/window.  We are gearing towards IDE so our efforts
> >> will count for this goal.
> >
> > I'm not sure this argument is valid, since one can set up a 
> > dedicated *Messages* window in Emacs, if desired.
> 
> Why does that help? Don't we need the protected window feature that
> will (hopefully) be included (for ECB)?

What's the "protected window feature"? Never heard of it. If you introduce stuff
into the discussion, at least give people a pointer to what you mean.

I admit that I don't yet understand what problem we are trying to solve here. So
Yidong's suggestion made sense to me - that's in fact what I do, I guess: show
*Messages* in a dedicated window (and let it tail itself).

IMO, it would help others (beyond those few here who seem to understand the
problem and proposed solutions) to give a few concrete examples of the problem -
one per message type, perhaps.

IOW, I suspect you few are way ahead of the rest of us. What, exactly, is the
problem?

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 17, 2009 at 12:00 AM, Drew Adams<drew.adams@oracle.com> wrote:
>> >> Because messages missing by the user is a real problem in Emacs.
>> >> Most modern IDEs has no such problem since they have a special
>> >> `Log' tab/window.  We are gearing towards IDE so our efforts
>> >> will count for this goal.
>> >
>> > I'm not sure this argument is valid, since one can set up a
>> > dedicated *Messages* window in Emacs, if desired.
>>
>> Why does that help? Don't we need the protected window feature that
>> will (hopefully) be included (for ECB)?
>
> What's the "protected window feature"? Never heard of it. If you introduce stuff
> into the discussion, at least give people a pointer to what you mean.

There is no "protected windows" yet, but ECB tries to implement them.
It is windows that are not affected by window commands that deletes
windows, like C-x 1, C-x 0.

I have no idea what we will call, that is why I gave a pointer to ECB,
but of course only those that are familiar with ECB will understand
me. Sorry.

There was a long discussion of this feature here some time ago. ECB
uses advice to achieve this now. The solution is surpricingly good,
but there are some smaller irritating problems with it of course.

RE: Infrastructural complexity.

[Drew Adams]

> >> >> Because messages missing by the user is a real problem in Emacs.
> >> >> Most modern IDEs has no such problem since they have a special
> >> >> `Log' tab/window.  We are gearing towards IDE so our efforts
> >> >> will count for this goal.
> >> >
> >> > I'm not sure this argument is valid, since one can set up a
> >> > dedicated *Messages* window in Emacs, if desired.
> >>
> >> Why does that help? Don't we need the protected window feature that
> >> will (hopefully) be included (for ECB)?
>
> There is no "protected windows" yet, but ... It is windows that
> are not affected by window commands that deletes windows,
> like C-x 1, C-x 0.

OK, so let's forget about ECB for the moment. You are saying, I guess, that
unless we can protect the *Messages* window from being deleted, what Yidong
suggested won't help (or it won't be sufficient). Is that it?

If so, why not? I don't see why the window needs to be protected from deletion.
Can you give a concrete example of the problem?

FWIW - I show *Messages* in its own frame, in a dedicated window. It tails
itself naturally (assuming point is at eob). I can leave *Messages* showing or I
can delete its frame/window, if I want. Nothing else will delete or displace it
behind my back. I can easily adjust the frame/window height to change the "tail"
size. What more is needed? What is the problem here that what I'm already doing
doesn't solve?

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 17, 2009 at 12:25 AM, Drew Adams<drew.adams@oracle.com> wrote:
>> >> >> Because messages missing by the user is a real problem in Emacs.
>> >> >> Most modern IDEs has no such problem since they have a special
>> >> >> `Log' tab/window.  We are gearing towards IDE so our efforts
>> >> >> will count for this goal.
>> >> >
>> >> > I'm not sure this argument is valid, since one can set up a
>> >> > dedicated *Messages* window in Emacs, if desired.
>> >>
>> >> Why does that help? Don't we need the protected window feature that
>> >> will (hopefully) be included (for ECB)?
>>
>> There is no "protected windows" yet, but ... It is windows that
>> are not affected by window commands that deletes windows,
>> like C-x 1, C-x 0.
>
> OK, so let's forget about ECB for the moment. You are saying, I guess, that
> unless we can protect the *Messages* window from being deleted, what Yidong
> suggested won't help (or it won't be sufficient). Is that it?

What I wanted to say is that "dedicated window" does not help that
much for this problem. However a "protected window" help (if you want
to keep it open on the same frame).


> If so, why not? I don't see why the window needs to be protected from deletion.
> Can you give a concrete example of the problem?
>
> FWIW - I show *Messages* in its own frame, in a dedicated window. It tails
> itself naturally (assuming point is at eob). I can leave *Messages* showing or I
> can delete its frame/window, if I want. Nothing else will delete or displace it
> behind my back. I can easily adjust the frame/window height to change the "tail"
> size. What more is needed? What is the problem here that what I'm already doing
> doesn't solve?

Yes, that works, it is how I usually do it too.

RE: Infrastructural complexity.

[Drew Adams]

> What I wanted to say is that "dedicated window" does not help that
> much for this problem. However a "protected window" help (if you want
> to keep it open on the same frame).

Doesn't it do the job if it is alone in the frame? If so, then we have at least
two alternative solutions to the problem you raise: (1) protect the window,
preventing its deletion or (2) put the window in its own frame.

I would choose #2, personally, since I want to be able to delete the frame
(dunno if that is proscribed by your window protection). And #2 is already
available, and requires no special setup - just do it. (I really don't see the
problem, I guess.)

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 17, 2009 at 12:38 AM, Drew Adams<drew.adams@oracle.com> wrote:
>> What I wanted to say is that "dedicated window" does not help that
>> much for this problem. However a "protected window" help (if you want
>> to keep it open on the same frame).
>
> Doesn't it do the job if it is alone in the frame? If so, then we have at least
> two alternative solutions to the problem you raise: (1) protect the window,
> preventing its deletion or (2) put the window in its own frame.
>
> I would choose #2, personally, since I want to be able to delete the frame
> (dunno if that is proscribed by your window protection). And #2 is already
> available, and requires no special setup - just do it. (I really don't see the
> problem, I guess.)

Your are right, this is not the problem, it is just a side-track
created by my unexplained answer to Chong's suggestion. I am not sure
what Chong actually meant and I am not sure it is important here, but
maybe he will explain.

So let us go back to a more relevant point in discussion and continue
from there. I think I did some rather useful and simple suggestions.
Could we please continue from that message instead?

Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-17 at 00:14 +0200, Lennart Borgman wrote:

> There is no "protected windows" yet, but ECB tries to implement them.
> It is windows that are not affected by window commands that deletes
> windows, like C-x 1, C-x 0.


If (and it's a moderately sized "if") I understand correctly
what functionality is desired, I think that there is a cleaner
approach:  hack frames, not windows.

How about:

A "frame" is a frame, essentially like today.  Except:

A "framelette" is like a frame, except that it is a child
of a frame.  Every frame has exactly four framelettes, always:
Two framelettes at the top and and bottom of the frame, one
just below where menus go, the other just above where the
minibuffer goes.  Two framelettes at the left and right edges,
bordered above and below by the top and bottom framelettes.

Framelettes can not be created or deleted other than
by making a new frame or killing an old frame.

The window configuration of a framelette can be nil, in 
which case the framelette is not displayed.

The rectangle left in the middle, bounded on all sides by
the four framelettes, is where the windows of the frame
go.  A command like C-x 1 clears just that one rectangle,
at least if invoked from within that rectangle.

If a window in a framelette is selected, then "selected-frame"
gives the framelette, not the parent frame.  

DELETE-FRAME in a framelette does not actually delete the
frame, it only sets its window configuration to nil and
selects a window in the middle of the parent frame.

Trying to hack what I think you are trying to do just
at the window level seems like it will overly complicate
the problem of coming up with a better window configuration
system.  Hacking it at the frame level and keeping it simple
with just the four framelettes seems like you an do all the 
neat IDE GUIish stuff without too badly mucking up long-standing
abstractions.

I would expect the modes most often used in buffers whose
windows live in framelettes to not treat commands like C-x 1
quite normally - but they can do that easily without horking
too badly what such commands normally mean.

-t




> 
> I have no idea what we will call, that is why I gave a pointer to ECB,
> but of course only those that are familiar with ECB will understand
> me. Sorry.
> 
> There was a long discussion of this feature here some time ago. ECB
> uses advice to achieve this now. The solution is surpricingly good,
> but there are some smaller irritating problems with it of course.

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 17, 2009 at 12:49 AM, Thomas Lord<lord@emf.net> wrote:
> On Fri, 2009-07-17 at 00:14 +0200, Lennart Borgman wrote:
>
>> There is no "protected windows" yet, but ECB tries to implement them.
>> It is windows that are not affected by window commands that deletes
>> windows, like C-x 1, C-x 0.
>
>
> If (and it's a moderately sized "if") I understand correctly
> what functionality is desired, I think that there is a cleaner
> approach:  hack frames, not windows.
>
> How about:
>
> A "frame" is a frame, essentially like today.  Except:
>
> A "framelette" is like a frame, except that it is a child
> of a frame.  Every frame has exactly four framelettes, always:
> Two framelettes at the top and and bottom of the frame, one
> just below where menus go, the other just above where the
> minibuffer goes.  Two framelettes at the left and right edges,
> bordered above and below by the top and bottom framelettes.

I am unable to understand the "four framelettes". Why not just let any
window be a framelette if desired?


> Framelettes can not be created or deleted other than
> by making a new frame or killing an old frame.
>
> The window configuration of a framelette can be nil, in
> which case the framelette is not displayed.
>
> The rectangle left in the middle, bounded on all sides by
> the four framelettes, is where the windows of the frame
> go.  A command like C-x 1 clears just that one rectangle,
> at least if invoked from within that rectangle.
>
> If a window in a framelette is selected, then "selected-frame"
> gives the framelette, not the parent frame.
>
> DELETE-FRAME in a framelette does not actually delete the
> frame, it only sets its window configuration to nil and
> selects a window in the middle of the parent frame.
>
> Trying to hack what I think you are trying to do just
> at the window level seems like it will overly complicate
> the problem of coming up with a better window configuration
> system.  Hacking it at the frame level and keeping it simple
> with just the four framelettes seems like you an do all the
> neat IDE GUIish stuff without too badly mucking up long-standing
> abstractions.
>
> I would expect the modes most often used in buffers whose
> windows live in framelettes to not treat commands like C-x 1
> quite normally - but they can do that easily without horking
> too badly what such commands normally mean.
>
> -t
>
>
>
>
>>
>> I have no idea what we will call, that is why I gave a pointer to ECB,
>> but of course only those that are familiar with ECB will understand
>> me. Sorry.
>>
>> There was a long discussion of this feature here some time ago. ECB
>> uses advice to achieve this now. The solution is surpricingly good,
>> but there are some smaller irritating problems with it of course.
>
>
>

Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-17 at 00:54 +0200, Lennart Borgman wrote:

> I am unable to understand the "four framelettes". Why not just let any
> window be a framelette if desired?


I can't imagine a clean way for that to work
for two reasons.   First, it would allow unbounded
nesting of framelettes.  Second, I don't know about
you but I can't think of any semantics for window 
configurations that would make that work nicely.

That being said, I'll observe that "any window a 
framelette" is easily construed as a generalization
of "four fixed framelettes in the customary toolbar
and panel positions" and so it is not so absurd to think
of starting with the conceptually simpler "four framelettes"
idea and generalizing later if clear answers appear
for unbounded nesting and window configuration semantics.

-t

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 17, 2009 at 1:44 AM, Thomas Lord<lord@emf.net> wrote:
> On Fri, 2009-07-17 at 00:54 +0200, Lennart Borgman wrote:
>
>> I am unable to understand the "four framelettes". Why not just let any
>> window be a framelette if desired?
>
>
> I can't imagine a clean way for that to work
> for two reasons.   First, it would allow unbounded
> nesting of framelettes.

Why is that a problem?


> Second, I don't know about
> you but I can't think of any semantics for window
> configurations that would make that work nicely.

I am not sure I understand. I just think of it as you described it (on
a general level).

- Inside a framelett window commands just affects that framelet.
- A framelet inside a framelet is just treated as any other window if
you are outside of it.
- A framelet or a single window can be marked as "protected", but that
holds just when you are doing operations from windows inside the same
level. (Inside they do not touch them by definitions above and outside
they are just seen as windows on the same level which may be protected
or not.)


> That being said, I'll observe that "any window a
> framelette" is easily construed as a generalization
> of "four fixed framelettes in the customary toolbar
> and panel positions" and so it is not so absurd to think
> of starting with the conceptually simpler "four framelettes"
> idea and generalizing later if clear answers appear
> for unbounded nesting and window configuration semantics.

I do not understand why you think this is conceptually easier to
restrict it to four framelettes and just one sublevel. Why is it
easier? (I guess the code would have to handle that restriction and it
just seems more complicated to me.)

Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-17 at 02:30 +0200, Lennart Borgman wrote:
> On Fri, Jul 17, 2009 at 1:44 AM, Thomas Lord<lord@emf.net> wrote:
> > On Fri, 2009-07-17 at 00:54 +0200, Lennart Borgman wrote:

> >> I am unable to understand the "four framelettes". Why not just let any
> >> window be a framelette if desired?

> > I can't imagine a clean way for that to work
> > for two reasons.   First, it would allow unbounded
> > nesting of framelettes.

> Why is that a problem?

That's a good question.  

I'm concerned because I'm imagining the case of
user commands that operate on the "selected-frame".
(I'm also concerned about how it looks to lisp
programs but it's easiest to introduce the concerns
from a user perspective.)

C-x 1 is a suitable example.  As thing stands,
C-x 1 operates on *the* selected frame.  With
the "four framelettes" notion, now there is a little
potential ambiguity but we can (usefully, I think) say
that if the current window is in a framelette, the
command applies to that framelette - otherwise to the frame.
It's easy for users to learn that the framelettes around
the borders are one context for C-x 1, the space in the
middle a separate context.


Now, what if the current window is underneath a hierarchical
list of 5 framelettes?  I, the user, want C-x 1 to apply
to the third framelette in that list.   What then?
I can't think of any usable solution.  How is a user supposed
to figure out, trivially, without stopping and solving a 
slightly complicated puzzle, which window to select to 
achieve that desired C-x 1 effect?

I think that as window configuration support improves
and as things get more IDEish, "C-x 1" will be the least
of our problems.   That is, I anticipate a wealth of 
fancier ways for users to manipulate window config but,
with arbitrarily nested frames, the question still hangs
of how a user is supposed to select which, in a nested 
list, window config to change.

It's for reasons like that I think a simple, 2-level
frame/framelette abstraction is a good idea.

As I wrote the above another idea occurred to me:
What about (as in, e.g., GIMP) "tear offs".  A tear
off is a separate window-system window (not an emacs
window) and could be naturally modeled as a 
framelette in a 2-layer frame/framelette hierarchy.

Putting on my "dabble in mysticism" hat, there
are essentially three natural numbers greater than
0:  one, two, and "many".  Nesting of frame-like
things is currently at "one".  How about trying "two"
before jumping to "many".  Sometimes "two" is enough.



> > Second, I don't know about
> > you but I can't think of any semantics for window
> > configurations that would make that work nicely.

> I am not sure I understand. I just think of it as you described it (on
> a general level).

I don't see the "generalization" you are after.




> - Inside a framelett window commands just affects that framelet.
> - A framelet inside a framelet is just treated as any other window if
> you are outside of it.
> - A framelet or a single window can be marked as "protected", but that
> holds just when you are doing operations from windows inside the same
> level. (Inside they do not touch them by definitions above and outside
> they are just seen as windows on the same level which may be protected
> or not.) 

I don't see any convincing story about how user's have a 
friendly nice model for those "levels" beyond two.

I also don't see any useful way to treat framelettes
other than the four around the periphery (perhaps
plus "tear offs").  




> > That being said, I'll observe that "any window a
> > framelette" is easily construed as a generalization
> > of "four fixed framelettes in the customary toolbar
> > and panel positions" and so it is not so absurd to think
> > of starting with the conceptually simpler "four framelettes"
> > idea and generalizing later if clear answers appear
> > for unbounded nesting and window configuration semantics.
> 
> I do not understand why you think this is conceptually easier to
> restrict it to four framelettes and just one sublevel. Why is it
> easier? (I guess the code would have to handle that restriction and it
> just seems more complicated to me.)

Another way to say why it is easier is that users don't
have to think very hard about "frame v. framelette".  They
can just learn, as they have with so many other GUIs, that there
are these four special areas around the main content of a window-system
window (and perhaps "tear offs").


-t

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 17, 2009 at 3:18 AM, Thomas Lord<lord@emf.net> wrote:
> On Fri, 2009-07-17 at 02:30 +0200, Lennart Borgman wrote:
>> On Fri, Jul 17, 2009 at 1:44 AM, Thomas Lord<lord@emf.net> wrote:
>> > On Fri, 2009-07-17 at 00:54 +0200, Lennart Borgman wrote:
>
>> >> I am unable to understand the "four framelettes". Why not just let any
>> >> window be a framelette if desired?
>
>> > I can't imagine a clean way for that to work
>> > for two reasons.   First, it would allow unbounded
>> > nesting of framelettes.
>
>> Why is that a problem?
>
> Now, what if the current window is underneath a hierarchical
> list of 5 framelettes?  I, the user, want C-x 1 to apply
> to the third framelette in that list.   What then?
> I can't think of any usable solution.  How is a user supposed
> to figure out, trivially, without stopping and solving a
> slightly complicated puzzle, which window to select to
> achieve that desired C-x 1 effect?

Thanks. I see your point, however I expected the framelets border to
be marked in some way. Your note about GIMP made me think of another,
additional, way: Using a different background color for the active
framelet.



> Putting on my "dabble in mysticism" hat, there
> are essentially three natural numbers greater than
> 0:  one, two, and "many".

That is more about human couple relationship ...


>> I am not sure I understand. I just think of it as you described it (on
>> a general level).
>
> I don't see the "generalization" you are after.

Just the level thing.


> Another way to say why it is easier is that users don't
> have to think very hard about "frame v. framelette".  They
> can just learn, as they have with so many other GUIs, that there
> are these four special areas around the main content of a window-system
> window (and perhaps "tear offs").

That might be a thing for the actually used user interfaces, but on
the devel side I see no reason to put in that restriction. Rather it
could be on option to set that restriction on the user side.

Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-17 at 03:29 +0200, Lennart Borgman wrote:

> That might be a thing for the actually used user interfaces, but on
> the devel side I see no reason to put in that restriction. Rather it
> could be on option to set that restriction on the user side.

[context: restrict or don't restrict "framelettes" to 
one level of nesting below frames, etc.]

I just don't see what rules you'd reasonably 
make up for that nesting in various primitives.
I can imagine rules that can be implemented but 
not rules that have a rationale.

I'm glad you (in unquoted stuff) ack seeing my 
concern about the nesting issues and understand
where I'm coming from with my proposal.

I think my version is *probably* easier to
implement, although that only has a loose correlation
with "likely to be implemented sooner".

Thanks,
-t

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 17, 2009 at 4:21 AM, Thomas Lord<lord@emf.net> wrote:
> On Fri, 2009-07-17 at 03:29 +0200, Lennart Borgman wrote:
>
>> That might be a thing for the actually used user interfaces, but on
>> the devel side I see no reason to put in that restriction. Rather it
>> could be on option to set that restriction on the user side.
>
> [context: restrict or don't restrict "framelettes" to
> one level of nesting below frames, etc.]
>
> I just don't see what rules you'd reasonably
> make up for that nesting in various primitives.
> I can imagine rules that can be implemented but
> not rules that have a rationale.

I was not thinking about directly implementing them in the primitives.
Rather in the user commands.


> I'm glad you (in unquoted stuff) ack seeing my
> concern about the nesting issues and understand
> where I'm coming from with my proposal.
>
> I think my version is *probably* easier to
> implement, although that only has a loose correlation
> with "likely to be implemented sooner".
>
> Thanks,
> -t

Thanks for your thoughts.

Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-17 at 04:24 +0200, Lennart Borgman wrote:

> I was not thinking about directly implementing them in the primitives.
> Rather in the user commands.

Bad choice of language on my part.  I did not
mean "primitives" as in "functions written in 
C" (although I expect there will be some impact
at that level).  I meant something more like
"core" -- C prims plus the core lisp/*.el 
files.   "The stuff that defines the basic
model of Emacs" -- primitive in that sense.

-t

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 17, 2009 at 4:44 AM, Thomas Lord<lord@emf.net> wrote:
> On Fri, 2009-07-17 at 04:24 +0200, Lennart Borgman wrote:
>
>> I was not thinking about directly implementing them in the primitives.
>> Rather in the user commands.
>
> Bad choice of language on my part.  I did not
> mean "primitives" as in "functions written in
> C" (although I expect there will be some impact
> at that level).  I meant something more like
> "core" -- C prims plus the core lisp/*.el
> files.   "The stuff that defines the basic
> model of Emacs" -- primitive in that sense.

Yes, I understood that. But because I believe it is more easy to
implement it the general way (and long time wise possibly more useful)
I said that the restrictions you want may be implemented at the user
command level.

Re: Infrastructural complexity.

[joakim]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Fri, Jul 17, 2009 at 4:44 AM, Thomas Lord<lord@emf.net> wrote:
>> On Fri, 2009-07-17 at 04:24 +0200, Lennart Borgman wrote:
>>
>>> I was not thinking about directly implementing them in the primitives.
>>> Rather in the user commands.
>>
>> Bad choice of language on my part.  I did not
>> mean "primitives" as in "functions written in
>> C" (although I expect there will be some impact
>> at that level).  I meant something more like
>> "core" -- C prims plus the core lisp/*.el
>> files.   "The stuff that defines the basic
>> model of Emacs" -- primitive in that sense.
>
> Yes, I understood that. But because I believe it is more easy to
> implement it the general way (and long time wise possibly more useful)
> I said that the restrictions you want may be implemented at the user
> command level.
>
>

I'm not closely following this thread, but this discussion is similar to
the "window group" proposal. There is patches in the previous threads.

Basically window groups are groups of windows that behave somehwat like
the "framelettes" discussed here. Window operations that affect other
windows only affect the other windows in the same group as the current
window. So, delete-other-windows, for instance, only deletes the other
windows in the same group.

-- 
Joakim Verona

Re: Infrastructural complexity.

[Chong Yidong]

joakim@verona.se writes:

> I'm not closely following this thread, but this discussion is similar to
> the "window group" proposal. There is patches in the previous threads.
>
> Basically window groups are groups of windows that behave somehwat like
> the "framelettes" discussed here. Window operations that affect other
> windows only affect the other windows in the same group as the current
> window. So, delete-other-windows, for instance, only deletes the other
> windows in the same group.

Yes, we should add the window group feature (as well as merging CEDET).
I've been planning to look into this after the 23.1 release, but if
someone wants to work on it now, please do.

I recall that we had an inconclusive discussion over the relative merits
of two proposals, one by Joakim that (IIRC) relied on window parameters,
and another by Martin that uses more built-in code.  Does anyone have
any new thoughts about this?

Re: Infrastructural complexity.

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> joakim@verona.se writes:
>
>> I'm not closely following this thread, but this discussion is similar to
>> the "window group" proposal. There is patches in the previous threads.
>>
>> Basically window groups are groups of windows that behave somehwat like
>> the "framelettes" discussed here. Window operations that affect other
>> windows only affect the other windows in the same group as the current
>> window. So, delete-other-windows, for instance, only deletes the other
>> windows in the same group.
>
> Yes, we should add the window group feature (as well as merging CEDET).
> I've been planning to look into this after the 23.1 release, but if
> someone wants to work on it now, please do.
>
> I recall that we had an inconclusive discussion over the relative merits
> of two proposals, one by Joakim that (IIRC) relied on window parameters,
> and another by Martin that uses more built-in code.  Does anyone have
> any new thoughts about this?

I thought the interface of my proposal was rather nice, but then I
stumbled on some unforseen annoyances with getting some mouse operations
to work, got mad and quit working on it. I'm better now and can continue
working on it when I resolve my bzr issues. OTOH, if Martins proposal
already works, why not use it?

>
-- 
Joakim Verona

Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-17 at 14:46 -0400, Chong Yidong wrote:

> I recall that we had an inconclusive discussion over the relative merits
> of two proposals, one by Joakim that (IIRC) relied on window parameters,
> and another by Martin that uses more built-in code.  Does anyone have
> any new thoughts about this?

Yes.

One observation is that RMS posted some pretty
challenging questions about whether or not 
window groups are a good design, and these have 
gone unanswered:

http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg01769.html

I think window groups are clearly not a good
design, essentially because the questions he raises
don't have good answers that I can see.  But,
there's no need to dwell on the negative.

I've been looking at Eclipse screenshots and I 
regularly use programs like the OpenOffice suite
and Gimp and so forth.  I think I have some "feel"
for what the goals are here.

The "GUIs" you are going up against here tend
to have window system windows with a main edit
area.  At the sides or bottom or top are various
"panels" that perform ancillary functions.  Each
panel might have such things as a toolbar or set
of "tabs".   The window  system window as a whole will
have menus, a toolbar, and perhaps something like
a minibuffer.   In addition there are floating
dialog boxes and "tear offs".   So the question seems
to be how to cleanly and simply improve emacs so
that analogous things are possible.

To me, Emacs frames are an existing abstraction that
is already very close to how each individual panel,
tearoff, and pop-up works.  One key difference is 
that the panels etc. are one-level-deep subordinate
to one main "frame" - sometimes graphically nested
in them and always having commands that operate on the
basis of that subordination.  But they're frames.  
One example is if you look at Eclipse screen shots and
the panel down the left side - sometimes it is split
vertically;  sometimes the user gets to add additional
vertical splits.  That panel is, to my mind, a frame --
just with this slight "subordination" addition and 
perhaps a restriction about which buffers can be displayed
there.

When I think about what kinds of buffers would appear
in those "side frames", tear-offs etc.  well, they would
tend to be "controllers" that effect the parent frame.
"Parent frame" is a new concept but the code for those 
controllers would also be new code so it isn't unreasonable
to ask new code to recognize a new concept.

There are other GUI details in the IDEs and other programs.
Tab bars, and toolbars and such.   I can imagine clean
ways to add those to the extent they aren't already there
but nothing even remotely close to "window groups" seems
a reasonable abstraction -- at least unless it can be explained
much better than it already has been.

Something like "framelettes" seems a much better design
to me.

FWIW, of course.
-t

Re: Infrastructural complexity.

[Chong Yidong]

> To me, Emacs frames are an existing abstraction that is already very
> close to how each individual panel, tearoff, and pop-up works...  One
> example is if you look at Eclipse screen shots and the panel down the
> left side - sometimes it is split vertically; sometimes the user gets
> to add additional vertical splits.  That panel is, to my mind, a frame
> -- just with this slight "subordination" addition and perhaps a
> restriction about which buffers can be displayed there.

The proofs of concept written by Joakim and Martin already handle this
behavior.  They don't require much of a change to the usual window
semantics, either; the only new rule is that window operations only
effect the windows within the current window group (e.g., C-x 1 would
not delete the windows in other groups).

The only thing new that the "framelets" idea brings to the table is the
possibility of a separate set of tool-bars.  But I don't think it's a
big advantage considering (i) the extra engineering that would be
required to get these extra toolbars to work, and (ii) the fact that
Emacs is mostly keyboard-driven anyway.

Re: Infrastructural complexity.

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

>> To me, Emacs frames are an existing abstraction that is already very
>> close to how each individual panel, tearoff, and pop-up works...  One
>> example is if you look at Eclipse screen shots and the panel down the
>> left side - sometimes it is split vertically; sometimes the user gets
>> to add additional vertical splits.  That panel is, to my mind, a frame
>> -- just with this slight "subordination" addition and perhaps a
>> restriction about which buffers can be displayed there.
>
> The proofs of concept written by Joakim and Martin already handle this
> behavior.  They don't require much of a change to the usual window
> semantics, either; the only new rule is that window operations only
> effect the windows within the current window group (e.g., C-x 1 would
> not delete the windows in other groups).
>
> The only thing new that the "framelets" idea brings to the table is the
> possibility of a separate set of tool-bars.  But I don't think it's a
> big advantage considering (i) the extra engineering that would be
> required to get these extra toolbars to work, and (ii) the fact that
> Emacs is mostly keyboard-driven anyway.

More toolbars within Emacs windows would be doable with my xwidget
patch. But I agree keyboard-driven is the true Emacs flavour.

-- 
Joakim Verona

Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-17 at 19:49 -0400, Chong Yidong wrote:
> > To me, Emacs frames are an existing abstraction that is already very
> > close to how each individual panel, tearoff, and pop-up works...  One
> > example is if you look at Eclipse screen shots and the panel down the
> > left side - sometimes it is split vertically; sometimes the user gets
> > to add additional vertical splits.  That panel is, to my mind, a frame
> > -- just with this slight "subordination" addition and perhaps a
> > restriction about which buffers can be displayed there.
> 
> The proofs of concept written by Joakim and Martin already handle this
> behavior.  They don't require much of a change to the usual window
> semantics, either; the only new rule is that window operations only
> effect the windows within the current window group (e.g., C-x 1 would
> not delete the windows in other groups).


To my old, stubborn, set-in-my-ways mind yes, window
groups "handle that" but in a needless way.  No "new rule"
is needed for the concept of a set of windows that are the
scope of window operations - we've already got one: a frame.




> The only thing new that the "framelets" idea brings to the table is the
> possibility of a separate set of tool-bars. 


I don't think that that's a fair characterization.
Framelets accomplish the use-case goals but without
complicating the window abstraction and with only a very
minor complication added to frames.



>  But I don't think it's a
> big advantage considering (i) the extra engineering that would be
> required to get these extra toolbars to work, and (ii) the fact that
> Emacs is mostly keyboard-driven anyway.

There is no reason that toolbars can't be "keyboard-driven"
so I'm not sure what you are saying.

Toolbars are nice because they are a form of "passive recollection"
interface.   You have to actively remember that C-f means forward-char,
passive recollection is being able to search through a menu of 
commands.   For very large command sets, such as found in 
word processors or IDEs, support for passive recollection
command access is a good thing.

-t

Re: Infrastructural complexity.

[Miles Bader]

Thomas Lord <lord@emf.net> writes:
> For very large command sets, such as found in word processors or IDEs,
> support for passive recollection command access is a good thing.

Eh?  For very large command sets, tool-bars suck massively, because each
command requires physical space, all the time.  They're great for
save/load/refresh, but quickly become unwieldy and ultimately almost
unusable (see: many microsoft apps, which at some point became quite
surreal in their abuse of toolbars... [and tab-bar abuse, and...]).

-Miles

-- 
Omochiroi!

Re: Infrastructural complexity.

[Thomas Lord]

On Mon, 2009-07-20 at 13:59 +0900, Miles Bader wrote:
> Thomas Lord <lord@emf.net> writes:
> > For very large command sets, such as found in word processors or IDEs,
> > support for passive recollection command access is a good thing.
> 
> Eh?  For very large command sets, tool-bars suck massively, because each
> command requires physical space, all the time

Not if the toolbar is a hierarchical menu.



>  They're great for
> save/load/refresh, but quickly become unwieldy and ultimately almost
> unusable (see: many microsoft apps, which at some point became quite
> surreal in their abuse of toolbars... [and tab-bar abuse, and...]).


Right, there's a balance between not having this kind of menu
at all and having too much of it.

-t




> -Miles
> 

Re: Infrastructural complexity.

[joakim]

Thomas Lord <lord@emf.net> writes:

> On Fri, 2009-07-17 at 14:46 -0400, Chong Yidong wrote:
>
>> I recall that we had an inconclusive discussion over the relative merits
>> of two proposals, one by Joakim that (IIRC) relied on window parameters,
>> and another by Martin that uses more built-in code.  Does anyone have
>> any new thoughts about this?
>
> Yes.
>
> One observation is that RMS posted some pretty
> challenging questions about whether or not 
> window groups are a good design, and these have 
> gone unanswered:
>
> http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg01769.html
>
> I think window groups are clearly not a good
> design, essentially because the questions he raises
> don't have good answers that I can see.  But,
> there's no need to dwell on the negative.
>
> I've been looking at Eclipse screenshots and I 
> regularly use programs like the OpenOffice suite
> and Gimp and so forth.  I think I have some "feel"
> for what the goals are here.
>
> The "GUIs" you are going up against here tend
> to have window system windows with a main edit
> area.  At the sides or bottom or top are various
> "panels" that perform ancillary functions.  Each
> panel might have such things as a toolbar or set
> of "tabs".   The window  system window as a whole will
> have menus, a toolbar, and perhaps something like
> a minibuffer.   In addition there are floating
> dialog boxes and "tear offs".   So the question seems
> to be how to cleanly and simply improve emacs so
> that analogous things are possible.
>
> To me, Emacs frames are an existing abstraction that
> is already very close to how each individual panel,
> tearoff, and pop-up works.  One key difference is 
> that the panels etc. are one-level-deep subordinate
> to one main "frame" - sometimes graphically nested
> in them and always having commands that operate on the
> basis of that subordination.  But they're frames.  
> One example is if you look at Eclipse screen shots and
> the panel down the left side - sometimes it is split
> vertically;  sometimes the user gets to add additional
> vertical splits.  That panel is, to my mind, a frame --
> just with this slight "subordination" addition and 
> perhaps a restriction about which buffers can be displayed
> there.
>
> When I think about what kinds of buffers would appear
> in those "side frames", tear-offs etc.  well, they would
> tend to be "controllers" that effect the parent frame.
> "Parent frame" is a new concept but the code for those 
> controllers would also be new code so it isn't unreasonable
> to ask new code to recognize a new concept.
>
> There are other GUI details in the IDEs and other programs.
> Tab bars, and toolbars and such.   I can imagine clean
> ways to add those to the extent they aren't already there
> but nothing even remotely close to "window groups" seems
> a reasonable abstraction -- at least unless it can be explained
> much better than it already has been.
>
> Something like "framelettes" seems a much better design
> to me.
>
> FWIW, of course.
> -t

When I did my "windowgroups" patch, I wanted to find a simple
abstraction on which you could build other things. The ECB already does
all the Eclips:ish things you describe above, and I just wanted to find
the smalles set of primitives suitable to get rid of the advice ECB
uses. In my mind most of the issues in RMS observations are answered in
some way by ECB, and "windowgroups" lets ECB be included in Emacs, since
advice is no longer needed.

A "windowgroup" is similar to an Emacs frame, inside another emacs
frame. I like this better than using several Emacs frames.

>
-- 
Joakim Verona

Re: Infrastructural complexity.

[Lennart Borgman]

On Sat, Jul 18, 2009 at 2:05 AM, <joakim@verona.se> wrote:
> Thomas Lord <lord@emf.net> writes:
>
>> On Fri, 2009-07-17 at 14:46 -0400, Chong Yidong wrote:
>>
>>> I recall that we had an inconclusive discussion over the relative merits
>>> of two proposals, one by Joakim that (IIRC) relied on window parameters,
>>> and another by Martin that uses more built-in code.  Does anyone have
>>> any new thoughts about this?
>>
>> Yes.
>>
>> One observation is that RMS posted some pretty
>> challenging questions about whether or not
>> window groups are a good design, and these have
>> gone unanswered:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg01769.html
>>
>> I think window groups are clearly not a good
>> design, essentially because the questions he raises
>> don't have good answers that I can see.  But,
>> there's no need to dwell on the negative.
>>
>> I've been looking at Eclipse screenshots and I
>> regularly use programs like the OpenOffice suite
>> and Gimp and so forth.  I think I have some "feel"
>> for what the goals are here.

One thing many GIMP users have complained about is the lack of a
docking ability for the tool windows. (Ie keeping everything in one OS
window which simplifies switching between different applications and
make things looks nicer and less cluttered).

A small note on this: In my opinion the "docking ability" does not
necessarily have to be within one OS window. It could instead be on
the display level. By this I mean that switching to for example GIMP
could show just GIMP and hide/minimize all other application windows.




>> The "GUIs" you are going up against here tend
>> to have window system windows with a main edit
>> area.

Or several.


>> In addition there are floating
>> dialog boxes

Which I think should be implemented in Emacs. (On w32 the needed OS
level feature is "always on top" + tinier header/border parts.)

>>  and "tear offs".

What is that?



>> There are other GUI details in the IDEs and other programs.
>> Tab bars, and toolbars and such.   I can imagine clean
>> ways to add those to the extent they aren't already there
>> but nothing even remotely close to "window groups" seems
>> a reasonable abstraction -- at least unless it can be explained
>> much better than it already has been.
>>
>> Something like "framelettes" seems a much better design
>> to me.
>>
>> FWIW, of course.
>> -t
>
> When I did my "windowgroups" patch, I wanted to find a simple
> abstraction on which you could build other things. The ECB already does
> all the Eclips:ish things you describe above, and I just wanted to find
> the smalles set of primitives suitable to get rid of the advice ECB
> uses. In my mind most of the issues in RMS observations are answered in
> some way by ECB, and "windowgroups" lets ECB be included in Emacs, since
> advice is no longer needed.
>
> A "windowgroup" is similar to an Emacs frame, inside another emacs
> frame. I like this better than using several Emacs frames.


Windowgroups is a nice thing. Framelettes is also a nice thing.

I think windowgroups might be the basis for framelettes. One thing
that windowgroups does not take care of is the visual feedback to the
user which tells which windows that belongs to the group. The concept
of framelettes might help with this, but is not the only possible
solution.

However some kind of solution for the visual feedback is necessary.
Using a visual extra "frame" is one solution. Background coloring
another. Please make room for those in windowgroups.

Re: Infrastructural complexity.

[Leo]

On 2009-07-18 01:21 +0100, Lennart Borgman wrote:
> One thing many GIMP users have complained about is the lack of a
> docking ability for the tool windows. (Ie keeping everything in one OS
> window which simplifies switching between different applications and
> make things looks nicer and less cluttered).

GIMP has the *worst* GUI. 

-- 
Leo's Emacs uptime: 37 days, 10 hours, 43 minutes, 16 seconds

Re: Infrastructural complexity.

[Juri Linkov]

>> One thing many GIMP users have complained about is the lack of a
>> docking ability for the tool windows. (Ie keeping everything in one OS
>> window which simplifies switching between different applications and
>> make things looks nicer and less cluttered).
>
> GIMP has the *worst* GUI.

Because GIMP tried to mimic Photoshop GUI.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[Leo]

On 2009-07-18 23:06 +0100, Juri Linkov wrote:
>>> One thing many GIMP users have complained about is the lack of a
>>> docking ability for the tool windows. (Ie keeping everything in one OS
>>> window which simplifies switching between different applications and
>>> make things looks nicer and less cluttered).
>>
>> GIMP has the *worst* GUI.
>
> Because GIMP tried to mimic Photoshop GUI.

However, Photoshop has learnt its deficiency and evolved into a much
better one while GIMP has stuck to it.

-- 
Leo's Emacs uptime: 38 days, 23 hours, 39 minutes, 51 seconds

Re: Infrastructural complexity.

[Miles Bader]

Leo <sdl.web@gmail.com> writes:
>>> GIMP has the *worst* GUI.
>>
>> Because GIMP tried to mimic Photoshop GUI.
>
> However, Photoshop has learnt its deficiency and evolved into a much
> better one while GIMP has stuck to it.

Of course, the most vociferous complainers always seem to be hardcore
photoshop fanboys, who would scream about _anything_ which is the least
bit different than photoshop...

-Miles

-- 
Once, adj. Enough.

Re: Infrastructural complexity.

[Thomas Lord]

On Sun, 2009-07-19 at 14:21 +0100, Leo wrote:

> >> GIMP has the *worst* GUI.

> > Because GIMP tried to mimic Photoshop GUI.

> However, Photoshop has learnt its deficiency and evolved into a much
> better one while GIMP has stuck to it.


I wonder about this sentiment.   Perhaps it 
is just my twisted mind but I kind of like the
Gimp UI system.   It could (will?) benefit from
incremental spit and polish for years to come
but the basic idea seems sound.

Regardless, though, if it's easier we could
talk about the examples of OpenOffice and 
Eclipse, if those are less controversial.

Informally speaking, I'm looking forward to
an Emacs with some way to have "control panel
thingies" and tear-offs because I think that 
once we have that, soon after, (a) I won't have
to use OpenOffice writer any more;  (b) the
program I use instead will have things like C-x 2
and C-x b in the main edit area (plus all the other
lovely, logical orderliness of the Emacs command
set and command loop.

This (one way or another) is going to be awesome
and I tip my hat to the more active Emacs developers
today for their work towards it.

-t

Re: Infrastructural complexity.

[joakim]

Lennart Borgman <lennart.borgman@gmail.com> writes:


> I think windowgroups might be the basis for framelettes. One thing
> that windowgroups does not take care of is the visual feedback to the
> user which tells which windows that belongs to the group. The concept
> of framelettes might help with this, but is not the only possible
> solution.
>
> However some kind of solution for the visual feedback is necessary.
> Using a visual extra "frame" is one solution. Background coloring
> another. Please make room for those in windowgroups.

This could go into a layer on top of Window-Groups.

-- 
Joakim Verona

Re: Infrastructural complexity.

[Richard Stallman]

    A "windowgroup" is similar to an Emacs frame, inside another emacs
    frame. I like this better than using several Emacs frames.

It might be a subtle question.  To think about it, I suggest looking
at by asking: What is the difference between a windowgroup and a
framelet?  Or what are the various differences?

With a list of these differences, it might be possible to see a number
of different design options and what is better or worse about them.

Re: Infrastructural complexity.

[Juri Linkov]

>     A "windowgroup" is similar to an Emacs frame, inside another emacs
>     frame. I like this better than using several Emacs frames.
>
> It might be a subtle question.  To think about it, I suggest looking
> at by asking: What is the difference between a windowgroup and a
> framelet?  Or what are the various differences?

I guess the difference is in frame parameters.  If framelets are
Emacs frames inside the main Emacs frame, then they should have
their own menu bars, tool bars, tab bars.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[Lennart Borgman]

On Sun, Jul 19, 2009 at 12:05 AM, Juri Linkov<juri@jurta.org> wrote:
>>     A "windowgroup" is similar to an Emacs frame, inside another emacs
>>     frame. I like this better than using several Emacs frames.
>>
>> It might be a subtle question.  To think about it, I suggest looking
>> at by asking: What is the difference between a windowgroup and a
>> framelet?  Or what are the various differences?
>
> I guess the difference is in frame parameters.  If framelets are
> Emacs frames inside the main Emacs frame, then they should have
> their own menu bars, tool bars, tab bars.


Why should they need menu bars and tool bars etc? I think they would
be useful without it. We have mentioned some things:

- Windows inside forms a group.
- This group can be visually marked so a user quickly can grasp it.
- Some commands that we already have can work on windows in this
group, just as they today work on frames (nearly, of course).
- Frame commands could work on framelettes, just as...
- The concept could be made recursive (which might be usefull).

None of these requires menus or toolbars for the framelettes
themselves. (One can compare tool windows in other IDE:s. These may of
course also be implemented as "floating frames" on GUI platforms.)

Re: Infrastructural complexity.

[Juri Linkov]

> Why should they need menu bars and tool bars etc? I think they would
> be useful without it.

Have you seen Eclipse screenshots?  Eclipse and other IDE framelets have
tool bars and tab bars.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[Thomas Lord]

On Sun, 2009-07-19 at 21:23 +0300, Juri Linkov wrote:
> > Why should they need menu bars and tool bars etc? I think they would
> > be useful without it.
> 
> Have you seen Eclipse screenshots?  Eclipse and other IDE framelets have
> tool bars and tab bars.

This is more idle brainstorming than anything else:

Some quick thoughts about how I think about this design
space:

1) A useful concept is that toolbars, tab bars, and menu
bars are all "virtual input devices".   Their main function
is to give users a way to generate a distinct class of input
event types.   This concept is reflected in the existing 
support, of course, but it's useful to state it explicitly.
What kinds of "virtual input device" we have is necessarily
kind of ad hoc but that's ok because having just a few, general
purpose ad hoc virtual input devices goes a long way in terms
of utility.

2) We don't have to slavishly follow Eclipse or another
program to determine our list of virtual input devices.
When we pick virtual input device types and their behavior,
whenever possible, virtual input devices that make some sense
on plain-text smart terminals are extra nifty to have.

Given Emacs' huge command set, I'd really like to see a
virtual input device that resembled, say, the command menu
system of old PC programs like Lotus whatsit or any of the
spreadsheet programs.   This also resembles the command
menu interfaces of some HP calculators, as I recall.  Basically,
a narrow area for listing a thin menu of commands but with a 
"tree structure" so you can dig down to sub-commands or pop 
back up to parent menus.   With a "home" or "clear" command for
getting back to the root of the command tree.

-t

Re: Infrastructural complexity.

[Juri Linkov]

> This is more idle brainstorming than anything else:
>
> Some quick thoughts about how I think about this design
> space:
>
> 1) A useful concept is that toolbars, tab bars, and menu
> bars are all "virtual input devices".   Their main function
> is to give users a way to generate a distinct class of input
> event types.   This concept is reflected in the existing
> support, of course, but it's useful to state it explicitly.
> What kinds of "virtual input device" we have is necessarily
> kind of ad hoc but that's ok because having just a few, general
> purpose ad hoc virtual input devices goes a long way in terms
> of utility.

One of the main questions is where and how to attach these
virtual input devices.  It is still unclear how to attach
a tab bar (a useful virtual input device still unsupported
by Emacs unlike tool bars and menu bars) to the Emacs frame.
Last year Jan looked how to do this in GTK and concluded
this is not straightforward.  Maybe newer GTK versions provide
an easier way.

> 2) We don't have to slavishly follow Eclipse or another
> program to determine our list of virtual input devices.
> When we pick virtual input device types and their behavior,
> whenever possible, virtual input devices that make some sense
> on plain-text smart terminals are extra nifty to have.

We could implement tab bars on plain-text terminals exactly as
a menu bar line is implemented at the top on the terminal window.

> Given Emacs' huge command set, I'd really like to see a
> virtual input device that resembled, say, the command menu
> system of old PC programs like Lotus whatsit or any of the
> spreadsheet programs.   This also resembles the command
> menu interfaces of some HP calculators, as I recall.  Basically,
> a narrow area for listing a thin menu of commands but with a 
> "tree structure" so you can dig down to sub-commands or pop 
> back up to parent menus.   With a "home" or "clear" command for
> getting back to the root of the command tree.

Yes, I remember that in Lotus 1-2-3 the slash key activated
a keyboard-driven menu.  Since in Emacs keymaps and menus
have the same structure it is easy to do the same in Emacs.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[Thomas Lord]

On Sun, 2009-07-19 at 23:57 +0300, Juri Linkov wrote:

> One of the main questions is where and how to attach these
> virtual input devices.  It is still unclear how to attach
> a tab bar (a useful virtual input device still unsupported
> by Emacs unlike tool bars and menu bars) to the Emacs frame.
> Last year Jan looked how to do this in GTK and concluded
> this is not straightforward.  Maybe newer GTK versions provide
> an easier way.


There is no good reason or need to use GTK's "native"
tab bars.

As you note: tab bars are a simple enough graphical presentation
that they  can be implemented using plain text, given just 
some suitable "symbol fonts".   Emacs could have tab bars that
work the same and look very similar across all graphical 
toolkits and on ordinary text terminals.   They won't look
like "native" tab bars to the fans of any particular GUI
toolkit but, with care in providing a custom symbol font, 
they can look quite nice.


> > 2) We don't have to slavishly follow Eclipse or another
> > program to determine our list of virtual input devices.
> > When we pick virtual input device types and their behavior,
> > whenever possible, virtual input devices that make some sense
> > on plain-text smart terminals are extra nifty to have.

> We could implement tab bars on plain-text terminals exactly as
> a menu bar line is implemented at the top on the terminal window.

Yes.



> > Given Emacs' huge command set, I'd really like to see a
> > virtual input device that resembled, say, the command menu
> > system of old PC programs like Lotus whatsit or any of the
> > spreadsheet programs.   This also resembles the command
> > menu interfaces of some HP calculators, as I recall.  Basically,
> > a narrow area for listing a thin menu of commands but with a 
> > "tree structure" so you can dig down to sub-commands or pop 
> > back up to parent menus.   With a "home" or "clear" command for
> > getting back to the root of the command tree.
> 
> Yes, I remember that in Lotus 1-2-3 the slash key activated
> a keyboard-driven menu.  Since in Emacs keymaps and menus
> have the same structure it is easy to do the same in Emacs.

Yup.

I like the idea of making these command menus generate
a new kind of event like [CMD-MENU FIND-FILE].  Maybe 
there can be special rules for how to fall back in case
there is no CMD-MENU binding.

-t

RE: Infrastructural complexity.

[Drew Adams]

> > Yes, I remember that in Lotus 1-2-3 the slash key activated
> > a keyboard-driven menu.  Since in Emacs keymaps and menus
> > have the same structure it is easy to do the same in Emacs.
> 
> Yup.

Just bind `/' to `lacarte-execute-menu-command'.

(But I use `f10' as in `tmm', since I use `/' for other things. ;-)

Re: Infrastructural complexity.

[Mathias Dahl]

> Given Emacs' huge command set, I'd really like to see a
> virtual input device that resembled, say, the command menu
> system of old PC programs like Lotus whatsit or any of the
> spreadsheet programs.   This also resembles the command
> menu interfaces of some HP calculators, as I recall.  Basically,
> a narrow area for listing a thin menu of commands but with a
> "tree structure" so you can dig down to sub-commands or pop
> back up to parent menus.   With a "home" or "clear" command for
> getting back to the root of the command tree.

That sounds very similar to M-x tmm-menubar. It seems to lack a
feature to back up though.

/Mathias

Re: Infrastructural complexity.

[Thomas Lord]

On Sun, 2009-07-19 at 23:56 +0200, Mathias Dahl wrote:
> > Given Emacs' huge command set, I'd really like to see a
> > virtual input device that resembled, say, the command menu
> > system of old PC programs like Lotus whatsit or any of the
> > spreadsheet programs.   This also resembles the command
> > menu interfaces of some HP calculators, as I recall.  Basically,
> > a narrow area for listing a thin menu of commands but with a
> > "tree structure" so you can dig down to sub-commands or pop
> > back up to parent menus.   With a "home" or "clear" command for
> > getting back to the root of the command tree.
> 
> That sounds very similar to M-x tmm-menubar. It seems to lack a
> feature to back up though.

A big difference is that a tmm-menubar menu is a 
buffer.  A "virtual input device" of the same idea
is not a buffer but is conceptually a "feature of the
terminal being used for display".  It's more like the 
(remotely) programmable function keys on some real-world
physical terminals.  

Choosing an item off of a virtual input device 
hierarchical menu should produce a synthetic 
input event, such as [CMD-MENU FIND-FILE].

That would not directly call "find-file" it would
go through the usual keymap process to find the 
binding for [CMD-MENU FIND-FILE].

For example, suppose I type C-h k

Next, I pick a menu item off of the command menu.

I should see the doc string for the command
that would be invoked had I not typed C-h k first.

In tmm-mode, instead, I get the documentation 
string for "tmm-shortcut".

Menu bars are an example of a virtual input/output device.
Scrollbars are examples of virtual input/output devices.
So are mode lines.   A little hierarchical command menu
could be the same sort of thing.  A very slight generalization
would allow lisp programs to specify both plain text and an 
icon for each menu item.  With that, we have in one subsystem
both toolbars, as in modern guis, and text based command menus
as in those ancient PC programs.

-t

RE: Infrastructural complexity.

[Drew Adams]

> Choosing an item off of a virtual input device 
> hierarchical menu should produce a synthetic 
> input event, such as [CMD-MENU FIND-FILE].
> 
> That would not directly call "find-file" it would
> go through the usual keymap process to find the 
> binding for [CMD-MENU FIND-FILE].

LaCarte does go through the menu structure to look up a command. (It does not,
however, produce a pseudo input event.)

> For example, suppose I type C-h k
> Next, I pick a menu item off of the command menu.
> I should see the doc string for the command
> that would be invoked had I not typed C-h k first.
> 
> In tmm-mode, instead, I get the documentation 
> string for "tmm-shortcut".

FWIW -

Icicles does that (again, though, not in the same way). You can complete key
sequences, including menu-bar menus. And you can see the doc for each completion
candidate (menu item or submenu).

You see the first doc-string line automatically (in the mode line of
*Completions*) if you cycle among candidates. And you can see the full doc
string for any candidates on demand.

> Menu bars are an example of a virtual input/output device.
> Scrollbars are examples of virtual input/output devices.
> So are mode lines.   A little hierarchical command menu
> could be the same sort of thing.

So, I would think, is the minibuffer. (I'm just following your examples. I
didn't see any definition of virtual i/o device, so I might be mistaken.)

> A very slight generalization
> would allow lisp programs to specify both plain text and an 
> icon for each menu item.  With that, we have in one subsystem
> both toolbars, as in modern guis, and text based command menus
> as in those ancient PC programs.

Yes, icons in some menus (with or as replacement of text) could perhaps
sometimes be useful.  Similarly, for other kinds of completion candidates: file
types, for instance, for file-name candidates.

With Icicles, you can add icons to text candidates (including menu items) or use
them instead of text: just add an image using s `display' property for the
menu-item candidate. But I have never done so. (I haven't tried to use Emacs
with images. Seems like too much trouble on Windows.)

RE: Infrastructural complexity.

[Thomas Lord]

On Sun, 2009-07-19 at 16:54 -0700, Drew Adams wrote:

> > Menu bars are an example of a virtual input/output device.
> > Scrollbars are examples of virtual input/output devices.
> > So are mode lines.   A little hierarchical command menu
> > could be the same sort of thing.
> 
> So, I would think, is the minibuffer. (I'm just following your examples. I
> didn't see any definition of virtual i/o device, so I might be mistaken.)

I guess you could say, the way I'm using the phrase,
that the minibuffer area - and each Emacs window - are
virtual i/o devices.  Minibuffer buffers and regular 
buffers are not virtual i/o devices but they are parameters
to some virtual i/o devices (e.g., the parameter of what 
buffer should be displayed in a window or the minibuffer
area).

The minibuffer area, each window, the menu bar, etc.
are all features of the display and I/O system that 
exist to show constantly-updated views on some object
and to translate system input events into various kinds
of command loop input events (e.g., a mouse action into 
a MENU event).

It (the concept of a virtual i/o device) is just supposed
to be a handy way of thinking about the core architecture
of Emacs.  If the concept fails to work that way for you,
don't get hung up on it - I'm sure there are other good ways
of thinking about the same architectural details.

-t

Re: Infrastructural complexity.

[Lennart Borgman]

On Mon, Jul 20, 2009 at 12:21 AM, Thomas Lord<lord@emf.net> wrote:

>> That sounds very similar to M-x tmm-menubar. It seems to lack a
>> feature to back up though.

Sounds like a bug.


> A big difference is that a tmm-menubar menu is a
> buffer.  A "virtual input device" of the same idea
> is not a buffer

Why not? Couldn't there be several "virtual input devices?".

Of course, a virtual input device corresponding to the default dito on
the platform is very important.


> Choosing an item off of a virtual input device
> hierarchical menu should produce a synthetic
> input event, such as [CMD-MENU FIND-FILE].
>
> That would not directly call "find-file" it would
> go through the usual keymap process to find the
> binding for [CMD-MENU FIND-FILE].

Can't that kind of abstraction be reach on different routes? For
example could tmm look for a flag from C-h k (and other things, of
course) telling it what to do at the end.

I do not think the abstraction is impossible in the current Emacs
structure. But there could surely be a general mechanism for this.
This could just consist of:

- Setting a flag at "virtual input device" start tellinng it how to
treat input in the end.
- And of course the "virtual input device" should check that at the end...
- ... and more... the help function must understand this structure...


> For example, suppose I type C-h k
>
> Next, I pick a menu item off of the command menu.
>
> I should see the doc string for the command
> that would be invoked had I not typed C-h k first.
>
> In tmm-mode, instead, I get the documentation
> string for "tmm-shortcut".

Re: Infrastructural complexity.

[Thomas Lord]

On Mon, 2009-07-20 at 01:58 +0200, Lennart Borgman wrote:
> On Mon, Jul 20, 2009 at 12:21 AM, Thomas Lord<lord@emf.net> wrote:

> >> That sounds very similar to M-x tmm-menubar. It seems to lack a
> >> feature to back up though.

> Sounds like a bug.

> > A big difference is that a tmm-menubar menu is a
> > buffer.  A "virtual input device" of the same idea
> > is not a buffer

> Why not? Couldn't there be several "virtual input devices?".


There are.  Hmm.   This isn't complicated but I seem
to have caused confusion - my bad and let me try to fix
it.

Emacs windows, menu bars, menu bars, the minibuffer
area - all of these things are "virtual i/o devices".
Each corresponds very directly to a set of pixels on
the screen.  Each implies its own set of rules for translating
associated window system input events into command loop
events.

Buffers, on the other hand, are abstract things (and,
obviously a core abstraction for what Emacs does).  Multiple
windows (virtual i/o devices) can be set so that they are
displaying the same buffer.  The window is the virtual i/o 
device, the buffer is like a "model" to that "view". 

So my suggestion about a hierarchical command menus is
to make a new kind of virtual i/o device.  There are windows
and menu bars and mode lines -- and this suggestion is to 
add, parallel to those, command menu areas.

Windows are virtual i/o devices that happen to display
buffers.  So, one notion is: shouldn't a command menu area
just be a window?  The command menu could then be defined
as the contents of a buffer.

And, I'm suggesting, no, windows aren't quite right
for that.  Windows are far more general than the use
case of a command menu calls for.  User's can kill the 
buffer underlying a window but they shouldn't be able to
kill the data a command menu displays the same way, for 
example.

Menu bars are an example of a virtual i/o device that
displays keymap data, not buffer data, and that treats input
differently from inputs to a buffer window.  I'm suggesting
that command menus should be more like that.

There are four, popular, commonly implemented, and nifty
UI elements:  menus, toolbars, "command menus" like those
old PC programs, and, now that I think about it, tabs.

All of those have in common that the user would use
them to generate command loop events: [MENU foo], [CMD-MENU bar],
[TAB xyzzy], and so forth.   Three of them, menus, tool bars,
and those hierarchical command menus are essentially displaying
keymaps.  Mode lines display various buffer variables, suitably
interpreted.   These can (usefully) all be unified as a single
abstraction with a few parameters that control their differences.





> Of course, a virtual input device corresponding to the default dito on
> the platform is very important.

"dito"?


> > Choosing an item off of a virtual input device
> > hierarchical menu should produce a synthetic
> > input event, such as [CMD-MENU FIND-FILE].
> >
> > That would not directly call "find-file" it would
> > go through the usual keymap process to find the
> > binding for [CMD-MENU FIND-FILE].
> 
> Can't that kind of abstraction be reach on different routes? For
> example could tmm look for a flag from C-h k (and other things, of
> course) telling it what to do at the end.

Well, that's kind of messy.  For example, in a tmm menu now
you say C-h k f because the menu says "f" is something about
files.  The legacy, and perfectly sufficient command loop logic
and keymap logic leads you to the doc string for tmm-shortcut,
not the the thing you are looking for.

You are really talking about mucking with that that command
loop and keymap logic which is not something to do for such
an ad hoc purpose.  It's too central to the architecture.



> I do not think the abstraction is impossible in the current Emacs
> structure. But there could surely be a general mechanism for this.
> This could just consist of:
> 
> - Setting a flag at "virtual input device" start tellinng it how to
> treat input in the end.
> - And of course the "virtual input device" should check that at the end...
> - ... and more... the help function must understand this structure...
> 


Ok, why aren't keymaps buffers?

If keymaps were buffers than menu bars would
be windows, rather than something distinct from
windows.

I imagine one could make an Emacs-like program in
which menu bars are windows and keymaps are buffers.
That's a radical architectural change from what 
GNU Emacs is, however.

-t

RE: Infrastructural complexity.

[Drew Adams]

> > Basically,
> > a narrow area for listing a thin menu of commands but with a
> > "tree structure" so you can dig down to sub-commands or pop
> > back up to parent menus.   With a "home" or "clear" command for
> > getting back to the root of the command tree.
> 
> That sounds very similar to M-x tmm-menubar. It seems to lack a
> feature to back up though.

I think you're right, but LaCarte does let you back up.

LaCarte uses normal Emacs completion. Just remove text from the right to back
up, just as you do when navigating the file hierarchy using file-name
completion.

LaCarte could be added to Emacs, as a replacement or as an alternative to tmm.
Or similar code could be written for Emacs from scratch. The point is that
completion is a handy way to explore a hierarchy (down, up, sideways).

http://www.emacswiki.org/emacs/LaCarte

(You do not need Icicles to use LaCarte. The page mentions Icicles because
completion that is not just prefix completion enhances how you can navigate the
menu tree/forest.)

Re: Infrastructural complexity.

[Lennart Borgman]

On Sun, Jul 19, 2009 at 8:23 PM, Juri Linkov<juri@jurta.org> wrote:
>> Why should they need menu bars and tool bars etc? I think they would
>> be useful without it.
>
> Have you seen Eclipse screenshots?  Eclipse and other IDE framelets have
> tool bars and tab bars.


Hm, thanks, you are right. It uses tab bars and tool bars. However I
do not believe menus are allowed in child windows on w32 (at least it
was not that before).

Re: Infrastructural complexity.

[Richard Stallman]

    I guess the difference is in frame parameters.  If framelets are
    Emacs frames inside the main Emacs frame, then they should have
    their own menu bars, tool bars, tab bars.

Are those the only parameters that might vary?
What about at the Lisp level?
At the keyboard command level?

Re: Infrastructural complexity.

[Thomas Lord]

On Sat, 2009-07-18 at 13:11 -0400, Richard Stallman wrote:
> A "windowgroup" is similar to an Emacs frame, inside another emacs
>     frame. I like this better than using several Emacs frames.
> 
> It might be a subtle question.  To think about it, I suggest looking
> at by asking: What is the difference between a windowgroup and a
> framelet?  Or what are the various differences?
> 
> With a list of these differences, it might be possible to see a number
> of different design options and what is better or worse about them.

It is hard to be objective because it is an
apples and oranges comparison.  I won't pretend 
to be but I'll try to not be unfair.

One difference is that the window groups proposal
changes the behavior of windows by quite a lot.
I have trouble (perhaps its just me) thinking 
through all the implications of what, for example,
the changes proposed for "split-window" imply.

On the other hand, framelets changes the rules for 
frame handling just a little.  They seem far easier
to think through, to me.

Window groups includes new rules for "split-window" that are
hard to wrap one's head around.  It's clear (sorta)
that the new rules can be used to achieve the desired
IDE-style features but it isn't clear what else the
new rules imply.   I get pretty confused just reading the
window groups proposal.

Framelets says that you can have five frames in a window
system window plus any pop-ups or tear-off menu frames
associated with that window.    One of the five frames in
a window is the "parent" frame to all the others - the main
edit area.   Four of the five frames are laid out along the
periphery of that main edit area (there are 16 ways to do
so) - and they are for "control panel" interfaces that are
common in contemporary GUIs.  Finally, you can create free-floating
child frames like "tear off menus" that are common in GUIs.

Not a lot of details of how frames work change.  A framelet
mostly works just like a frame does today.   Some differences
are that if a parent frame is hidden or destroyed, it's child
frames go with it;  new code can ask "does my selected-frame
have a parent and if so, what is it?".  The window subsystem
of Emacs is unchanged.

Framelets seem a much cleaner and simpler and less restrictive
in future work yet solve the IDE goals of the present.

One large difference, though, is that framelets really require
more changes to the C code of Emacs while window groups can
get away with little or 0 changes to the C code.  From some of the
conversation, I suspect that this is one of the big reasons that
there is support for window groups.  I sympathize with that
but I think that the proposed complexity in core lisp code
is sufficiently problematic that it's at the very least not
an obviously good idea to go with window groups.


-t

Re: Infrastructural complexity.

[Lennart Borgman]

On Sun, Jul 19, 2009 at 3:14 AM, Thomas Lord<lord@emf.net> wrote:
>
> One large difference, though, is that framelets really require
> more changes to the C code of Emacs while window groups can
> get away with little or 0 changes to the C code.  From some of the
> conversation, I suspect that this is one of the big reasons that
> there is support for window groups.  I sympathize with that
> but I think that the proposed complexity in core lisp code
> is sufficiently problematic that it's at the very least not
> an obviously good idea to go with window groups.


Just a note of clarification. The idea of framelets was yours, but I
adopted the term and use it a bit differently.

I am unfortunately unable to understand the details of your
suggestion. By that I do not want to say it is good, I am just not
sure I understand it.

You restrict it to four framelettes in a frame. I am guessing that
this is because this will be easy to recognize, but I am not sure.

My suggestion is that any window could act as a kind of framelet. This
means basically that

- Windows inside it forms a window group.
- Frame-related commands (C-x 1, etc) commands work inside the framelet.
- It should visually clear that it is a framelet.

From Martins reply it seems clear that my view of a framelet is the
same as what he calls a window group.

Re: Infrastructural complexity.

[Thomas Lord]

Ok, so - in light of Lennart's stated 
uncertainty about exactly what the framelet
proposal is I figure it's useful to collect
the results of earlier discussion and
restate the framelet proposal so we have something
at least a little more concrete to work from
in this discussion.

I can't make the framelet proposal perfectly
concrete, by far.  "Perfectly concrete" would
be patches.  One big difference between the
window group proposal and framelets is that
the window group proposal has patches, more or
less.  So, I agree with anyone who says that that
is a relative weakness of the framelet proposal.

So, the proposal.  I'll present it in a 
narrative style, mixing rationales and 
introductions of concepts with proposed technical
details:

-----------------

The popular IDE(s), word processors, image editors,
etc. all use window systems windows in a nice way.
They have a main edit area "in the middle" with 
control panels along the side.   They also have 
persistent pop-up windows like "tear off menus"
and so forth -- all of which are conceptually 
subordinate to that main edit area.   The control 
panels and pop-ups can be used as specialized click-and-point
interfaces to various commands operating on the edit area,
or as "message" windows about stuff going on in the 
main edit area.

The framelet proposal for Emacs is a proposal to 
very directly model the interface style of those apps.

Given a window system window, Emacs currently says
"there is one frame in that window."  The framelet
proposal says that, no, there are five frames in that
window, four of which are "framelets".

Draw (in your imagination or on paper) a 
largish rectangle. Call that a window system window.

In the middle, draw a smaller rectangle. Call
that smaller rectangle the "main edit area".  

Now, the main edit area rectangle has four vertexes.
At each vertex, you can extend a horizontal or vertical 
line from a side of the inner rectangle to an edge of the 
outer rectangle.  (Picture the outer rectangle as containing
a tic-tac-toe grid.)

Now, imagine that you have to erase one line from 
each vertex of the inner box of the tic-tack-toe grid
to the outer rectangle.

You'll be left with four rectangles surrounding an 
inner rectangle.  The outer four are the "control panel
areas" and the inner rectangle is the main edit
area.  There are sixteen possible choices of which 
combinations of line segment to erase.  (Draw the
picture, puzzle it out.)

Now, in Emacs terms, all five of those rectangles
are frames.  In new terms, under this proposal, 
four of them are "framelet(tes)".  The one in the
middle is the ordinary frame - call it a "parent 
frame".  The other four around the side are framelets.
Framelets have a parent and the parent of these four
is the main edit area - the parent frame.

Framelets on either side can have a width of 0.
Framelets top or bottom can have a he1ight of 0.
In those cases, the corresponding frame is hiden
and not selected by ordinary frame traversal commands.
One way to set the width or height to 0 is to set
the window configuration of the framelet to nil.

Additionally, there can be framelets which are, on 
window systems, separate windows - free floating but
still with some other main edit area frame as parent.
They hide or are killed when the parent is.  They
are used for "tear-offs" and such.

So we have new functions like:

FRAMELET-P
FRAMELET-POSITION  ; returns N, S, E, W, or FLOATING
FRAMELET-PARENT    ; nil or a parent frame

And that's about it.  Lots can be built on top of this,
of course.  Interfaces very similar to Eclipse or Open Office
can be built on this.

What further details are unclear to people?

-t

16 (Re: Infrastructural complexity.)

[Thomas Lord]

_______         
|_|_|_|    template
|_|_|_|         
|_|_|_|
                
                
Enlarged:



  _______________________________
  |         |         |         |
  |         |         |         |
  |  ~~~control~~~panel~~~area  |
  |         |         |         |
  |_________|_________|_________|
  |         | main    |         |
  |   ~~    | edit    |   ~~    |
  |         | area    |         |
  |         |         |         |
  |_________|_________|_________|
  |         |         |         |
  |         |         |         |
  |  ~~~control~~~panel~~~area  |
  |         |         |         |
  |_________|_________|_________|



16 possible layouts of control
panel frames:

_______
|_____|    NNSS  0
|_|_|_|        
|_____|                                                    
               
               
_______
|_____|    NNSs  1
|_|_| |            
|___|_|            
                   
                   
_______            
|_____|    NNsS   2
| |_|_|
|_|___|
      
                
_______         
|_____|    NNss   3 
| |_| |         
|_|_|_|         
                
                
_______         
|___| |    NnSS   4
|_|_|_|         
|_____|         
                
                
_______         
|___| |    NnSs   5
|_|_| |         
|___|_|         
                
                
_______         
|___| |    NnsS   6
| |_|_|         
|_|___|         
                
                
_______         
|___| |    Nnss   7
| |_| |         
|_|_|_|
                
                
_______         
| |___|    nNSS   8
|_|_|_|         
|_____|
                
                
_______         
| |___|    nNSs   9 
|_|_| |         
|___|_|
                
                
_______         
| |___|    nNsS   10
| |_|_|         
|_|___|
                
                
_______         
| |___|    nNss   11
| |_| |         
|_|_|_|
                
                
_______         
| |_| |    nnSS   12 
|_|_|_|         
|_____|
                
                
_______         
| |_| |    nnSs    13
|_|_| |         
|___|_|
                
                
_______         
| |_| |    nnsS    14
| |_|_|         
|_|___|
                
                
_______         
| |_| |    nnss    15
| |_| |         
|_|_|_|        
                

-t

Re: 16 (Re: Infrastructural complexity.)

[Thomas Lord]

An example of the effect of "nil" window
configurations for various control panel
frames, using the control panel frame
layout "nNss (11)".



_______
| |___|    nNss   11
| |_| |
|_|_|_|


_______
|     |    nNss   11   ; 11.0
|     |    NSEW   0
|_____|


_______
| |   |    nNss   11   ; 11.1
| |   |    NSEw   1
|_|___|


_______
|   | |    nNss   11   ; 11.2
|   | |    NSeW   2
|___|_|


_______
| | | |    nNss   11   ; 11.3
| | | |    NSew   3
|_|_|_|


_______
|     |    nNss   11   ; 11.4
|_____|    NsEW   4
|_____|


_______
| |   |    nNss   11   ; 11.5
| |___|    NsEw   5
|_|___|


_______
|   | |    nNss   11   ; 11.6
|___| |    NseW   6
|___|_|


_______
| | | |    nNss   11   ; 11.7
| |_| |    Nsew   7
|_|_|_|


_______
|_____|    nNss   11   ; 11.8
|     |    nSEW   8
|_____|


_______
|_____|    nNss   11   ; 11.9
|   | |    nSEw   9
|___|_|


_______
| |___|    nNss   11   ; 11.10
| |   |    nSeW   10
|_|___|


_______
| |___|    nNss   11   ; 11.11
| | | |    nSew   11
|_|_|_|


_______
|_____|    nNss   11   ; 11.12
|_____|    nsEW   12
|_____|


_______
| |___|    nNss   11   ; 11.13
| |___|    nsEw   13
|_|___|


_______
|_____|    nNss   11   ; 11.14
|___| |    nseW   14
|___|_|


_______
| |___|    nNss   11   ; 11.15 == 11
| |_| |    nesw   15
|_|_|_|



-t

Re: 16 (Re: Infrastructural complexity.)

[Thomas Lord]

[Last obscure post in this round.]


If you want to get fancy, then looking
at the template:


_______
|_|_|_|    template
|_|_|_|
|_|_|_|



You could say that there are 8 control panel
frames around the main edit frame rather than
just four.  The combinatorics expressed by the
NSSS/NSEW notation have to be replaced with
something slightly more complex but its still
a simple boolean logic structure.

And, while in the description so far I've 
insisted on not nesting frames more than one
layer deep really, you could have a kind 
"theory of relativity" in which each of peripheral
"control panel" frames had it's own surrounding set 
of 8 subordinate frames -- all "frames of 
reference" (pun intended) look the same in that regard.
That gives you nested pie menus as a unifying metaphor.

A numeric keypad makes for a fine navigational
tool for an "every frame is surrounded by eight
control panels" system.  If mouse driven, it's
basically a "pie menu" configuration.

"You are not expected to understand this [most of
you, anyway]." -- early unix kernel silliness.
-t

Re: 16 (Re: Infrastructural complexity.)

[Lennart Borgman]

On Mon, Jul 20, 2009 at 7:45 AM, Thomas Lord<lord@emf.net> wrote:
> _______
>  _______________________________
>  |         |         |         |
>  |         |         |         |
>  |  ~~~control~~~panel~~~area  |
>  |         |         |         |
>  |_________|_________|_________|
>  |         | main    |         |
>  |   ~~    | edit    |   ~~    |
>  |         | area    |         |
>  |         |         |         |
>  |_________|_________|_________|
>  |         |         |         |
>  |         |         |         |
>  |  ~~~control~~~panel~~~area  |
>  |         |         |         |
>  |_________|_________|_________|
>
>
>
> 16 possible layouts of control
> panel frames:
>
> _______
> |_____|    NNSS  0
> |_|_|_|
> |_____|
>
>
> _______
> |_____|    NNSs  1
> |_|_| |
> |___|_|


Thanks, that made it easier to think about it.

It looks like a good approximation for text terminals and the current
Emacs GUI where we do not have floating child frames. (In OS level
terms it is child windows, of course). And it looks like an idea to
level ECB things to a more general level.


Is your goal making this a user-level changeable layout framework
(within these 16 layouts)? Logically it seems pretty easy with
functions like:

- left-panel-enlarge-upwards
- left-panel-enlarge-downwards
etc.

- hide-left-panel
- show-left-panel
etc.

- (swap-panels 'left 'top)

This seems to be easy to implement on the elisp level, but I do not
know how easy it is for a user to grasp the idea.

Re: 16 (Re: Infrastructural complexity.)

[Thomas Lord]

On Mon, 2009-07-20 at 08:47 +0200, Lennart Borgman wrote:
> On Mon, Jul 20, 2009 at 7:45 AM, Thomas Lord<lord@emf.net> wrote:
> > _______
> >  _______________________________
> >  |         |         |         |
> >  |         |         |         |
> >  |  ~~~control~~~panel~~~area  |
> >  |         |         |         |
> >  |_________|_________|_________|
> >  |         | main    |         |
> >  |   ~~    | edit    |   ~~    |
> >  |         | area    |         |
> >  |         |         |         |
> >  |_________|_________|_________|
> >  |         |         |         |
> >  |         |         |         |
> >  |  ~~~control~~~panel~~~area  |
> >  |         |         |         |
> >  |_________|_________|_________|
> >
> >
> >
> > 16 possible layouts of control
> > panel frames:
> >
> > _______
> > |_____|    NNSS  0
> > |_|_|_|
> > |_____|
> >
> >
> > _______
> > |_____|    NNSs  1
> > |_|_| |
> > |___|_|
> 
> 
> Thanks, that made it easier to think about it.


It took me a few days to come up with 
the NNSS notation.  I knew there had to be
a good notation but it was a little bit hard
to find one.  I'm glad it paid off.



> It looks like a good approximation for text terminals and the current
> Emacs GUI where we do not have floating child frames. (In OS level
> terms it is child windows, of course). And it looks like an idea to
> level ECB things to a more general level.


Let's talk about floating child frames separately,
a little later.

> Is your goal making this a user-level changeable layout framework
> (within these 16 layouts)? Logically it seems pretty easy with
> functions like:
> 
> - left-panel-enlarge-upwards
> - left-panel-enlarge-downwards
> etc.
> 
> - hide-left-panel
> - show-left-panel
> etc.


I was just pacing the floor thinking roughly
the same.  Yeah, in most cases, users get control
over those 8 bits of params.

> - (swap-panels 'left 'top)

> This seems to be easy to implement on the elisp level,

I don't see how, c.f. Miles' comments recently.  I mean,
you need some C-level hackery to have the "five frames
in one systems window, configurable by those eight bits"
but then, sure, you can make all the behaviour of that nice
by hacking at the elisp level.

>  but I do not
> know how easy it is for a user to grasp the idea.
> 

It's such a nice simple little, almost "physical"
abstraction.  It's visceral.  I take my inspiration
from things like HP calculators and visicalc.  My
(subjective) instinct is that users will love it although
many will need a little bit of a tutorial to grok it.
(FWIW)

-t

Re: 16 (Re: Infrastructural complexity.)

[Lennart Borgman]

On Mon, Jul 20, 2009 at 9:28 AM, Thomas Lord<lord@emf.net> wrote:
> On Mon, 2009-07-20 at 08:47 +0200, Lennart Borgman wrote:
>> On Mon, Jul 20, 2009 at 7:45 AM, Thomas Lord<lord@emf.net> wrote:
>> > _______
>> >  _______________________________
>> >  |         |         |         |
>> >  |         |         |         |
>> >  |  ~~~control~~~panel~~~area  |
>> >  |         |         |         |
>> >  |_________|_________|_________|
>> >  |         | main    |         |
>> >  |   ~~    | edit    |   ~~    |
>> >  |         | area    |         |
>> >  |         |         |         |
>> >  |_________|_________|_________|
>> >  |         |         |         |
>> >  |         |         |         |
>> >  |  ~~~control~~~panel~~~area  |
>> >  |         |         |         |
>> >  |_________|_________|_________|

>
>> This seems to be easy to implement on the elisp level,
>
> I don't see how, c.f. Miles' comments recently.  I mean,
> you need some C-level hackery to have the "five frames
> in one systems window, configurable by those eight bits"
> but then, sure, you can make all the behaviour of that nice
> by hacking at the elisp level.


I mean the layout, not tool bars, tab bars etc. (Forgot exactly what
Miles meant.)

And I do not think of the 4 panels in this layout as panel windows. I
think of them as panel CONTAINERS for panel windows.

Re: 16 (Re: Infrastructural complexity.)

[Thomas Lord]

I've lost you a little bit there because 
your calling the four panels "containers".
I call them "frames".

-t



On Mon, 2009-07-20 at 09:34 +0200, Lennart Borgman wrote:
> On Mon, Jul 20, 2009 at 9:28 AM, Thomas Lord<lord@emf.net> wrote:
> > On Mon, 2009-07-20 at 08:47 +0200, Lennart Borgman wrote:
> >> On Mon, Jul 20, 2009 at 7:45 AM, Thomas Lord<lord@emf.net> wrote:
> >> > _______
> >> >  _______________________________
> >> >  |         |         |         |
> >> >  |         |         |         |
> >> >  |  ~~~control~~~panel~~~area  |
> >> >  |         |         |         |
> >> >  |_________|_________|_________|
> >> >  |         | main    |         |
> >> >  |   ~~    | edit    |   ~~    |
> >> >  |         | area    |         |
> >> >  |         |         |         |
> >> >  |_________|_________|_________|
> >> >  |         |         |         |
> >> >  |         |         |         |
> >> >  |  ~~~control~~~panel~~~area  |
> >> >  |         |         |         |
> >> >  |_________|_________|_________|
> 
> >
> >> This seems to be easy to implement on the elisp level,
> >
> > I don't see how, c.f. Miles' comments recently.  I mean,
> > you need some C-level hackery to have the "five frames
> > in one systems window, configurable by those eight bits"
> > but then, sure, you can make all the behaviour of that nice
> > by hacking at the elisp level.
> 
> 
> I mean the layout, not tool bars, tab bars etc. (Forgot exactly what
> Miles meant.)
> 
> And I do not think of the 4 panels in this layout as panel windows. I
> think of them as panel CONTAINERS for panel windows.
> 
> 

Re: Infrastructural complexity.

[martin rudalics]

 > One large difference, though, is that framelets really require
 > more changes to the C code of Emacs while window groups can
 > get away with little or 0 changes to the C code.  From some of the
 > conversation, I suspect that this is one of the big reasons that
 > there is support for window groups.  I sympathize with that
 > but I think that the proposed complexity in core lisp code
 > is sufficiently problematic that it's at the very least not
 > an obviously good idea to go with window groups.

I'm afraid that window groups won't get away with little or 0 changes to
the C code.  OTOH, framelets could get away with hardly any changes to C
code.  Speedbar has its separate frame, initially attached to some
existing frame, can be torn off and moved around.  There's no reason why
we can't additionally build around an existing Emacs frame a message
frame, a log frame, a tools frame.  All these would come (optionally)
with their own tool bar, menu bar, tabs, mode-/header-line and could be
handled by the window manager of your choice.  The display code might
need some additional means to handle zero sized frames or windows, but
that's all IMHO.

Personally, I prefer to always stay within one and the same frame and
therefore never use the speedbar.  So in practice I probably would never
work with code based on distinct frames.  Maybe also, converting
existing ECB code by substituting windows with say root-windows of
frames might be difficult but likely no more than making it work with
window groups.

martin

Re: Infrastructural complexity.

[joakim]

martin rudalics <rudalics@gmx.at> writes:

>> One large difference, though, is that framelets really require
>> more changes to the C code of Emacs while window groups can
>> get away with little or 0 changes to the C code.  From some of the
>> conversation, I suspect that this is one of the big reasons that
>> there is support for window groups.  I sympathize with that
>> but I think that the proposed complexity in core lisp code
>> is sufficiently problematic that it's at the very least not
>> an obviously good idea to go with window groups.
>
> I'm afraid that window groups won't get away with little or 0 changes to
> the C code.  OTOH, framelets could get away with hardly any changes to C

Yes, the current Window Groups patch touches nearly only C code.

> code.  Speedbar has its separate frame, initially attached to some
> existing frame, can be torn off and moved around.  There's no reason why
> we can't additionally build around an existing Emacs frame a message
> frame, a log frame, a tools frame.  All these would come (optionally)
> with their own tool bar, menu bar, tabs, mode-/header-line and could be
> handled by the window manager of your choice.  The display code might
> need some additional means to handle zero sized frames or windows, but
> that's all IMHO.
> Personally, I prefer to always stay within one and the same frame and
> therefore never use the speedbar.  So in practice I probably would never
> work with code based on distinct frames.  Maybe also, converting
> existing ECB code by substituting windows with say root-windows of
> frames might be difficult but likely no more than making it work with
> window groups.

I also prefer to work with only 1 frame. ECB has code to make the
Speedbar live in an Emacs window, which makes Speedbar very nice for me.


> martin
-- 
Joakim Verona

Re: Infrastructural complexity.

[Miles Bader]

martin rudalics <rudalics@gmx.at> writes:
> I'm afraid that window groups won't get away with little or 0 changes to
> the C code.  OTOH, framelets could get away with hardly any changes to C
> code.

Eh?  How?!  ... unless you're suggesting  using separate real frames (i.e., window-manager
windows), but that seems a quick path to misery.

I thought the whole point of these window-groups / framelets (hate the
name, but anyway the concept) was to keep these auxiliary thingies
inside a single frame (window-manager window), so emacs has some hope of
keeping control over their placement.  That AFAICS, requires changes to
the C code...

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Infrastructural complexity.

[martin rudalics]

 >> I'm afraid that window groups won't get away with little or 0 changes to
 >> the C code.  OTOH, framelets could get away with hardly any changes to C
 >> code.
 >
 > Eh?  How?!  ... unless you're suggesting  using separate real frames (i.e., window-manager
 > windows), but that seems a quick path to misery.

If people want frame-like behavior (i.e., have toolbars, menubars,
tear-off "windows"), then IMHO the easiest way to implement that is
using "real frames".  But please don't misread my opinion as "suggestion".

 > I thought the whole point of these window-groups / framelets (hate the
 > name, but anyway the concept) was to keep these auxiliary thingies
 > inside a single frame (window-manager window), so emacs has some hope of
 > keeping control over their placement.  That AFAICS, requires changes to
 > the C code...

A point of my proposal was to the keep the "auxiliary thingies inside a
single frame" and to change the C code.  OTOH I believe that
implementing framelets via separate frames would still give Emacs "some
hope of keeping control over their placement" (just as Emacs is able to
control placement of the Speedbar).

martin

Re: Infrastructural complexity.

[Miles Bader]

martin rudalics <rudalics@gmx.at> writes:
> A point of my proposal was to the keep the "auxiliary thingies inside a
> single frame" and to change the C code.  OTOH I believe that
> implementing framelets via separate frames would still give Emacs "some
> hope of keeping control over their placement" (just as Emacs is able to
> control placement of the Speedbar).

Emacs is miserable at  controlling placement of the speedbar.

Once you start letting the WM have any control all bets are off --
remember, it's _not_ just initial placement, but movement, sizing
[think: tiling WM!], additional WM-added frames, dealing with the many,
many, differences between WMs on different platforms, etc.

This approach seems a complete non-starter to me, unless we have control
over the WM as well (and we don't)...

-Miles

-- 
Consult, v.i. To seek another's disapproval of a course already decided on.

Re: Infrastructural complexity.

[martin rudalics]

 > Once you start letting the WM have any control all bets are off --
 > remember, it's _not_ just initial placement, but movement, sizing
 > [think: tiling WM!], additional WM-added frames, dealing with the many,
 > many, differences between WMs on different platforms, etc.

The user is supposed to control the WM and tiling WMs should manage
multiple Emacs frames better than Emacs itself is able to tile a frame
into multiple windows.  After all that's what tiling WMs are supposed to
do well.

 > This approach seems a complete non-starter to me, unless we have control
 > over the WM as well (and we don't)...

... hopefully we don't since otherwise we could never blame the WM for
not being able to handle our frames ;-)

Anway, converting windows to frames in order to tear them off and back
to windows when docking them back seems hardly feasible to me.  Not to
think of multiple (un-)wrapping menu- or toolbars somewhere in the
middle of a frame just because the user decided to resize that frame.

So once we decided that the multi-frames approach is a non-starter we
should decide that tear-off windows and windows with menu- or toolbars
are non-starters too.  Can we agree on that?

martin

Re: Infrastructural complexity.

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> Anway, converting windows to frames in order to tear them off and back
> to windows when docking them back seems hardly feasible to me.  Not to
> think of multiple (un-)wrapping menu- or toolbars somewhere in the
> middle of a frame just because the user decided to resize that frame.
>
> So once we decided that the multi-frames approach is a non-starter we
> should decide that tear-off windows and windows with menu- or toolbars
> are non-starters too.  Can we agree on that?

I see no reason to implement tear-off functionality, extra tool-bars,
etc.  All I care about is to have an infrastructure for grouping
windows, for replacing the advice used in ECB (while being general
enough to be used by other applications, such as gdb-ui).

Re: Infrastructural complexity.

[Miles Bader]

martin rudalics <rudalics@gmx.at> writes:
>> Once you start letting the WM have any control all bets are off --
>> remember, it's _not_ just initial placement, but movement, sizing
>> [think: tiling WM!], additional WM-added frames, dealing with the many,
>> many, differences between WMs on different platforms, etc.
>
> The user is supposed to control the WM

AFAIK, the problem people are trying to solve right now is a way of
increasing the power of emacs _automatic_ control over window layout --
burdening the user with the placement and moving of these sub-windows is
exactly what we _don't_ want to do.

> and tiling WMs should manage multiple Emacs frames better than Emacs
> itself is able to tile a frame into multiple windows.  After all
> that's what tiling WMs are supposed to do well.

They certainly don't do it well, not if you want application-specific
inter-relationships between a set of different windows (which is exactly
what we want).

[They do an OK job of laying out completely independent application
windows in some case, at least to a point.]

> So once we decided that the multi-frames approach is a non-starter we
> should decide that tear-off windows and windows with menu- or toolbars
> are non-starters too.  Can we agree on that?

I don't know if "tear off" windows are a goal or not, but tearing off a
emacs sub-window is an explicit user action saying "ok, I as user am now
assuming control over this sub-window."  So _moving_ a torn-off emacs
internal window into its own separate frame would actually be the most
natural thing to do.

-Miles

-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Gandhi

Re: Infrastructural complexity.

[martin rudalics]

 > AFAIK, the problem people are trying to solve right now is a way of
 > increasing the power of emacs _automatic_ control over window layout --
 > burdening the user with the placement and moving of these sub-windows is
 > exactly what we _don't_ want to do.

In my book tearing off a window does not count as automatic control.

 > They certainly don't do it well, not if you want application-specific
 > inter-relationships between a set of different windows (which is exactly
 > what we want).

What's the purpose of tiling window managers when you can't tell them
_where_ to put your windows?

 > I don't know if "tear off" windows are a goal or not,

Certainly not my goal.  This subthread was my reaction to proposals like
providing tear-off windows, toolbars and menubars for the objects we
want to handle.  I argued it can be done easily but only at the cost of
conceptually replacing windows by frames.

 > but tearing off a
 > emacs sub-window is an explicit user action saying "ok, I as user am now
 > assuming control over this sub-window."  So _moving_ a torn-off emacs
 > internal window into its own separate frame would actually be the most
 > natural thing to do.

Tearing off a window and putting it into a separate frame is no synonym
for "moving" that window into a separate frame.  You have to make a new
window and you break all overlays with a 'window property in the old
window's buffer and all references to that window stored in running
applications (although for the user the new window appears the same as
before).  So if you consider tearing off windows "a natural thing to do"
you only raise false hopes.

martin

Re: Infrastructural complexity.

[Miles Bader]

>> AFAIK, the problem people are trying to solve right now is a way of
>> increasing the power of emacs _automatic_ control over window layout --
>> burdening the user with the placement and moving of these sub-windows is
>> exactly what we _don't_ want to do.
>
> In my book tearing off a window does not count as automatic control.

Why do you keep talking about "tear-off windows"?  They aren't the focus
of this discussion.

As I said in my previous message:  [[I don't know if "tear off" windows
are a goal or not, but tearing off a emacs sub-window is an explicit
user action saying "ok, I as user am now assuming control over this
sub-window."']]

In other words, they are (1) not a required feature, and (2) represent
and explicit user _escape_ from the automatic layout.  The focus of this
discussion -- AFAICT -- is the automatic layout _not_ the
optional-and-fringe-feature of tear-off-windows.  While tear-off windows
may be an interesting feature, and kinda cool, they are not a
particularly important feature, and are _not_ the point of the current
conversation.  It'd be fine if whatever solution is decided completely
lacks that feature.

>> They certainly don't do it well, not if you want application-specific
>> inter-relationships between a set of different windows (which is exactly
>> what we want).
>
> What's the purpose of tiling window managers when you can't tell them
> _where_ to put your windows?

[completely OT at this point, but: to place windows.  By default, most
tiling WMs, do so automatically, unless the user or the app takes the
trouble to setup some (non-default and WM-specific) mechanism to do so.]

> Tearing off a window and putting it into a separate frame is no synonym
> for "moving" that window into a separate frame.  You have to make a new
> window and you break all overlays with a 'window property in the old
> window's buffer and all references to that window stored in running
> applications (although for the user the new window appears the same as
> before).  So if you consider tearing off windows "a natural thing to do"
> you only raise false hopes.

I dunno; I haven't looked at the implementation details.  It doesn't
sound particularly hard to me, offhand, to have the Emacs code move an
internal Emacs window structure to another parent frame (preserving any
pointers/whatever, but changing the frame pointer etc) in this case, but
I'll have to demur from arguing about it, since I don't have any
detailed basis on which do so.

Since tear-off windows are not very important though, it doesn't really
matter.  An implementation which creates a new Emacs window inside a new
frame seems acceptable to me as well.  Or simply not having tear-off
windows.

-Miles

-- 
Learning, n. The kind of ignorance distinguishing the studious.

Re: Infrastructural complexity.

[Lennart Borgman]

On Tue, Jul 21, 2009 at 12:08 AM, Miles Bader<miles@gnu.org> wrote:
>
> I dunno; I haven't looked at the implementation details.  It doesn't
> sound particularly hard to me, offhand, to have the Emacs code move an
> internal Emacs window structure to another parent frame (preserving any
> pointers/whatever, but changing the frame pointer etc) in this case, but
> I'll have to demur from arguing about it, since I don't have any
> detailed basis on which do so.


This was actually one of the reasons I wrote winsav.el, it does just
that (in elisp). It can put a window tree into a window.

There are some things to think about, like window (re)sizing.


> Since tear-off windows are not very important though, it doesn't really
> matter.  An implementation which creates a new Emacs window inside a new
> frame seems acceptable to me as well.  Or simply not having tear-off
> windows.

Re: Infrastructural complexity.

[Thomas Lord]

Re the "tear off" confusion:

I think I probably started the confusion by
bringing up tear-offs in the first place.
Sorry.   My only point is that the addition
of a (probably or at least initially non-nesting)
"parent-frame" slot to frames would give a natural
model for both control panels around the side of a 
window and for tear offs.

If a window system window was really 5 frames,
configurable in the ways I diagramed....  if there
were "tear off frames" from tool bars....  if
Emacs had a unified model for toolbars and menus ...
THEN I think it would be straightforward to have
Emacs extension packages that look and feel a lot
like OpenOffice Writer and Eclipse.

When (if?) Emacs pixmap buffers become richer in 
functionality it could also compete against
programs like Gimp.

If (when?) Emacs had a display mode for 
"SVG buffers", it could compete against drawing
programs, presentation manager programs, etc.

It would be kinda neat, from my perspective,
in that with those features - 20 years worth
of GUI toolkit designers repeating the mistakes of
their predecessors could be flushed away. 
The church of Emacs would be vindicated (as
if it needs it) :-)

I also think it's pretty "doable".  The 1 system
window == 5 frames thing just can't possibly be
*that* hard.   The generalization of menu bars
into toolbars and hierarchical command menus
isn't huge and fits in nicely among existing 
abstractions / facilities.   Improved pixmap
support (e.g., "one buffer per layer" with virtual
buffers overlaying them) is a huge job but one
small step at a time can get it done.  And, 
sure, the notion of "SVG buffers" is a pipe-dream
and, yeah, just kind of hard to get over the first
hump to achieve something minimally useful.  But
a boy can dream, can't he?


-t



On Tue, 2009-07-21 at 07:08 +0900, Miles Bader wrote:
> >> AFAIK, the problem people are trying to solve right now is a way of
> >> increasing the power of emacs _automatic_ control over window layout --
> >> burdening the user with the placement and moving of these sub-windows is
> >> exactly what we _don't_ want to do.
> >
> > In my book tearing off a window does not count as automatic control.
> 
> Why do you keep talking about "tear-off windows"?  They aren't the focus
> of this discussion.
> 
> As I said in my previous message:  [[I don't know if "tear off" windows
> are a goal or not, but tearing off a emacs sub-window is an explicit
> user action saying "ok, I as user am now assuming control over this
> sub-window."']]
> 
> In other words, they are (1) not a required feature, and (2) represent
> and explicit user _escape_ from the automatic layout.  The focus of this
> discussion -- AFAICT -- is the automatic layout _not_ the
> optional-and-fringe-feature of tear-off-windows.  While tear-off windows
> may be an interesting feature, and kinda cool, they are not a
> particularly important feature, and are _not_ the point of the current
> conversation.  It'd be fine if whatever solution is decided completely
> lacks that feature.
> 
> >> They certainly don't do it well, not if you want application-specific
> >> inter-relationships between a set of different windows (which is exactly
> >> what we want).
> >
> > What's the purpose of tiling window managers when you can't tell them
> > _where_ to put your windows?
> 
> [completely OT at this point, but: to place windows.  By default, most
> tiling WMs, do so automatically, unless the user or the app takes the
> trouble to setup some (non-default and WM-specific) mechanism to do so.]
> 
> > Tearing off a window and putting it into a separate frame is no synonym
> > for "moving" that window into a separate frame.  You have to make a new
> > window and you break all overlays with a 'window property in the old
> > window's buffer and all references to that window stored in running
> > applications (although for the user the new window appears the same as
> > before).  So if you consider tearing off windows "a natural thing to do"
> > you only raise false hopes.
> 
> I dunno; I haven't looked at the implementation details.  It doesn't
> sound particularly hard to me, offhand, to have the Emacs code move an
> internal Emacs window structure to another parent frame (preserving any
> pointers/whatever, but changing the frame pointer etc) in this case, but
> I'll have to demur from arguing about it, since I don't have any
> detailed basis on which do so.
> 
> Since tear-off windows are not very important though, it doesn't really
> matter.  An implementation which creates a new Emacs window inside a new
> frame seems acceptable to me as well.  Or simply not having tear-off
> windows.
> 
> -Miles
> 

Re: Infrastructural complexity.

[martin rudalics]

 > Why do you keep talking about "tear-off windows"?  They aren't the focus
 > of this discussion.

This subthread was triggered by the framelet proposal which introduced
tear-off windows together with separate tool/menu/tabbars.  The idea or
introducing such features was the premise for my initial posting which
you tend to ignore all the time.  I said that if we want these sort of
things then we should use frames instead of windows.  I never proposed
to use frames unconditionally (which would be ridiculous BTW since I
already spent quite some time modifying the window code).

But I have to consider the possibility that users regard issues like
tear-off windows and separate tool/menu/tabbars important enough so I
have to make sure which way to go.

 > As I said in my previous message:  [[I don't know if "tear off" windows
 > are a goal or not, but tearing off a emacs sub-window is an explicit
 > user action saying "ok, I as user am now assuming control over this
 > sub-window."']]
 >
 > In other words, they are (1) not a required feature, and (2) represent
 > and explicit user _escape_ from the automatic layout.  The focus of this
 > discussion -- AFAICT -- is the automatic layout _not_ the
 > optional-and-fringe-feature of tear-off-windows.  While tear-off windows
 > may be an interesting feature, and kinda cool, they are not a
 > particularly important feature, and are _not_ the point of the current
 > conversation.  It'd be fine if whatever solution is decided completely
 > lacks that feature.

But precisely that is the problem: If a user is allowed to escape the
automatic layout (any maybe return to it at some later moment) we have
to handle that.  It's already hard enough to handle the case where a
user invokes `display-buffer' within the automatic layout in order to
show a help or info window and later quit that window.  IIRC ECB saves
the current window layout for that purpose leaving a one window frame,
splits that window, makes one window the help/info window and fills the
other window with the saved layout.  Now how to you suppose us to handle
the case where we have to fill the space left by a torn-off window and
reintegrate that window in the automatic layout?

 >> What's the purpose of tiling window managers when you can't tell them
 >> _where_ to put your windows?
 >
 > [completely OT at this point, but: to place windows.  By default, most
 > tiling WMs, do so automatically, unless the user or the app takes the
 > trouble to setup some (non-default and WM-specific) mechanism to do so.]

Yes, and I conjectured that setting up such a mechanism is quite as
complicated as setting up an mechanism for automatic layout of windows
within an Emacs frame.  And I did this in a reply to Tom's earlier
statement, namely

 > One large difference, though, is that framelets really require
 > more changes to the C code of Emacs while window groups can
 > get away with little or 0 changes to the C code.  From some of the
 > conversation, I suspect that this is one of the big reasons that
 > there is support for window groups.

to state that IMHO implementing window groups means to make considerably
more changes to the C code than implementing framelets.

 >> Tearing off a window and putting it into a separate frame is no synonym
 >> for "moving" that window into a separate frame.  You have to make a new
 >> window and you break all overlays with a 'window property in the old
 >> window's buffer and all references to that window stored in running
 >> applications (although for the user the new window appears the same as
 >> before).  So if you consider tearing off windows "a natural thing to do"
 >> you only raise false hopes.
 >
 > I dunno; I haven't looked at the implementation details.  It doesn't
 > sound particularly hard to me, offhand, to have the Emacs code move an
 > internal Emacs window structure to another parent frame (preserving any
 > pointers/whatever, but changing the frame pointer etc) in this case, but
 > I'll have to demur from arguing about it, since I don't have any
 > detailed basis on which do so.

Emacs has overlays which can have a window property which can have the
display engine handle the overlay differently when the property matches
the window the overlay is displayed on.  When you tear off a window the
identity of that window changes and you have to check all overlays in
all buffers whether any window property should get updated accordingly.

 > Since tear-off windows are not very important though, it doesn't really
 > matter.  An implementation which creates a new Emacs window inside a new
 > frame seems acceptable to me as well.  Or simply not having tear-off
 > windows.

... or separate tool/menu/tabbars (unless the latter show up in the
header lines).

martin

Re: Infrastructural complexity.

[Miles Bader]

martin rudalics <rudalics@gmx.at> writes:
>> Why do you keep talking about "tear-off windows"?  They aren't the focus
>> of this discussion.
>
> This subthread was triggered by the framelet proposal which introduced
> tear-off windows together with separate tool/menu/tabbars.

Nonetheless, that was a minor and optional detail, not the focus of the thread.

> The idea or introducing such features was the premise for my initial
> posting which you tend to ignore all the time.  I said that if we want
> these sort of things then we should use frames instead of windows.  I
> never proposed to use frames unconditionally (which would be
> ridiculous BTW since I already spent quite some time modifying the
> window code).

It might indeed make implementing tear-off windows -- a minor feature --
easier, at the expensive of making the _normal_ case -- automatic layout
-- much more difficult.  Not a good tradeoff, I'd wager.

> But I have to consider the possibility that users regard issues like
> tear-off windows and separate tool/menu/tabbars important enough so I
> have to make sure which way to go.

I suppose you can consider the possibility that easy tear-off windows are
more important than automatic window layout, but it seems remote to me.

> But precisely that is the problem: If a user is allowed to escape the
> automatic layout (any maybe return to it at some later moment) we have
> to handle that.  It's already hard enough to handle the case where a
> user invokes `display-buffer' within the automatic layout in order to
> show a help or info window and later quit that window.  IIRC ECB saves
> the current window layout for that purpose leaving a one window frame,
> splits that window, makes one window the help/info window and fills the
> other window with the saved layout.  Now how to you suppose us to handle
> the case where we have to fill the space left by a torn-off window and
> reintegrate that window in the automatic layout?

I have not thought deeply about how to implement tear-off windows.

However, it doesn't matter w/r/t the issue of whether we use WM windows
or "internal" windows for the windows in question:  the actual automatic
_layout_ is equally hard or easy regardless -- the additional
difficulties of using WM windows come from the fact that it's much more
difficult for Emacs to control them (because it must go through, and
account for the vagaries of, the WM).

> to state that IMHO implementing window groups means to make considerably
> more changes to the C code than implementing framelets.

>> I dunno; I haven't looked at the implementation details.  It doesn't
>> sound particularly hard to me, offhand, to have the Emacs code move an
>> internal Emacs window structure to another parent frame (preserving any
>> pointers/whatever, but changing the frame pointer etc) in this case, but
>> I'll have to demur from arguing about it, since I don't have any
>> detailed basis on which do so.
>
> Emacs has overlays which can have a window property which can have the
> display engine handle the overlay differently when the property matches
> the window the overlay is displayed on.  When you tear off a window the
> identity of that window changes and you have to check all overlays in
> all buffers whether any window property should get updated accordingly.

Well, obviously that difficulty only applies if we can't move the window
object ("re-purpose it") into another frame.  If we _can_, well then the
window object stays the same, so no (or at least fewer) problems.

If there's a reason we _can't_ re-purpose the window object into a
another frame, then the issues you raise may apply.  However, I do not
know if this is actually important or not -- in many cases, it's
perfectly valid to say "user code has to be prepared to deal with this."

-Miles

-- 
Non-combatant, n. A dead Quaker.

Re: Infrastructural complexity.

[martin rudalics]

 > Nonetheless, that was a minor and optional detail, not the focus of the thread.

This our subthread was triggered by Tom's statement

 > > The "GUIs" you are going up against here tend
 > > to have window system windows with a main edit
 > > area.  At the sides or bottom or top are various
 > > "panels" that perform ancillary functions.  Each
 > > panel might have such things as a toolbar or set
 > > of "tabs".   The window  system window as a whole will
 > > have menus, a toolbar, and perhaps something like
 > > a minibuffer.   In addition there are floating
 > > dialog boxes and "tear offs".   So the question seems
 > > to be how to cleanly and simply improve emacs so
 > > that analogous things are possible.
 > [...]
 > > Something like "framelettes" seems a much better design
 > > to me.

Richard's request

 > > It might be a subtle question.  To think about it, I suggest looking
 > > at by asking: What is the difference between a windowgroup and a
 > > framelet?  Or what are the various differences?

and Juri's remark

 > > I guess the difference is in frame parameters.  If framelets are
 > > Emacs frames inside the main Emacs frame, then they should have
 > > their own menu bars, tool bars, tab bars.

so I guess they are focus of this subthread.

 > It might indeed make implementing tear-off windows -- a minor feature --
 > easier, at the expensive of making the _normal_ case -- automatic layout
 > -- much more difficult.  Not a good tradeoff, I'd wager.

The difficulty results exclusively from your assertion that the WM is
not able to honor Emacs' requests of window placement.  I can't judge
that assertion because I practically always use only one frame that
occupies the entire screen.  So maybe you're right - but a WM that
doesn't honor its client's placement requests is a bad WM IMHO.

 > I suppose you can consider the possibility that easy tear-off windows are
 > more important than automatic window layout, but it seems remote to me.

But I must consider the possibility that an automatic layout gets broken
by tearing off a window.  ECB, for example, puts considerable care into
how windows are rearranged when one gets deleted.

 > Well, obviously that difficulty only applies if we can't move the window
 > object ("re-purpose it") into another frame.  If we _can_, well then the
 > window object stays the same, so no (or at least fewer) problems.

In three steps: (1) save a frame's window configuration, (2) tear off a
window from that frame and re-purpose it into another frame, (3) restore
the window configuration saved in step (1).  Gets you two windows with
the same identity.  No fun here, no fun at all ...

 > If there's a reason we _can't_ re-purpose the window object into a
 > another frame, then the issues you raise may apply.  However, I do not
 > know if this is actually important or not -- in many cases, it's
 > perfectly valid to say "user code has to be prepared to deal with this."

I cannot think of a case where it would be even slightly valid to say
that.

martin

Re: Infrastructural complexity.

[Stefan Monnier]

> The difficulty results exclusively from your assertion that the WM is
> not able to honor Emacs' requests of window placement.

There's really no way for Emacs to request a particular placement: maybe
when the frame is created, Emacs can sometimes specify the size and
position of that frame, but:
- it's only a hint, which the window-manager is allowed to disregard,
  and in practice window managers often disregard it, and for good
  reasons (e.g. the window would overlap with some other important
  window, or the position is incompatible with some other layout
  request from the user, or ...).
- it doesn't say what to do when one of the two frames gets
  resized/iconified/moved/... (because there's no protocol to convey the
  intention behind the choice of those specific size and position
  parameters).

> I can't judge
> that assertion because I practically always use only one frame that
> occupies the entire screen.  So maybe you're right - but a WM that
> doesn't honor its client's placement requests is a bad WM IMHO.

A good WM makes it possible for the user to explain to the WM what kind
of layouts he wants.  E.g. whether he wants windows to be tiled or not,
which windows are allowed to overlap which other windows, which windows
get placed manually, which ones should fit within the screen
boundaries...  The more such rules there are, the more likely it is that
they will collide with the application's placement request, in which
case the WM is justified to favor the user's config over the
application's request.
On top of that, 99% of the applications don't request any particular
placement, so the WM code handling it has *very* low priority.
And to really kill it off completely, most applications that make such
requests do it for the wrong reason (they're written with one
particular use-case in mind and completely disregard other situations,
so it's common for the WM to take such data with a big grain of salt).

I agree with Miles here: it's a non-starter.  If you want other reasons
for it, think about the difficulties we face already with timing issues
in requests for resizing/moving frames and/or controlling focus of newly
created frames.  We have lots and lots of bugs there, most of which are
a nightmare to fix because we're at the mercy of the WM.

> In three steps: (1) save a frame's window configuration, (2) tear off a
> window from that frame and re-purpose it into another frame, (3) restore
> the window configuration saved in step (1).  Gets you two windows with
> the same identity.  No fun here, no fun at all ...

I think such window-configurations shouldn't save window identities.
Especially if one wants to be able to restore one window-configuration in
a different frame (and/or save that config into a file).

In other words, I think that the issue of window-identity w.r.t
window-configurations is one where there's no way to win.  I think the
least breakage will happen when we give up on preserving
those identities.


        Stefan

Re: Infrastructural complexity.

[Thomas Lord]

On Tue, 2009-07-21 at 12:13 -0400, Stefan Monnier wrote:

> There's really no way for Emacs to request a particular placement: maybe
> when the frame is created,

Is that really true for the use case at hand?

For example, on X11, window system windows can have parents
and applications can control their placement within the
parent.  That's how things like pop-up menus often work.

A "tear-off" is a menu or very similar pop-up that
the user can "reparent" and make persistent on the
screen.  When the user does that, it's generally
speaking by means of a mouse gesture that explicitly
says where the reparented window goes.

I don't see the problem with allowing those pop-ups
to be frames (framelets) that can then be torn off.

-t

Re: Infrastructural complexity.

[martin rudalics]

 > I agree with Miles here: it's a non-starter.  If you want other reasons
 > for it, think about the difficulties we face already with timing issues
 > in requests for resizing/moving frames and/or controlling focus of newly
 > created frames.  We have lots and lots of bugs there, most of which are
 > a nightmare to fix because we're at the mercy of the WM.

I agree with you and Miles that WM interaction is problematic.  But if
we don't use frames then IMHO framelets, tear-off windows and multiple
tool and/or menubars are non-starters too.  And here we apparently
disagree.

 >> In three steps: (1) save a frame's window configuration, (2) tear off a
 >> window from that frame and re-purpose it into another frame, (3) restore
 >> the window configuration saved in step (1).  Gets you two windows with
 >> the same identity.  No fun here, no fun at all ...
 >
 > I think such window-configurations shouldn't save window identities.

`current-window-configuration' combined with `set-window-configuration'
does preserve window identities.

 > Especially if one wants to be able to restore one window-configuration in
 > a different frame (and/or save that config into a file).

These would have to become different functions anyway and would always
have to create a new window.

 >  In other words, I think that the issue of window-identity w.r.t
 > window-configurations is one where there's no way to win.  I think the
 > least breakage will happen when we give up on preserving those
 > identities.

We currently do not have any problems with window identities.  So why
introduce problems by trying to preserve a window's identity when
tearing it off?

martin

Re: Infrastructural complexity.

[Stefan Monnier]

>> I think such window-configurations shouldn't save window identities.
> `current-window-configuration' combined with `set-window-configuration'
> does preserve window identities.

Of course, I know they currently do.  IIUC they don't in XEmacs any more.

>> In other words, I think that the issue of window-identity w.r.t
>> window-configurations is one where there's no way to win.  I think the
>> least breakage will happen when we give up on preserving those
>> identities.
> We currently do not have any problems with window identities.  So why
> introduce problems by trying to preserve a window's identity when
> tearing it off?

Here I agree with you: I do not care about preserving window-identities
during tear-off any more than during any other operation.


        Stefan

Re: Infrastructural complexity.

[martin rudalics]

 >>> I think such window-configurations shouldn't save window identities.
 >> `current-window-configuration' combined with `set-window-configuration'
 >> does preserve window identities.
 >
 > Of course, I know they currently do.  IIUC they don't in XEmacs any more.
[...]
 > Here I agree with you: I do not care about preserving window-identities
 > during tear-off any more than during any other operation.

So in the future I may have to rebuild all overlays with a 'window
property whenever `adjust-window-trailing-edge' fails or I'm reading
from the minibuffer.  Good to know.

martin

Re: Infrastructural complexity.

[Stefan Monnier]

> So in the future I may have to rebuild all overlays with a 'window
> property whenever `adjust-window-trailing-edge' fails or I'm reading
> from the minibuffer.  Good to know.

Not sure what you mean by "I".  Which mode using the `window' property
would need that?


        Stefan

Re: Infrastructural complexity.

[martin rudalics]

 > Not sure what you mean by "I".  Which mode using the `window' property
 > would need that?

"I" means "I", so just my own, private code would be affected.

However, letting `set-window-configuration' change the identity of
windows would obviously break my window groups code (which is based on
the invariant identity of internal windows) and my entire window
debugging code.

I'd finally understand that the "s" in Emacs stands for "stochastic" ;-)

martin

Re: Infrastructural complexity.

[Stefan Monnier]

>> Not sure what you mean by "I".  Which mode using the `window' property
>> would need that?
> "I" means "I", so just my own, private code would be affected.

> However, letting `set-window-configuration' change the identity of
> windows would obviously break my window groups code (which is based on
> the invariant identity of internal windows) and my entire window
> debugging code.

I'd consider such code as "internal", so yes it would probably need to
be updated.  This said, I don't think set-window-configuration should be
changed to always create new window identities.  E.g. in the case of
save-window-excursion, for example, new identities would only be created
for windows that had been deleted in the mean time.

> I'd finally understand that the "s" in Emacs stands for "stochastic" ;-)

Yes, and the "c" is for "creative".


        Stefan

Re: Infrastructural complexity.

[Lennart Borgman]

On Thu, Jul 23, 2009 at 5:12 PM, Stefan Monnier<monnier@iro.umontreal.ca> wrote:
>>> Not sure what you mean by "I".  Which mode using the `window' property
>>> would need that?
>> "I" means "I", so just my own, private code would be affected.
>
>> However, letting `set-window-configuration' change the identity of
>> windows would obviously break my window groups code (which is based on
>> the invariant identity of internal windows) and my entire window
>> debugging code.
>
> I'd consider such code as "internal", so yes it would probably need to
> be updated.  This said, I don't think set-window-configuration should be
> changed to always create new window identities.  E.g. in the case of
> save-window-excursion, for example, new identities would only be created
> for windows that had been deleted in the mean time.


Maybe we could add an internal window property to be used as fallback
if a window with a certain identity is not found. Save window
configuration could save and restore this property.

Re: Infrastructural complexity.

[martin rudalics]

 >> However, letting `set-window-configuration' change the identity of
 >> windows would obviously break my window groups code (which is based on
 >> the invariant identity of internal windows) and my entire window
 >> debugging code.
 >
 > I'd consider such code as "internal", so yes it would probably need to
 > be updated.

Updated in what sense?  To deal with the fact that window excursions can
change the identity of a window or an entire window group?  I currently
display in my mode line the identity and group of each window to control
visually how their status changes.  How shall I continue to do that when
each window excursion can arbitrarily change these identities?

 > This said, I don't think set-window-configuration should be
 > changed to always create new window identities.  E.g. in the case of
 > save-window-excursion, for example, new identities would only be created
 > for windows that had been deleted in the mean time.

When `adjust-window-trailing-edge' inadvertently deletes a window, it
restores the previous window configuration and reports an error.  Thus
this function currently behaves as a noop wrt the window configuration.
Do you really mean it should give the resurrected window a new identity?

 > Yes, and the "c" is for "creative".

So let's try to be more "creative" and less "chaotic".

martin

Re: Infrastructural complexity.

[Thomas Lord]

I have a naive question / whacky idea that maybe
someone can evaluate off the top of their head
much more quickly than I could myself.

Doesn't `screen' and similar programs give 
the ability to tile a text display with 
more than one virtual terminal?

Can't Emacs be persuaded to use multiple `screen'
virtual terminals as frames?

If the answer to both is "yes" then can't that
be usefully used as a way to prototype and try
out the idea of "four framelets around a central
edit area"?

-t

Re: Infrastructural complexity.

[joakim]

Thomas Lord <lord@emf.net> writes:

> I have a naive question / whacky idea that maybe
> someone can evaluate off the top of their head
> much more quickly than I could myself.
>
> Doesn't `screen' and similar programs give 
> the ability to tile a text display with 
> more than one virtual terminal?
>
> Can't Emacs be persuaded to use multiple `screen'
> virtual terminals as frames?

Yes, that should be doable.

> If the answer to both is "yes" then can't that
> be usefully used as a way to prototype and try
> out the idea of "four framelets around a central
> edit area"?
>
> -t
>
-- 
Joakim Verona

Re: Infrastructural complexity.

[Stefan Monnier]

> When `adjust-window-trailing-edge' inadvertently deletes a window, it
> restores the previous window configuration and reports an error.  Thus
> this function currently behaves as a noop wrt the window configuration.
> Do you really mean it should give the resurrected window a new identity?

No, I mean it should be changed so as to detect the problem before the
window gets deleted.


        Stefan

Re: Infrastructural complexity.

[martin rudalics]

 >> When `adjust-window-trailing-edge' inadvertently deletes a window, it
 >> restores the previous window configuration and reports an error.  Thus
 >> this function currently behaves as a noop wrt the window configuration.
 >> Do you really mean it should give the resurrected window a new identity?
 >
 > No, I mean it should be changed so as to detect the problem before the
 > window gets deleted.

I doubt Richard deliberately used window configurations in
`adjust-window-trailing-edge'.  Unless we can get `enlarge-window' DTRT
in all cases (which seems a rather challenging task IMHO) saving window
configurations is an effective albeit somewhat expensive way to handle
this and similar behaviors.

martin

Re: Infrastructural complexity.

[Richard Stallman]

    I doubt Richard deliberately used window configurations in
    `adjust-window-trailing-edge'.  Unless we can get `enlarge-window' DTRT
    in all cases (which seems a rather challenging task IMHO) saving window
    configurations is an effective albeit somewhat expensive way to handle
    this and similar behaviors.

I used window configurations as a simple and reliable way to make
sure it would not delete the window.  If someone wants to make it use
a different and faster method, I have nothing against it.

Note that `adjust-window-trailing-edge' is conceptually a lower level
and more predictable operation than `enlarge-window'.  One could
imagine rewriting `enlarge-window' in Lisp and making it use
`adjust-window-trailing-edge'.

Re: Infrastructural complexity.

[martin rudalics]

 > I used window configurations as a simple and reliable way to make
 > sure it would not delete the window.  If someone wants to make it use
 > a different and faster method, I have nothing against it.

Any such method would have to guess whether, which, and how many,
windows `enlarge-window' is going to delete.  Counting windows and
restoring saved window configurations seems indeed like the most simple
and reliable approach to do that.

 > Note that `adjust-window-trailing-edge' is conceptually a lower level
 > and more predictable operation than `enlarge-window'.  One could
 > imagine rewriting `enlarge-window' in Lisp and making it use
 > `adjust-window-trailing-edge'.

Currently, `adjust-window-trailing-edge' has a bug in that it does not
handle fixed-size windows correctly, see bug#3689.  I think we need an
`enlarge-window' function which does not delete windows but is allowed
to resize any other windows that are not fixed-size.

martin

Re: Infrastructural complexity.

[Stefan Monnier]

>> I used window configurations as a simple and reliable way to make
>> sure it would not delete the window.  If someone wants to make it use
>> a different and faster method, I have nothing against it.

> Any such method would have to guess whether, which, and how many,
> windows `enlarge-window' is going to delete.  Counting windows and
> restoring saved window configurations seems indeed like the most simple
> and reliable approach to do that.

How 'bout: bind a enlarge-window-abort-before-delete variable to
t in adjust-window-trailing-edge, and then check this variable before
deleting a window?

> Currently, `adjust-window-trailing-edge' has a bug in that it does not
> handle fixed-size windows correctly, see bug#3689.  I think we need an
> `enlarge-window' function which does not delete windows but is allowed
> to resize any other windows that are not fixed-size.

100% agreement.


        Stefan

Re: Infrastructural complexity.

[martin rudalics]

 > How 'bout: bind a enlarge-window-abort-before-delete variable to
 > t in adjust-window-trailing-edge, and then check this variable before
 > deleting a window?

Not really.  Enlarging a window means stealing space from others and
size_window might already have stolen space from windows before it tries
to delete one.  With a DELTA > 1 this might leave the frame in an
inconsistent state.  That is, a window that shall be enlarged vertically
might have grown by a couple of lines but not the entire DELTA when the
action must be aborted.

 >> Currently, `adjust-window-trailing-edge' has a bug in that it does not
 >> handle fixed-size windows correctly, see bug#3689.  I think we need an
 >> `enlarge-window' function which does not delete windows but is allowed
 >> to resize any other windows that are not fixed-size.
 >
 > 100% agreement.

Writing such a function is not entirely trivial.  I suppose we'd have to
run the function without actually changing anything first and, if we
succeeded in not deleting any windows, apply the actual changes.

martin

Re: Infrastructural complexity.

[Stefan Monnier]

>> How 'bout: bind a enlarge-window-abort-before-delete variable to
>> t in adjust-window-trailing-edge, and then check this variable before
>> deleting a window?

> Not really.  Enlarging a window means stealing space from others and
> size_window might already have stolen space from windows before it tries
> to delete one.  With a DELTA > 1 this might leave the frame in an
> inconsistent state.  That is, a window that shall be enlarged vertically
> might have grown by a couple of lines but not the entire DELTA when the
> action must be aborted.

But if we combine it with save-window-configuration, we should be able
to revert to the original state (and if we stop before deleting
a window, there's no need to create a new window identity).

>>> Currently, `adjust-window-trailing-edge' has a bug in that it does not
>>> handle fixed-size windows correctly, see bug#3689.  I think we need an
>>> `enlarge-window' function which does not delete windows but is allowed
>>> to resize any other windows that are not fixed-size.

> Writing such a function is not entirely trivial.  I suppose we'd have to
> run the function without actually changing anything first and, if we
> succeeded in not deleting any windows, apply the actual changes.

I rather think that it requires a completely new algorithm where
window-deletion is not even an option.


        Stefan

Re: Infrastructural complexity.

[martin rudalics]

 > But if we combine it with save-window-configuration, we should be able
 > to revert to the original state (and if we stop before deleting
 > a window, there's no need to create a new window identity).

Hmmm...  size_window has a NODELETE_P argument but for some reason
adjust_window_trailing_edge doesn't set it.  On the other hand
size_window never reports failure so we would have to compare heights in
adjust_window_trailing_edge to detect whether there was a failure.

 > I rather think that it requires a completely new algorithm where
 > window-deletion is not even an option.

Probably using the NODELETE_P argument mentioned above.  Remains one
question: In which cases would deleting windows be an option?

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Tue, 2009-07-21 at 19:28 +0900, Miles Bader wrote:

> I have not thought deeply about how to implement tear-off windows.

I think there is confusion in this thread because
"tear of *windows*" aren't a feature that's commonly
used.   Tear-off menus and toolbar controllers are
commonly used (and are nice to use).

In other words, by "tear-off" we shouldn't mean that
you grab an arbitrary Emacs window from its frame,
tear it out, and then it has its own frame.  Rather,
it's more like you click on a toolbar item -- a new
(usually tiny) window system window "pops up" with a 
bunch of sub-options to choose from.  You can either 
pick an option - in which case the tiny pop-up 
disappears - or you can "tear it off" in which case
it is persistent and you can pick multiple options
from the choices.

For example, to draw a rectangle in the OO diagram
editor you click a "shape" icon on a toolbar and up
pops a tiny window of possible shapes you might
want to draw.  You can pick "rectangle" and the tiny
window goes away and you are in "rectangle drawing mode".
On the other hand, you can "tear off" the tiny window,
pick "rectangle", draw a rectangle, then pick "ellipse",
draw an ellipse, and so forth.

Those tiny windows could be modeled nicely, I
think, as framelets:  frames with a non-nil parent.

-t

Re: Infrastructural complexity.

[martin rudalics]

 > I think there is confusion in this thread because
 > "tear of *windows*" aren't a feature that's commonly
 > used.

Good.  I hope this means we don't have to care about tear-off "windows"
any more.

 > Tear-off menus and toolbar controllers are
 > commonly used (and are nice to use).

And these can be implemented independently from window groups.

 > Those tiny windows could be modeled nicely, I
 > think, as framelets:  frames with a non-nil parent.

What is the parent of a frame?  Not an Emacs concept, I presume.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Wed, 2009-07-22 at 12:12 +0200, martin rudalics wrote:

>  > Tear-off menus and toolbar controllers are
>  > commonly used (and are nice to use).
> 
> And these can be implemented independently from window groups.
> 
>  > Those tiny windows could be modeled nicely, I
>  > think, as framelets:  frames with a non-nil parent.
> 
> What is the parent of a frame?  Not an Emacs concept, I presume.

It is a concept I'm trying to persuade people
to use *instead of* window groups.  I think
that window groups are too complicated and that
they add generality of dubious, perhaps negative
utility.

With the change I'm proposing, frames gain
a new slot - a parent slot - whose value is
either nil or another frame.   Elisp programs
can *not* modify this slot arbitrarily.

No frame with a non-nil parent slot can itself
be parent to another frame (at least not initially)
thus nesting is limited to one level.

Frames with non-nil parent slots can be created as
pop-ups that can be torn off.   Additionally, each
frame with a nil parent slot has four children that
share its same window system window.  (See my earlier
message with the Subject line "16 (Re: ...)".)

When a parent frame is minimized or deleted, it's
child frames are also minimized or deleted.

This is a cleaner way, imo, to accomplish what
window groups are trying to accomplish.

-t

Re: Infrastructural complexity.

[Mathias Dahl]

K














































































































2009/7/22, Thomas Lord <lord@emf.net>:
> On Wed, 2009-07-22 at 12:12 +0200, martin rudalics wrote:
>
>>  > Tear-off menus and toolbar controllers are
>>  > commonly used (and are nice to use).
>>
>> And these can be implemented independently from window groups.
>>
>>  > Those tiny windows could be modeled nicely, I
>>  > think, as framelets:  frames with a non-nil parent.
>>
>> What is the parent of a frame?  Not an Emacs concept, I presume.
>
> It is a concept I'm trying to persuade people
> to use *instead of* window groups.  I think
> that window groups are too complicated and that
> they add generality of dubious, perhaps negative
> utility.
>
> With the change I'm proposing, frames gain
> a new slot - a parent slot - whose value is
> either nil or another frame.   Elisp programs
> can *not* modify this slot arbitrarily.
>
> No frame with a non-nil parent slot can itself
> be parent to another frame (at least not initially)
> thus nesting is limited to one level.
>
> Frames with non-nil parent slots can be created as
> pop-ups that can be torn off.   Additionally, each
> frame with a nil parent slot has four children that
> share its same window system window.  (See my earlier
> message with the Subject line "16 (Re: ...)".)
>
> When a parent frame is minimized or deleted, it's
> child frames are also minimized or deleted.
>
> This is a cleaner way, imo, to accomplish what
> window groups are trying to accomplish.
>
> -t
>
>
>
>
>

-- 
Skickat från min mobila enhet

Re: Infrastructural complexity.

[Thomas Lord]

On Tue, 2009-07-21 at 11:39 +0200, martin rudalics wrote:

>  > One large difference, though, is that framelets really require
>  > more changes to the C code of Emacs while window groups can
>  > get away with little or 0 changes to the C code.  From some of the
>  > conversation, I suspect that this is one of the big reasons that
>  > there is support for window groups.

> to state that IMHO implementing window groups means to make considerably
> more changes to the C code than implementing framelets.

OK.  I misunderstood and thought that the (supposed) lack of 
need for C code was an advantage of the window groups
proposal but apparently not.

I'm pretty concerned about the impact window groups
have on existing abstractions.  For example, if groups
are used as "control panels" then they probably should
not be reachable by C-x o;  `next-frame' is more appropriate.
I'm not sure there is a good answer to whether or not window
group windows should appear in the return value of `buffer-list'.
I don't think window groups should resize the same way as
non-grouped windows when a non-group window is deleted.
I think the presence of window groups will make it more
difficult to improve the window configuration code.

Framelets have none of those problems.



> Emacs has overlays which can have a window property which can have the
> display engine handle the overlay differently when the property matches
> the window the overlay is displayed on.  When you tear off a window the
> identity of that window changes and you have to check all overlays in
> all buffers whether any window property should get updated accordingly.

I don't think that that's the case.  "Tear-offs" don't 
mean that you can grab any Emacs window and move it to 
its own frame.   "Tear-offs" are more limited than that:

In something like the Open Office diagram editor there
is a toolbar at the bottom of the screen.  If you click
on an item in that toolbar - say the icon of a filled 
rectangle - it's a lot like a menu:  a small pop-up appears
with choices for which kind of filled shape you wish to
draw (rectangle, elipse, etc).   You can pick an item off
of that menu OR you can "tear it off" and have that 
menu remain permanently visible.   A natural model for this
in Emacs is that the pop-up menu is a frame(let) the whole
time.   At no time, therefore, is there a need to change
the window property of overlays.

Saving and restoring window configurations is a separate
question entirely.   The "window property problem" does
come up again there, I guess.  Perhaps the solution for
that is to allow windows to have an "ID" slot which may be
bound to a symbol, and allow the window property of an 
overlay to be a symbol which may or may not mach the vale
of "ID".



>  > Since tear-off windows are not very important though, it doesn't really
>  > matter.  An implementation which creates a new Emacs window inside a new
>  > frame seems acceptable to me as well.  Or simply not having tear-off
>  > windows.

> ... or separate tool/menu/tabbars (unless the latter show up in the
> header lines).

Suppose that every frame and every Emacs window had (optional)
menu, toolbar, and tabbar lines.  These can be understood as
all variations on the same thing: they are a GUI interface to
current keymaps.   These optional lines could be on any of the
four edges of the window or frame.

Then a natural way to have "separate" forms of those is to
permit the creation of a detached framelet (a frame with
non-nil parent) and permit it to contain a single, 0-width
or 0-height Emacs window - so that the menu, tab, or tool-bar
is the only thing visible.

As a side effect of that design there would be a neat 
feature possible:  the 0-width or -height window could
be made non-0 width/height for the purpose of displaying
help text.   For example, typing C-h k and then mouse-clicking
on a toolbar icon could temporarily expand the invisible
window (making it visible) and put the help text there.

-t

Re: Infrastructural complexity.

[martin rudalics]

 > I'm pretty concerned about the impact window groups
 > have on existing abstractions.

None, hopefully.

 > For example, if groups
 > are used as "control panels" then they probably should
 > not be reachable by C-x o;  `next-frame' is more appropriate.

Keybindings are not part of the window group concept but of ECB.  Emacs
without ECB (or some other UI) continues to work as if there were no
groups at all.

 > I'm not sure there is a good answer to whether or not window
 > group windows should appear in the return value of `buffer-list'.

You mean `window-list'?  They won't appear there because this function
returns only life windows.  There would be an extra function that gets
you all active window groups.

 > I don't think window groups should resize the same way as
 > non-grouped windows when a non-group window is deleted.
 > I think the presence of window groups will make it more
 > difficult to improve the window configuration code.

Resizing windows must be rethought anyway.  Fortunately, window groups
do not add any additional complexity here.  Emacs worked with leaking
internal windows for quite some time.

 > Framelets have none of those problems.

But they don't solve the window resizing issues either ;-)

 > At no time, therefore, is there a need to change
 > the window property of overlays.

There is if we pretend that tearing off a window stands for "moving that
window from one frame to another".

 > Saving and restoring window configurations is a separate
 > question entirely.   The "window property problem" does
 > come up again there, I guess.  Perhaps the solution for
 > that is to allow windows to have an "ID" slot which may be
 > bound to a symbol, and allow the window property of an
 > overlay to be a symbol which may or may not mach the vale
 > of "ID".

This could work indeed, as well as some other form of aliases.  But I
don't want to think of specifying that.

 > Suppose that every frame and every Emacs window had (optional)
 > menu, toolbar, and tabbar lines.  These can be understood as
 > all variations on the same thing: they are a GUI interface to
 > current keymaps.   These optional lines could be on any of the
 > four edges of the window or frame.

Unfortunately bars are not lines, they vary in size and shape and create
all sorts of troubles for the display-engine.

 > Then a natural way to have "separate" forms of those is to
 > permit the creation of a detached framelet (a frame with
 > non-nil parent) and permit it to contain a single, 0-width
 > or 0-height Emacs window - so that the menu, tab, or tool-bar
 > is the only thing visible.

Just that the display-engine is not very good at displaying
0-width/0-height objects.  The window code has special checks to avoid
that windows get too small.

 > As a side effect of that design there would be a neat
 > feature possible:  the 0-width or -height window could
 > be made non-0 width/height for the purpose of displaying
 > help text.   For example, typing C-h k and then mouse-clicking
 > on a toolbar icon could temporarily expand the invisible
 > window (making it visible) and put the help text there.

I'm afraid I'll have to add 0-size windows to the list of objects that
require a frame-based solution.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Tue, 2009-07-21 at 19:25 +0200, martin rudalics wrote:
> > I'm pretty concerned about the impact window groups
>  > have on existing abstractions.
> 
> None, hopefully.
> 
>  > For example, if groups
>  > are used as "control panels" then they probably should
>  > not be reachable by C-x o;  `next-frame' is more appropriate.
> 
> Keybindings are not part of the window group concept but of ECB.  Emacs
> without ECB (or some other UI) continues to work as if there were no
> groups at all.


I don't understand that answer.  In the edit-area
of ECB I can display any buffer at all.  Aribtrary,
existing code can run there.   That arbitrary code
can call things like `window-list' only I don't 
see any right answer as to what window-list should
return vis a vis the grouped windows in the display.




>  > I'm not sure there is a good answer to whether or not window
>  > group windows should appear in the return value of `buffer-list'.
> 
> You mean `window-list'? 

Yes.  Sorry.

>  They won't appear there because this function
> returns only life windows.  There would be an extra function that gets
> you all active window groups.

That seems "weird".  For example, before the
existence of window groups the list of windows
returned by `window-list' always added up to 
a rectangle.   Looking at the list, you could
predict what, say, `window-at' would do.

After window groups, that implicit invariant is
gone.  What exactly will that break in existing
code?  I don't know - perhaps little or nothing
or perhaps something.  It does break the conceptual
simplicity of windows, though.




>  > I don't think window groups should resize the same way as
>  > non-grouped windows when a non-group window is deleted.
>  > I think the presence of window groups will make it more
>  > difficult to improve the window configuration code.

> Resizing windows must be rethought anyway.  Fortunately, window groups
> do not add any additional complexity here.  Emacs worked with leaking
> internal windows for quite some time.

The very idea that an Elisp program could delete
the edit area window seems dubious to me, not least
in that how the window groups get resized in 
response seems necessarily arbitrary and not useful.



>  > Framelets have none of those problems.

> But they don't solve the window resizing issues either ;-)

They do, actually.   Take that example again: killing
the edit area window.   In the framelet proposal 
you simply can't do that because it would be a case of
killing the sole ordinary window in a frame.



>  > At no time, therefore, is there a need to change
>  > the window property of overlays.

> There is if we pretend that tearing off a window stands for "moving that
> window from one frame to another".

OK, and that might or might not be useful functionality
to support but it is not what people mean by "tear-off"
in the context of other GUI toolkits - so it is
linguistically confusing.



>  > Saving and restoring window configurations is a separate
>  > question entirely.   The "window property problem" does
>  > come up again there, I guess.  Perhaps the solution for
>  > that is to allow windows to have an "ID" slot which may be
>  > bound to a symbol, and allow the window property of an
>  > overlay to be a symbol which may or may not mach the vale
>  > of "ID".

> This could work indeed, as well as some other form of aliases.  But I
> don't want to think of specifying that.

OK.  I think it's just: (window-id WIN) / (set-window-id WIN VALUE)
and a slightly more complicated conditional in the code that
compares an overlay's `window' property to a given window.

Then, of course, lots of elisp packages will stand in need
of improvement to use ids rather than raw windows for the
`window' property -- but that can be done incrementally.


>  > Suppose that every frame and every Emacs window had (optional)
>  > menu, toolbar, and tabbar lines.  These can be understood as
>  > all variations on the same thing: they are a GUI interface to
>  > current keymaps.   These optional lines could be on any of the
>  > four edges of the window or frame.

> Unfortunately bars are not lines, they vary in size and shape and create
> all sorts of troubles for the display-engine.

Do I correctly understand that the problem you
are most worried about concerns toolbars, tabbars,
and so forth in individual windows?

If so, doesn't existing support for header lines
already solve most of that problem?


>  > Then a natural way to have "separate" forms of those is to
>  > permit the creation of a detached framelet (a frame with
>  > non-nil parent) and permit it to contain a single, 0-width
>  > or 0-height Emacs window - so that the menu, tab, or tool-bar
>  > is the only thing visible.
> 
> Just that the display-engine is not very good at displaying
> 0-width/0-height objects.  The window code has special checks to avoid
> that windows get too small.

You wouldn't have 0-width AND 0-height.  For
a detached vertical toolbar, 0-width.  For horizontal,
0-height.   This would be new to the display engine
but it's not a huge new complexity - just a special
rule for the case of a free-floating framelet.


>  > As a side effect of that design there would be a neat
>  > feature possible:  the 0-width or -height window could
>  > be made non-0 width/height for the purpose of displaying
>  > help text.   For example, typing C-h k and then mouse-clicking
>  > on a toolbar icon could temporarily expand the invisible
>  > window (making it visible) and put the help text there.
> 
> I'm afraid I'll have to add 0-size windows to the list of objects that
> require a frame-based solution.

Alternatively, it could be a frame with a nil window
configuration which is also needed anyway for the four
framelets that surround the main edit area.

-t

Re: Infrastructural complexity.

[martin rudalics]

 >> Keybindings are not part of the window group concept but of ECB.  Emacs
 >> without ECB (or some other UI) continues to work as if there were no
 >> groups at all.
 >
 > I don't understand that answer.  In the edit-area
 > of ECB I can display any buffer at all.  Aribtrary,
 > existing code can run there.   That arbitrary code
 > can call things like `window-list' only I don't
 > see any right answer as to what window-list should
 > return vis a vis the grouped windows in the display.

The return value of `window-list' must not be affected by running ECB.
If, for some reason, ECB wants to filter out windows not belonging to a
group it has to do that separately.  But what I meant in my answer was
that the semantics of functions like `other-window' or
`delete-other-windows' don't change wrt current Emacs unless you run a
UI like ECB in which case `delete-other-windows' will only delete other
windows in the same group and `other-window' will only switch to another
window in the same group.  This behavior must be built into the
functions `delete-other-windows' and `other-window' but can be triggered
only by activating a client like ECB before.

 > That seems "weird".  For example, before the
 > existence of window groups the list of windows
 > returned by `window-list' always added up to
 > a rectangle.   Looking at the list, you could
 > predict what, say, `window-at' would do.

What makes you think it won't do that after adding window groups?

 > After window groups, that implicit invariant is
 > gone.  What exactly will that break in existing
 > code?  I don't know - perhaps little or nothing
 > or perhaps something.  It does break the conceptual
 > simplicity of windows, though.

As I tried to say before, window groups are completely transparent wrt
existing code.  If you don't run a client like ECB you won't notice them
(unless I can abuse window groups to fix some other bugs).

 > The very idea that an Elisp program could delete
 > the edit area window seems dubious to me, not least
 > in that how the window groups get resized in
 > response seems necessarily arbitrary and not useful.

I don't understand this - please elaborate.

 >> But they don't solve the window resizing issues either ;-)
 >
 > They do, actually.   Take that example again: killing
 > the edit area window.   In the framelet proposal
 > you simply can't do that because it would be a case of
 > killing the sole ordinary window in a frame.

You can always kill the frame.

 >>  > At no time, therefore, is there a need to change
 >>  > the window property of overlays.
 >
 >> There is if we pretend that tearing off a window stands for "moving that
 >> window from one frame to another".
 >
 > OK, and that might or might not be useful functionality
 > to support but it is not what people mean by "tear-off"
 > in the context of other GUI toolkits - so it is
 > linguistically confusing.

I meanwhile understand that tearing off a window is not what you had in
mind when you talked about "tear-offs" ;-)

 > OK.  I think it's just: (window-id WIN) / (set-window-id WIN VALUE)
 > and a slightly more complicated conditional in the code that
 > compares an overlay's `window' property to a given window.
 >
 > Then, of course, lots of elisp packages will stand in need
 > of improvement to use ids rather than raw windows for the
 > `window' property -- but that can be done incrementally.

Probably not many.  But we still don't solve the problem that
application programs temporarily store the identity of window just in
order to tell which window to use when one and the the same buffer is
simultaneously displayed in two or more windows.

 > Do I correctly understand that the problem you
 > are most worried about concerns toolbars, tabbars,
 > and so forth in individual windows?

Sort of.  My Emacs already does have considerable troubles fighting with
wrapping menubars.  I don't use toolbars so I can't tell about them but
IIRC there were a number of problems with wrapping toolbars.  Handling
such bars with narrow frames might be quite challenging.

 > If so, doesn't existing support for header lines
 > already solve most of that problem?

How would header lines emulate menu or toolbars?

 >> Just that the display-engine is not very good at displaying
 >> 0-width/0-height objects.  The window code has special checks to avoid
 >> that windows get too small.
 >
 > You wouldn't have 0-width AND 0-height.  For
 > a detached vertical toolbar, 0-width.  For horizontal,
 > 0-height.   This would be new to the display engine
 > but it's not a huge new complexity - just a special
 > rule for the case of a free-floating framelet.

FWIW, the display-engine already crashes when you give it a one-column
width window.

 > Alternatively, it could be a frame with a nil window
 > configuration which is also needed anyway for the four
 > framelets that surround the main edit area.

How do you visually address a frame with a nil window configuration?
All I know about windows I can't see is that I usually forget about them
and that they show up when I need them least.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Wed, 2009-07-22 at 12:12 +0200, martin rudalics wrote:

>  > That seems "weird".  For example, before the
>  > existence of window groups the list of windows
>  > returned by `window-list' always added up to
>  > a rectangle.   Looking at the list, you could
>  > predict what, say, `window-at' would do.
> 
> What makes you think it won't do that after adding window groups?


I've been told two contradictory things.

First I was told that `window-list' would,
by default, return only a list of windows within
one group.   Then, just now, you've told me that
`window-list' will return all the windows in a 
frame by default, regardless of their group.

If `window-list' returns (by default) only
windows within one group (or only windows not
in any group) then it can return a list of windows
that don't add up to a rectangle.

If `window-list' returns all windows, regardless
of group, then sure - they add up to a rectangle - 
but there are other problems.  For example, C-x o
will not DTRT.



>  > After window groups, that implicit invariant is
>  > gone.  What exactly will that break in existing
>  > code?  I don't know - perhaps little or nothing
>  > or perhaps something.  It does break the conceptual
>  > simplicity of windows, though.
> 
> As I tried to say before, window groups are completely transparent wrt
> existing code.  If you don't run a client like ECB you won't notice them
> (unless I can abuse window groups to fix some other bugs).


If no window groups are created there is no
problem, that's true.  If window groups are
created, then existing code is impacted by,
for example, the way that `window-list' has
no good answer to give.


>  > The very idea that an Elisp program could delete
>  > the edit area window seems dubious to me, not least
>  > in that how the window groups get resized in
>  > response seems necessarily arbitrary and not useful.

> I don't understand this - please elaborate.

Consider an ECB configuation like:
_______
| | e |
|_|___|
|_____|

where "e" is the edit area.  Killing that
window stretches the control panel on the
left to fill the entire frame.  Ick.  

More useful is to say that you can't kill
all the edit area windows.  If you try to 
kill the last edit area window, the error
is "can't delete sole remaining ordinary
window".   If you regard the edit area and
the control panels as separate frames (that
share a window system window) then this
restriction about deleting the last edit area
window falls out automatically.


>  >> But they don't solve the window resizing issues either ;-)
>  >
>  > They do, actually.   Take that example again: killing
>  > the edit area window.   In the framelet proposal
>  > you simply can't do that because it would be a case of
>  > killing the sole ordinary window in a frame.
> 
> You can always kill the frame.

I don't see how the ability to kill the frame 
fixes the breakage to C-x 0





>  >>  > At no time, therefore, is there a need to change
>  >>  > the window property of overlays.
>  >
>  >> There is if we pretend that tearing off a window stands for "moving that
>  >> window from one frame to another".
>  >
>  > OK, and that might or might not be useful functionality
>  > to support but it is not what people mean by "tear-off"
>  > in the context of other GUI toolkits - so it is
>  > linguistically confusing.
> 
> I meanwhile understand that tearing off a window is not what you had in
> mind when you talked about "tear-offs" ;-)

Yup.


>  > OK.  I think it's just: (window-id WIN) / (set-window-id WIN VALUE)
>  > and a slightly more complicated conditional in the code that
>  > compares an overlay's `window' property to a given window.
>  >
>  > Then, of course, lots of elisp packages will stand in need
>  > of improvement to use ids rather than raw windows for the
>  > `window' property -- but that can be done incrementally.
> 
> Probably not many.  But we still don't solve the problem that
> application programs temporarily store the identity of window just in
> order to tell which window to use when one and the the same buffer is
> simultaneously displayed in two or more windows.

Cloning a window configuration will confuse those,
yes, but the point of the `window-id' suggestion is
that it makes those programs trivial to fix for
cloned configurations.


>  > Do I correctly understand that the problem you
>  > are most worried about concerns toolbars, tabbars,
>  > and so forth in individual windows?
> 
> Sort of.  My Emacs already does have considerable troubles fighting with
> wrapping menubars.  I don't use toolbars so I can't tell about them but
> IIRC there were a number of problems with wrapping toolbars.  Handling
> such bars with narrow frames might be quite challenging.


If there are bugs in that area they ought to
be fixed anyway.


>  > If so, doesn't existing support for header lines
>  > already solve most of that problem?
> 
> How would header lines emulate menu or toolbars?

By permitting icons to display and by letting
different parts of the bar be mouse sensitive
in different ways.  By having an option to generate
the format of the bar from keymaps rather than from
an explicit format string.



>  >> Just that the display-engine is not very good at displaying
>  >> 0-width/0-height objects.  The window code has special checks to avoid
>  >> that windows get too small.
>  >
>  > You wouldn't have 0-width AND 0-height.  For
>  > a detached vertical toolbar, 0-width.  For horizontal,
>  > 0-height.   This would be new to the display engine
>  > but it's not a huge new complexity - just a special
>  > rule for the case of a free-floating framelet.
> 
> FWIW, the display-engine already crashes when you give it a one-column
> width window.

Sounds like a bug.   It would be better if, given
only one column, the display-engine left the window
blank or (on graphical terminals) grey-ed out.


>  > Alternatively, it could be a frame with a nil window
>  > configuration which is also needed anyway for the four
>  > framelets that surround the main edit area.
> 
> How do you visually address a frame with a nil window configuration?
> All I know about windows I can't see is that I usually forget about them
> and that they show up when I need them least.

I retract the idea of a nil window configuration
for tear-off windows - that's a mistake.

The four child frames around the edge of a normal
frame, though - the four control panel areas - can
have a nil configuration.  When they do, they are
invisible, not reached by `next-frame', and don't
appear in the frame list.

-t





> 
> martin

Re: Infrastructural complexity.

[martin rudalics]

 > I've been told two contradictory things.
 >
 > First I was told that `window-list' would,
 > by default, return only a list of windows within
 > one group.

When and where did I say that?

 > Then, just now, you've told me that
 > `window-list' will return all the windows in a
 > frame by default, regardless of their group.

`window-list' returns all _life_ windows on the selected (or specified)
frame and will continue to do so.  If someone wants to give additional
semantics to the FRAME argument we can do that but I see no great use to
it.

 > If `window-list' returns (by default) only
 > windows within one group (or only windows not
 > in any group) then it can return a list of windows
 > that don't add up to a rectangle.

If you read my proposal you would know that window groups always form
rectangles.  So even if `window-list' returned only windows within a
specific group these would add up to a rectangle.

 > If `window-list' returns all windows, regardless
 > of group, then sure - they add up to a rectangle -
 > but there are other problems.  For example, C-x o
 > will not DTRT.

`other-window' doesn't use `window-list'.  IF ECB is active
`other-window' will probably drop any window returned by `next-window'
if that window is not part of the current group.  But I never looked at
the implementation of `other-window' in ECB.

 > If no window groups are created there is no
 > problem, that's true.  If window groups are
 > created, then existing code is impacted by,
 > for example, the way that `window-list' has
 > no good answer to give.

No.  Window groups per se don't change the behavior of existing code.
ECB would do that.

 > Consider an ECB configuation like:
 > _______
 > | | e |
 > |_|___|
 > |_____|
 >
 > where "e" is the edit area.  Killing that
 > window stretches the control panel on the
 > left to fill the entire frame.  Ick.

Maybe, I don't know.  It might also kill the control panel or the entire
frame.

 > More useful is to say that you can't kill
 > all the edit area windows.  If you try to
 > kill the last edit area window, the error
 > is "can't delete sole remaining ordinary
 > window".   If you regard the edit area and
 > the control panels as separate frames (that
 > share a window system window) then this
 > restriction about deleting the last edit area
 > window falls out automatically.

Window groups don't know anything about edit areas.  We could specify
such semantics in window parameters, maybe.

 > I don't see how the ability to kill the frame
 > fixes the breakage to C-x 0

The semantics of what a window should display are not part of the window
groups concept.  This has to be built on top of them.

 > Cloning a window configuration will confuse those,
 > yes, but the point of the `window-id' suggestion is
 > that it makes those programs trivial to fix for
 > cloned configurations.

Cloning a window configuration is a separate issue because it will
create a copy of the original window.  The window property of an overlay
applies to the original window only and the question was whether that
window could be moved to another frame retaining its identity.

 >> Sort of.  My Emacs already does have considerable troubles fighting with
 >> wrapping menubars.  I don't use toolbars so I can't tell about them but
 >> IIRC there were a number of problems with wrapping toolbars.  Handling
 >> such bars with narrow frames might be quite challenging.
 >
 > If there are bugs in that area they ought to
 > be fixed anyway.

Yes, but that can take some time.  ISTR a bug where a wrapping menubar
caused the modeline to disappear.

 > By permitting icons to display and by letting
 > different parts of the bar be mouse sensitive
 > in different ways.  By having an option to generate
 > the format of the bar from keymaps rather than from
 > an explicit format string.

If someone writes that code we can continue discussing it.

 > Sounds like a bug.   It would be better if, given
 > only one column, the display-engine left the window
 > blank or (on graphical terminals) grey-ed out.

Maybe.  But you see some of the restrictions that apply.

 > The four child frames around the edge of a normal
 > frame, though - the four control panel areas - can
 > have a nil configuration.  When they do, they are
 > invisible, not reached by `next-frame', and don't
 > appear in the frame list.

So why have them exist at all?  One can always recreate them.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Wed, 2009-07-22 at 20:23 +0200, martin rudalics wrote:

> If you read my proposal you would know that window groups always form
> rectangles.  So even if `window-list' returned only windows within a
> specific group these would add up to a rectangle.

This is from your proposal:


(1) A window group is a collection of windows displayed within the root
    window of a frame.  For any window group there exists one designated
    window - the root window of that group.  A group root window is
    either the frame's root window or is a window whose parent window
    does not belong to any group (hence groups don't nest).  Every other
    window of a group is a subwindow of the group root window.  Internal
    windows of a group have at least two children (so a group contains
    at least two leaf windows).

So, I understand that to mean that I can twice
split a window horizontally:
_______
| | | |
| | | |
|_|_|_|

Then twice split the middle window:

_______
| |_| |
| |_| |
|_|_|_|

Then split the window in the center of
that and from the resulting two leaf windows
form a group.

Now the non-grouped windows in that frame
fail to add up to a rectangle.

Did I misunderstand something?

-t

Re: Infrastructural complexity.

[martin rudalics]

 >> If you read my proposal you would know that window groups always form
 >> rectangles.  So even if `window-list' returned only windows within a
 >> specific group these would add up to a rectangle.
 >
[...]
 > _______
 > | |_| |
 > | |_| |
 > |_|_|_|
 >
 > Then split the window in the center of
 > that and from the resulting two leaf windows
 > form a group.
 >
 > Now the non-grouped windows in that frame
 > fail to add up to a rectangle.
 >
 > Did I misunderstand something?

Not at all.  Only window groups are guaranteed to form rectangles.  I
never claimed that the remaining windows would add up to a rectangle.
And obviously you can't retrieve the remaining windows by calling
`window-list'.  You can subtract the windows in a window group from the
windows returned by `window-list' to get the "remaining" windows.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Thu, 2009-07-23 at 11:24 +0200, martin rudalics wrote:

>  > Did I misunderstand something?
> 
> Not at all.  Only window groups are guaranteed to form rectangles.  I
> never claimed that the remaining windows would add up to a rectangle.
> And obviously you can't retrieve the remaining windows by calling
> `window-list'.  You can subtract the windows in a window group from the
> windows returned by `window-list' to get the "remaining" windows.

That's a fine example of how window-groups
are not quite the right concept here.

I understand you to say that `window-list'
should (by default) return all of the windows,
grouped or not.   That won't DTRT in the use
cases of greatest interest - where "groups"
are supposed to be control panels around an
edit area.   Just the windows in the edit area
should be returned by default.

That is, it seems to me - and yes this is 
necessarily just an opinion about user 
interfaces - that the edit area windows 
should behave exactly like a traditional
Emacs frame.  For example, C-x o navigates
(normally) just among the edit area windows.
Normal splitting or deleting of a window changes
only edit area windows.  Programs that look for,
say, a largest window to use to pop up some
buffer should look only to the edit area (unless
explicitly written to do otherwise).  It should
take a special gesture (keystroke or mouse, different
from C-x o) to select a window in a control panel
and, once its selected the set of windows in that
control panel are then the focus (the C-x o ring,
etc.).

Emacs already has a way to segregate groups of
windows in that way: frames.   That's what
gives rise to the idea that control panels are
mostly just a new way to render certain frames.




-t

Re: Infrastructural complexity.

[joakim]

Thomas Lord <lord@emf.net> writes:

> On Thu, 2009-07-23 at 11:24 +0200, martin rudalics wrote:
>
>>  > Did I misunderstand something?
>> 
>> Not at all.  Only window groups are guaranteed to form rectangles.  I
>> never claimed that the remaining windows would add up to a rectangle.
>> And obviously you can't retrieve the remaining windows by calling
>> `window-list'.  You can subtract the windows in a window group from the
>> windows returned by `window-list' to get the "remaining" windows.
>
> That's a fine example of how window-groups
> are not quite the right concept here.
>
> I understand you to say that `window-list'
> should (by default) return all of the windows,
> grouped or not.   That won't DTRT in the use
> cases of greatest interest - where "groups"
> are supposed to be control panels around an
> edit area.   Just the windows in the edit area
> should be returned by default.
>
> That is, it seems to me - and yes this is 
> necessarily just an opinion about user 
> interfaces - that the edit area windows 
> should behave exactly like a traditional
> Emacs frame.  For example, C-x o navigates
> (normally) just among the edit area windows.
> Normal splitting or deleting of a window changes
> only edit area windows.  Programs that look for,
> say, a largest window to use to pop up some
> buffer should look only to the edit area (unless
> explicitly written to do otherwise).  It should
> take a special gesture (keystroke or mouse, different
> from C-x o) to select a window in a control panel
> and, once its selected the set of windows in that
> control panel are then the focus (the C-x o ring,
> etc.).

The way I see window groups, they behave like you describe.

I have, however, lost track of this thread, so I might probably miss
something.

>
> Emacs already has a way to segregate groups of
> windows in that way: frames.   That's what
> gives rise to the idea that control panels are
> mostly just a new way to render certain frames.
>
>
>
>
> -t
>
-- 
Joakim Verona

Re: Infrastructural complexity.

[Lennart Borgman]

On Thu, Jul 23, 2009 at 9:17 PM, <joakim@verona.se> wrote:

>> That is, it seems to me - and yes this is
>> necessarily just an opinion about user
>> interfaces - that the edit area windows
>> should behave exactly like a traditional
>> Emacs frame.  For example, C-x o navigates
>> (normally) just among the edit area windows.
>> Normal splitting or deleting of a window changes
>> only edit area windows.  Programs that look for,
>> say, a largest window to use to pop up some
>> buffer should look only to the edit area (unless
>> explicitly written to do otherwise).  It should
>> take a special gesture (keystroke or mouse, different
>> from C-x o) to select a window in a control panel
>> and, once its selected the set of windows in that
>> control panel are then the focus (the C-x o ring,
>> etc.).
>
> The way I see window groups, they behave like you describe.


I think there is one more part of Thomas suggestion: that there should
be default framelets/window groups at each frame border (the 16
configs).

It might be a good idea that they are there by default. ECB for
example works according to a similar visual model.

One way to make it simple to implement that idea could be to have
hidden windows corresponding to those framelets (ie the framelets
should live inside them). That way iit could be easy to hide/show them
and one could make a set of function for handling them.

But then we need to have hidden windows though, but that does not seem
fantastically difficult. At least not to me that never tried to look
at that code ...

Re: Infrastructural complexity.

[joakim]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Thu, Jul 23, 2009 at 9:17 PM, <joakim@verona.se> wrote:
>
>>> That is, it seems to me - and yes this is
>>> necessarily just an opinion about user
>>> interfaces - that the edit area windows
>>> should behave exactly like a traditional
>>> Emacs frame.  For example, C-x o navigates
>>> (normally) just among the edit area windows.
>>> Normal splitting or deleting of a window changes
>>> only edit area windows.  Programs that look for,
>>> say, a largest window to use to pop up some
>>> buffer should look only to the edit area (unless
>>> explicitly written to do otherwise).  It should
>>> take a special gesture (keystroke or mouse, different
>>> from C-x o) to select a window in a control panel
>>> and, once its selected the set of windows in that
>>> control panel are then the focus (the C-x o ring,
>>> etc.).
>>
>> The way I see window groups, they behave like you describe.
>
>
> I think there is one more part of Thomas suggestion: that there should
> be default framelets/window groups at each frame border (the 16
> configs).

In my view that sort of functionality goes on top of window groups.
Framelets could go on top of window groups, and ECB on top of
Framelets.

There are 2 proposals for window groups, mine and Martins(which is
probably more advanced than mine). I initialy just wanted to be able to
"pin" windows, so they werent affected by c-x 1 and stuff like that. I
really just wanted a small window to hold the information the mode-line
normaly is misused to hold. So I wanted something lighter than a
frame. Oh wait, thats a framelet :)

Anyway, blue sky visions of what Emacs could do is good.

Looking at actual code that implements nearly everything of the blue sky
visions is also good. 


> It might be a good idea that they are there by default. ECB for
> example works according to a similar visual model.
>
> One way to make it simple to implement that idea could be to have
> hidden windows corresponding to those framelets (ie the framelets
> should live inside them). That way iit could be easy to hide/show them
> and one could make a set of function for handling them.
>
> But then we need to have hidden windows though, but that does not seem
> fantastically difficult. At least not to me that never tried to look
> at that code ...
>
>
-- 
Joakim Verona

Re: Infrastructural complexity.

[Stefan Monnier]

> There are 2 proposals for window groups, mine and Martins(which is
> probably more advanced than mine).  I initialy just wanted to be able
> to "pin" windows, so they werent affected by c-x 1 and stuff like
> that.  I really just wanted a small window to hold the information the
> mode-line normaly is misused to hold.  So I wanted something lighter
> than a frame. Oh wait, thats a framelet :)

I still believe also that tab-bars (and tool-bar as well) could/should
be implement(ed|able) in Elisp as "normal windows".  Such windows
obviously need a special treatment and are bound/related to some other
window (or window-tree).  You could think of them as being in
a top-framelet, but I also would like to be able to have tab-bars and
tool-bars attached to individual windows rather than to frames, so it
would appear to be necessary to handle such special windows appearing
not just on the border of a frame.

For this reason, I think that Thomas's proposal is too limited.


        Stefan

Re: Infrastructural complexity.

[Thomas Lord]

On Thu, 2009-07-23 at 21:08 -0400, Stefan Monnier wrote:
> > There are 2 proposals for window groups, mine and Martins(which is
> > probably more advanced than mine).  I initialy just wanted to be able
> > to "pin" windows, so they werent affected by c-x 1 and stuff like
> > that.  I really just wanted a small window to hold the information the
> > mode-line normaly is misused to hold.  So I wanted something lighter
> > than a frame. Oh wait, thats a framelet :)
> 
> I still believe also that tab-bars (and tool-bar as well) could/should
> be implement(ed|able) in Elisp as "normal windows".  

Please no!

They certainly shouldn't be C-x o material.  They shouldn't
be kill-buffer or switch-buffer material.  They ain't 
normal windows.

Menu bars are kinda sorta a view and controller over
keymaps.... shouldn't frame and window tab bars be the
same?


> Such windows
> obviously need a special treatment 

Which is sign of a mistake in design.


> and are bound/related to some other
> window (or window-tree).  You could think of them as being in
> a top-framelet, but I also would like to be able to have tab-bars and
> tool-bars attached to individual windows rather than to frames, so it
> would appear to be necessary to handle such special windows appearing
> not just on the border of a frame.
> 
> For this reason, I think that Thomas's proposal is too limited.
> 
> 
>         Stefan


Could you say more about that.  I'd like to hash 
this out with you because afaict i have a butt simple
aggregate of proposals that cover the use cases 
very nicely without screwing with existing abstractions.
Maybe(?) take this off list between us for a few 
exchanges and then report back?

-t

Re: Infrastructural complexity.

[martin rudalics]

 > One way to make it simple to implement that idea could be to have
 > hidden windows

I suppose you mean hidden frames here.  I suppose there won't be a way
to hide individual Emacs windows ever.

 > corresponding to those framelets (ie the framelets
 > should live inside them). That way iit could be easy to hide/show them
 > and one could make a set of function for handling them.
 >
 > But then we need to have hidden windows though, but that does not seem
 > fantastically difficult. At least not to me that never tried to look
 > at that code ...

Hiding a frame is certainly much simpler than making it zero width.

martin

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 24, 2009 at 10:28 AM, martin rudalics<rudalics@gmx.at> wrote:
>> One way to make it simple to implement that idea could be to have
>> hidden windows
>
> I suppose you mean hidden frames here.  I suppose there won't be a way
> to hide individual Emacs windows ever.


No, I mean hidden windows.

The reason I am proposing it is that it would be a convenient way to
hide/show framelets (ie window groups wich are placed along a frame
border.

As an example consider ECBs windows. There is currently a command in
ECB to hide/show them today. That could be implemented by
hiding/showing a window group.

That window group could be there always for applications to use. It
should not show up by default, but when an application asked for it.
Similar window groups could be there along the other frame borders.

To implement the visual structure that Thomas proposed there have to
be several of them, of course, but it is possible to do it this way.


But I am not sure about the merit of my own proposal here. There was a
suggestion long ago to be able to split the root window that I think
maybe could fullfill nearly the same requirements. The idea of hidden
windows just seem easy to me. Why don't you think we should hide
windows? Is there something that is difficult with it code wise or
conceptually?

Re: Infrastructural complexity.

[martin rudalics]

 > As an example consider ECBs windows. There is currently a command in
 > ECB to hide/show them today. That could be implemented by
 > hiding/showing a window group.

ECB does this by saving a window configuration, deleting the respective
windows, and resurrecting the saved configuration when the user wants
the windows to show up again.  Resurrection occurs procedurally, that is
by recursively splitting the root window of a frame.

 > That window group could be there always for applications to use. It
 > should not show up by default, but when an application asked for it.
 > Similar window groups could be there along the other frame borders.
 >
 > To implement the visual structure that Thomas proposed there have to
 > be several of them, of course, but it is possible to do it this way.

There's no problem doing that the way sketched above.  I'm skeptical
about hiding windows by giving them zero height or width, though.

 > But I am not sure about the merit of my own proposal here. There was a
 > suggestion long ago to be able to split the root window that I think
 > maybe could fullfill nearly the same requirements.

My code can split any root window (or any group root window) and clone
any saved window group into any of the two emanating halves.  And it
does not need to split windows to accomplish that.

 > The idea of hidden
 > windows just seem easy to me. Why don't you think we should hide
 > windows? Is there something that is difficult with it code wise or
 > conceptually?

The window handling code would almost certainly tolerate zero height or
width windows (although we might need some precautions to avoid that
thousands of such windows accumulate on a frame).  The UI would have to
give some help on how such windows can be resurrected.  Also, we would
have to decide whether, for example, a window of height zero can be
split vertically .

The current display-code would almost certainly choke when it's given a
window with zero size. So what you have to do is find someone who
certifies that zero size windows can be handled by the display-engine.

But as I said I can always remove a window group from its frame, save
it, and later put it into another internal or life window.  The
additional frame resizing code when a window group that spans an entire
side of that frame is removed would have to be written but that seems
fairly straightforward.

martin

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 24, 2009 at 2:10 PM, martin rudalics<rudalics@gmx.at> wrote:
>> As an example consider ECBs windows. There is currently a command in
>> ECB to hide/show them today. That could be implemented by
>> hiding/showing a window group.
>
> ECB does this by saving a window configuration, deleting the respective
> windows, and resurrecting the saved configuration when the user wants
> the windows to show up again.  Resurrection occurs procedurally, that is
> by recursively splitting the root window of a frame.


Yes, maybe that is the best way, I am not sure.


> There's no problem doing that the way sketched above.  I'm skeptical
> about hiding windows by giving them zero height or width, though.


I did not mean giving the zero height ot width. That would be
confusing. I meant visibility as a new property.


> My code can split any root window (or any group root window) and clone
> any saved window group into any of the two emanating halves.  And it
> does not need to split windows to accomplish that.


That sounds very good. To throw away that part of my code in winsav.el
I would need three more things:

- Rotate
- Transpose

and

> The
> additional frame resizing code when a window group that spans an entire
> side of that frame is removed would have to be written but that seems
> fairly straightforward.

- Resizing.

Actually the reszing code when putting back a window tree in winsav
was one of the most frustrating pieces of code I have written because
it had to fight what the C code was doing. I think the resizing code
is one of those pieces that should be written in C. It should be much
more simple there (the logic I mean ...).

AW: Infrastructural complexity.

[klaus.berndl]

Without following the complete discussion i chip in now because ECB is mentioned and window-groups...

IMHO currently there is a "missing link" (well, probably not the right wording but currently i have nothing better in my mind) between a window and ist containing frame, namely the mentioned window-groups: a frame contains at least one window-group and a window-group contains at least one window.

Especially for applications like ECB this would be a great help because such IDEs devide the frame in several window groups (e.g. with ECB: one group contains the special browsing windows, one the editing-windows, one the compile-output-window) which in turn can contain arbitrary windows.

With such a window-group concept several things should/could be possible:
- preventing a group from being be deleted by C-x 1 (AFAIK currently
  there is something going on to achieve this with a new window-flag,
  IIRC implemented by Joakim for the next release 24.X?!)
- hiding (ie. deleting) a window-group (ie. all it's windows but no others
  from outside the group)
- saving the window-configuration of exactly one group and restoring only this
  window-group (if a frame allocates needed space)
- rewriting display-buffer so only a certain window-group can be
  used for displaying a buffer - or the other direction: a window-group can
  be prevented from being used by display-buffer for buffer display
- etc...

IMHO such a general window-group concept between the frame- and the window-
concept would alleviate writing a tool like ECB (and would make a lot of its
advices obsolete or at least much simpler)

This is the point of view of the author and maintainer of ECB ;-)

Maybe it's offtopic for the original thread (i have not followed it), so feel
free to ignore it for this discussion or reopen a new discussion...

Regards
Klaus

-----Ursprüngliche Nachricht-----
Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org [mailto:emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org] Im Auftrag von Lennart Borgman
Gesendet: Freitag, 24. Juli 2009 16:21
An: martin rudalics
Cc: Thomas Lord; rms@gnu.org; cyd@stupidchicken.com; joakim@verona.se; emacs-devel@gnu.org; juri@jurta.org; monnier@iro.umontreal.ca; acm@muc.de; drew.adams@oracle.com; Miles Bader
Betreff: Re: Infrastructural complexity.

On Fri, Jul 24, 2009 at 2:10 PM, martin rudalics<rudalics@gmx.at> wrote:
>> As an example consider ECBs windows. There is currently a command in 
>> ECB to hide/show them today. That could be implemented by 
>> hiding/showing a window group.
>
> ECB does this by saving a window configuration, deleting the 
> respective windows, and resurrecting the saved configuration when the 
> user wants the windows to show up again.  Resurrection occurs 
> procedurally, that is by recursively splitting the root window of a frame.


Yes, maybe that is the best way, I am not sure.


> There's no problem doing that the way sketched above.  I'm skeptical 
> about hiding windows by giving them zero height or width, though.


I did not mean giving the zero height ot width. That would be confusing. I meant visibility as a new property.


> My code can split any root window (or any group root window) and clone 
> any saved window group into any of the two emanating halves.  And it 
> does not need to split windows to accomplish that.


That sounds very good. To throw away that part of my code in winsav.el I would need three more things:

- Rotate
- Transpose

and

> The
> additional frame resizing code when a window group that spans an 
> entire side of that frame is removed would have to be written but that 
> seems fairly straightforward.

- Resizing.

Actually the reszing code when putting back a window tree in winsav was one of the most frustrating pieces of code I have written because it had to fight what the C code was doing. I think the resizing code is one of those pieces that should be written in C. It should be much more simple there (the logic I mean ...).

Re: AW: Infrastructural complexity.

[martin rudalics]

 > With such a window-group concept several things should/could be possible:
 > - preventing a group from being be deleted by C-x 1 (AFAIK currently
 >   there is something going on to achieve this with a new window-flag,

This would be done with a window parameter of the internal window group
window (that parameter would have to be installed by ECB to become
effective) and an appropriate change of `delete-other-windows'.  BTW, I
suppose you mean that C-x 1 invoked within a window belonging to a
window group just deletes all other windows of that group?

 >   IIRC implemented by Joakim for the next release 24.X?!)
 > - hiding (ie. deleting) a window-group (ie. all it's windows but no others
 >   from outside the group)

Here this is simply `delete-window' applied to the internal window
constituting the group (some other window must be left on the frame to
make this happen).

 > - saving the window-configuration of exactly one group and restoring only this
 >   window-group (if a frame allocates needed space)

I suppose you mean saving the group configuration, that is, windows not
belonging to the group are not saved.  This can be done and you can
restore them in an arbitrary window (like the root window of a frame or
an arbitrary other window).

 > - rewriting display-buffer so only a certain window-group can be
 >   used for displaying a buffer - or the other direction: a window-group can
 >   be prevented from being used by display-buffer for buffer display

The "other direction" solution will be preferred, probably.  This means
a slight change in testing whether a window `display-buffer' chooses can
really be used.

 > - etc...
 >
 > IMHO such a general window-group concept between the frame- and the window-
 > concept would alleviate writing a tool like ECB (and would make a lot of its
 > advices obsolete or at least much simpler)

I suppose we must get rid of all advices.

 > This is the point of view of the author and maintainer of ECB ;-)

The more complete the list of issues you sketched above gets, the better
I can try to address these issues early enough.

martin

Re: AW: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-24 at 16:55 +0200, klaus.berndl@capgemini-sdm.com wrote:
> This is the point of view of the author and maintainer of ECB ;-)
> 
> Maybe it's offtopic for the original thread (i have not followed it),
> so feel
> free to ignore it for this discussion or reopen a new discussion...


The debate is really about how best to define what
a "window group" is.

One school of thought says that a "window group" is
something entirely new - a new concept.  The other 
school of thought says that "window groups" already
exist - they're called "frames".

Something like ECB's displays, if we understand
window groups as frames, would be implemented by
having multiple frames that tile a single window
system window (or that tile a text terminal display).
Right now a text terminal or a window system window
is always one frame but, with "framelets", that would
change.

-t

AW: AW: Infrastructural complexity.

[klaus.berndl]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

>The debate is really about how best to define what
>a "window group" is.

>One school of thought says that a "window group" is
>something entirely new - a new concept.  The other 
>school of thought says that "window groups" already
>exist - they're called "frames".

>Something like ECB's displays, if we understand
>window groups as frames, would be implemented by
>having multiple frames that tile a single window
>system window (or that tile a text terminal display).
>Right now a text terminal or a window system window
>is always one frame but, with "framelets", that would
>change.

well, these "framelets" sound good, very good - this is exactly 
what i meant with the window-group-concept described in my 
last posting. 

I don't care about the naming of that concepts, which tiles
a single window system window (or that tile a text terminal
display), IMHO "framelet" is as good as "window-group" would be.
But i'm convinced that we need a concept between the "a window system
window is exactly one frame" and an emacs-window... otherwise
writing something like ECB without heavily advicing Emacs is quite
impossible

i will try to abstract a requirement specification what is
exactly needed by ECB to throw away all of it's "kernel"-advices
(apart from that - often very small - advices which are needed
to achieve compatibility to other packages which have own "window-
managements"...)

Klaus


-t




[-- Attachment #2: Type: text/html, Size: 2147 bytes --]

Re: AW: AW: Infrastructural complexity.

[Miles Bader]

<klaus.berndl@capgemini-sdm.com> writes:
> But i'm convinced that we need a concept between the "a window system
> window is exactly one frame" and an emacs-window... otherwise
> writing something like ECB without heavily advicing Emacs is quite
> impossible

That's not true -- it's quite possible to simply modify the behavior of
Emacs internal windows appropriately.

Personally I think Tom's framelets seem too complex, and at the same
time overly limited in functionality.

-Miles

-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: AW: AW: Infrastructural complexity.

[Thomas Lord]

On Sat, 2009-07-25 at 17:06 +0900, Miles Bader wrote:

> Personally I think Tom's framelets seem too complex, and at the same
> time overly limited in functionality.

How so?

My thought re complexity is it is much simpler
to not  complicate windows and window configs:
they are plenty touchy already.

Re generality, the "four frames around 
edit area" is an arbitrary limit, sure.
It could be done that way.  Alternatively,
throw in your favorite, general purpose
tiling layout engine.  Whichever is easier,
I guess.

-t

Re: Infrastructural complexity.

[martin rudalics]

 > I did not mean giving the zero height ot width. That would be
 > confusing. I meant visibility as a new property.

Whose going to handle that property?  The display-engine?

 > - Rotate
 > - Transpose

What's the precise semantics of these operations?  Which window
variables should be changed?  I suppose what you mean is shuffling
around the buffers displayed in those windows.

 > - Resizing.
 >
 > Actually the reszing code when putting back a window tree in winsav
 > was one of the most frustrating pieces of code I have written because
 > it had to fight what the C code was doing. I think the resizing code
 > is one of those pieces that should be written in C. It should be much
 > more simple there (the logic I mean ...).

The resizing logic is the most difficult one (IMHO also due to the fact
that Emacs is allowed to delete windows when they get to small).  What's
worse is that in most cases resizing operations are not reversible.
That is, starting from an initial configuration, enlarging some window
first and shrinking it by the same amount afterwards often won't get you
back to the initial configuration.  However, resizing is a problem ECB
users should have got used to.  IIRC they can always refetch a specific
configuration from a set of saved ones.

martin

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 24, 2009 at 6:08 PM, martin rudalics<rudalics@gmx.at> wrote:
>> I did not mean giving the zero height ot width. That would be
>> confusing. I meant visibility as a new property.
>
> Whose going to handle that property?  The display-engine?


I do not know how it is implemented so I can't say exactly how. What I
mean is that they should be handled by those part as they did not
exist. (That of course means for example jumping over them in some
lists etc.)


>> - Rotate
>> - Transpose
>
> What's the precise semantics of these operations?  Which window
> variables should be changed?  I suppose what you mean is shuffling
> around the buffers displayed in those windows.


Rotating the visual window structure. Transposing the visual window structure.

Buffers should move with the windows (visulally).


>> - Resizing.
>>
>> Actually the reszing code when putting back a window tree in winsav
>> was one of the most frustrating pieces of code I have written because
>> it had to fight what the C code was doing. I think the resizing code
>> is one of those pieces that should be written in C. It should be much
>> more simple there (the logic I mean ...).
>
> The resizing logic is the most difficult one (IMHO also due to the fact
> that Emacs is allowed to delete windows when they get to small).  What's
> worse is that in most cases resizing operations are not reversible.
> That is, starting from an initial configuration, enlarging some window
> first and shrinking it by the same amount afterwards often won't get you
> back to the initial configuration.  However, resizing is a problem ECB
> users should have got used to.  IIRC they can always refetch a specific
> configuration from a set of saved ones.


In that case there are code in winsav.el for it.

Re: Infrastructural complexity.

[martin rudalics]

 >> Whose going to handle that property?  The display-engine?
 >
 > I do not know how it is implemented so I can't say exactly how. What I
 > mean is that they should be handled by those part as they did not
 > exist. (That of course means for example jumping over them in some
 > lists etc.)

That is you don't want to display these windows _and_ they should not be
returned by `window-list' either.  I suppose that such things would have
to be emulated by deleting windows and restoring saved configurations.

 > Rotating the visual window structure. Transposing the visual window structure.

These would be possible only within certain well-behaved window
configurations.  Hardly something for basic window handling routines.

martin

Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 24, 2009 at 7:13 PM, martin rudalics<rudalics@gmx.at> wrote:
>>> Whose going to handle that property?  The display-engine?
>>
>> I do not know how it is implemented so I can't say exactly how. What I
>> mean is that they should be handled by those part as they did not
>> exist. (That of course means for example jumping over them in some
>> lists etc.)
>
> That is you don't want to display these windows _and_ they should not be
> returned by `window-list' either.  I suppose that such things would have
> to be emulated by deleting windows and restoring saved configurations.


This can of course be done by just jumping over them. If that is worth
the effort is another matter.


>> Rotating the visual window structure. Transposing the visual window
>> structure.
>
> These would be possible only within certain well-behaved window
> configurations.  Hardly something for basic window handling routines.


Are there really any well-behaved window configuration when it comes
to rezising? Why should it be different when rotating or transposing?

I think they are easy to do once you have resizing code, but (I forgot
that before) they are really not possible without that.

I actually use these operations sometimes, but not very often. So
maybe they are not really worth the effort. (And they are already
available in winsav.el anyway.)

Re: Infrastructural complexity.

[martin rudalics]

 > This can of course be done by just jumping over them. If that is worth
 > the effort is another matter.

If you want the display-engine just jump over invisible windows, you
have to discuss that with someone familiar with the display code.

 >>> Rotating the visual window structure. Transposing the visual window
 >>> structure.
 >> These would be possible only within certain well-behaved window
 >> configurations.  Hardly something for basic window handling routines.
 >
 > Are there really any well-behaved window configuration when it comes
 > to rezising? Why should it be different when rotating or transposing?

I don't know how you would rotate a configuration like

  ----------------
|      |         |
|      |         |
|------|         |
|      |         |
|      |         |
  ----------------

and why people should want to do that.  Or do you mean to rotate the
frame by 90 degrees?

I occasionally do flip the contents of two equally sized side-by-side
windows, for example, when diffing revisions.  That's mainly because of
my way of reading things from left to right connotes the idea that
something in a left-hand window is older than something in a window on
the right.  So while I agree that transposing two windows around a
common axis can be interesting, I have no use case for rotating windows.

martin

Re: Infrastructural complexity.

[martin rudalics]

 > I understand you to say that `window-list'
 > should (by default) return all of the windows,
 > grouped or not.   That won't DTRT in the use
 > cases of greatest interest - where "groups"
 > are supposed to be control panels around an
 > edit area.   Just the windows in the edit area
 > should be returned by default.

The basic semantics of `window-list', namely that of returning all life
windows must be unchanged.  I suppose nobody wants to restrict the value
returned by `buffer-list' to the buffers controlled by a specific
application only.

 > Emacs already has a way to segregate groups of
 > windows in that way: frames.   That's what
 > gives rise to the idea that control panels are
 > mostly just a new way to render certain frames.

Frames still don't give you any means to control where `display-buffer'
is going to display a buffer.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-24 at 10:28 +0200, martin rudalics wrote:

> The basic semantics of `window-list', namely that of returning all life
> windows must be unchanged. 

I agree.  That is part of why I'd like to see
separate frames rather than window-groups.


>  I suppose nobody wants to restrict the value
> returned by `buffer-list' to the buffers controlled by a specific
> application only.

I agree with that as well but with a caveat.
While I dislike "window groups" I think Emacs
would benefit from the introduction of "buffer
groups" and from a frame property that says 
which buffer group is preferred there.  For example,
one "buffer group" might be `control-panels'.
Commands that switch buffers would be biased to,
by default, switch only to buffers in the 
buffer group of the current frame.  This is a
generalization of the existing notion of 
"internal" buffers.



>  > Emacs already has a way to segregate groups of
>  > windows in that way: frames.   That's what
>  > gives rise to the idea that control panels are
>  > mostly just a new way to render certain frames.

> Frames still don't give you any means to control where `display-buffer'
> is going to display a buffer.

I don't see any problem with adding special rules
to `display-buffer' so that it treats framelets (frames
with a non-nil parent slot) specially.  Do you?

-t

Re: Infrastructural complexity.

[martin rudalics]

 >> The basic semantics of `window-list', namely that of returning all life
 >> windows must be unchanged.
 >
 > I agree.  That is part of why I'd like to see
 > separate frames rather than window-groups.

But then we run into the problem again that most people consider
separate frames a non-starter.

 > I agree with that as well but with a caveat.
 > While I dislike "window groups" I think Emacs
 > would benefit from the introduction of "buffer
 > groups" and from a frame property that says
 > which buffer group is preferred there.  For example,
 > one "buffer group" might be `control-panels'.
 > Commands that switch buffers would be biased to,
 > by default, switch only to buffers in the
 > buffer group of the current frame.  This is a
 > generalization of the existing notion of
 > "internal" buffers.

There's already some flair of this in `same-window-buffer-names' and
`same-window-regexps'.  We could do similar things for window groups and
frames.

 >> Frames still don't give you any means to control where `display-buffer'
 >> is going to display a buffer.
 >
 > I don't see any problem with adding special rules
 > to `display-buffer' so that it treats framelets (frames
 > with a non-nil parent slot) specially.  Do you?

`display-buffer' can easily _avoid_ using a specific window for
displaying a buffer.  It's less good at _preferring_ a specific window
for that purpose.  This should change though.

martin

Re: Infrastructural complexity.

[Stefan Monnier]

>> I agree.  That is part of why I'd like to see
>> separate frames rather than window-groups.

> But then we run into the problem again that most people consider
> separate frames a non-starter.

I think there's a misunderstanding here: the non-starter idea is
"separate top-level WM windows".  Having several "frames" within the same
top-level WM-window is perfectly OK.  After all, it's just another way
to look at window-groups.


        Stefan

Re: Infrastructural complexity.

[martin rudalics]

 > I think there's a misunderstanding here: the non-starter idea is
 > "separate top-level WM windows".  Having several "frames" within the same
 > top-level WM-window is perfectly OK.  After all, it's just another way
 > to look at window-groups.

In my understanding a window group is the abstraction of an object we're
using every day - an internal window.  A frame embedded within a frame
is something whose internal representation we would have to specify and
code first.

martin

Re: Infrastructural complexity.

[Stefan Monnier]

>> I think there's a misunderstanding here: the non-starter idea is
>> "separate top-level WM windows".  Having several "frames" within the same
>> top-level WM-window is perfectly OK.  After all, it's just another way
>> to look at window-groups.

> In my understanding a window group is the abstraction of an object we're
> using every day - an internal window.

That's one view, indeed.

> A frame embedded within a frame is something whose internal
> representation we would have to specify and code first.

Think about it: take a frame, split it into 5 windows, then mark those
5 as "frame(let)s" aka "window-groups".


        Stefan

Re: Infrastructural complexity.

[martin rudalics]

 >> A frame embedded within a frame is something whose internal
 >> representation we would have to specify and code first.
 >
 > Think about it: take a frame, split it into 5 windows, then mark those
 > 5 as "frame(let)s" aka "window-groups".

We'd still have to specify such objects (I suppose they would get first
class rating like buffers or windows) decide how they are allowed to
tile a frame (which would be mostly a copy of the window making,
splitting, and deleting code) and provide some hooks for the window
management code to work (alternatively?) within a framelet or a frame.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Sun, 2009-07-26 at 17:14 +0200, martin rudalics wrote:

> We'd still have to specify such objects (I suppose they would get first
> class rating like buffers or windows)

They are frames.  Frames are modified to have a 
`parent' slot which may be nil or may be a
frame that itself has a nil `parent'.



>  decide how they are allowed to
> tile a frame 

Yes.  I have one possibility that seems to cover
all of the use cases people commonly want, but
there are other ways to do it, certainly.


> (which would be mostly a copy of the window making,
> splitting, and deleting code) 

Maybe.  There are other possibilities.  
It could also be done with something like
the layout engines found in some GUI 
toolkits.


> and provide some hooks for the window
> management code to work (alternatively?)
> within a framelet or a frame.


It's not clear that much or any changes to
window code would be needed.  Perhaps 
some changes to `display-buffer';  perhaps
some changes to `buffer-list' that kind
of thing.  These would be ways for an elisp
program to limit which buffers are likely to
be displayed in framelets that are used as control 
panels.

-t






> martin

Re: Infrastructural complexity.

[martin rudalics]

 > They are frames.  Frames are modified to have a
 > `parent' slot which may be nil or may be a
 > frame that itself has a nil `parent'.

Then you have to rewrite the frame management code in addition to the
window management code.  For example, the semantics of both `next-frame'
and `next-window' would change.

 >>  decide how they are allowed to
 >> tile a frame
 >
 > Yes.  I have one possibility that seems to cover
 > all of the use cases people commonly want, but
 > there are other ways to do it, certainly.
 >
 >> (which would be mostly a copy of the window making,
 >> splitting, and deleting code)
 >
 > Maybe.  There are other possibilities.
 > It could also be done with something like
 > the layout engines found in some GUI
 > toolkits.

These would have to be rewritten and adapted accordingly.

 > It's not clear that much or any changes to
 > window code would be needed.  Perhaps
 > some changes to `display-buffer';  perhaps
 > some changes to `buffer-list' that kind
 > of thing.  These would be ways for an elisp
 > program to limit which buffers are likely to
 > be displayed in framelets that are used as control
 > panels.

`buffer-list' is not part of the window management code.  But what would
`window-frame' return?  What would the `frame-root-window' of the
`window-frame' of a window be?  Or `selected-frame'?

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Sun, 2009-07-26 at 19:45 +0200, martin rudalics wrote:
> > They are frames.  Frames are modified to have a
>  > `parent' slot which may be nil or may be a
>  > frame that itself has a nil `parent'.

> Then you have to rewrite the frame management code in addition to the
> window management code.  For example, the semantics of both `next-frame'
> and `next-window' would change.

It might be desirable - though probably not
necessary - to *tweak* `next-frame' in a 
small way.

Why would you change `next-window'?  Is it
that you want C-x o to jump from edit area
windows to control panels and back again?
Maybe `next-frame', maybe a new command.
Leaving `next-window' alone means that the
edit area can act like "Emacs classic" with
the control panels serving as a new way
to invoke commands that effect the 
window and buffer currently selected in 
the edit area.




>  >>  decide how they are allowed to
>  >> tile a frame
>  >
>  > Yes.  I have one possibility that seems to cover
>  > all of the use cases people commonly want, but
>  > there are other ways to do it, certainly.
>  >
>  >> (which would be mostly a copy of the window making,
>  >> splitting, and deleting code)
>  >
>  > Maybe.  There are other possibilities.
>  > It could also be done with something like
>  > the layout engines found in some GUI
>  > toolkits.
> 
> These would have to be rewritten and adapted accordingly.

It shouldn't be very much code.


>  > It's not clear that much or any changes to
>  > window code would be needed.  Perhaps
>  > some changes to `display-buffer';  perhaps
>  > some changes to `buffer-list' that kind
>  > of thing.  These would be ways for an elisp
>  > program to limit which buffers are likely to
>  > be displayed in framelets that are used as control
>  > panels.
> 
> `buffer-list' is not part of the window management code.  But what would
> `window-frame' return? 


The containing frame(let), just as it does
now.   Control panel modes - for use in 
buffers displayed in control panels - can
use a new function in some cases:

    (defun window-parent-frame (w)
       (if (frame-parent (window-frame w))
            (frame-parent (window-frame w))
          (window-frame w)))



>  What would the `frame-root-window' of the
> `window-frame' of a window be?  Or `selected-frame'?

The root window of the frame, just as it is
now.   Control panel modes could use, in some
cases, (frame-root-window (window-parent-frame))

-t






> martin

Re: Infrastructural complexity.

[martin rudalics]

 > Why would you change `next-window'?  Is it
 > that you want C-x o to jump from edit area
 > windows to control panels and back again?

`next-window' has a MINIBUF and an ALL-FRAMES argument.  I'm not sure
whether and how their semantics would change with nested frames.

 >>  >>  decide how they are allowed to
 >>  >> tile a frame
 >>  >
 >>  > Yes.  I have one possibility that seems to cover
 >>  > all of the use cases people commonly want, but
 >>  > there are other ways to do it, certainly.
 >>  >
 >>  >> (which would be mostly a copy of the window making,
 >>  >> splitting, and deleting code)
 >>  >
 >>  > Maybe.  There are other possibilities.
 >>  > It could also be done with something like
 >>  > the layout engines found in some GUI
 >>  > toolkits.
 >>
 >> These would have to be rewritten and adapted accordingly.
 >
 > It shouldn't be very much code.

Fine.  This might also help frame resizing code DTRT in general.

 >> But what would
 >> `window-frame' return?
 >
 >
 > The containing frame(let), just as it does
 > now.   Control panel modes - for use in
 > buffers displayed in control panels - can
 > use a new function in some cases:
 >
 >     (defun window-parent-frame (w)
 >        (if (frame-parent (window-frame w))
 >             (frame-parent (window-frame w))
 >           (window-frame w)))
 >
 >
 >
 >>  What would the `frame-root-window' of the
 >> `window-frame' of a window be?  Or `selected-frame'?
 >
 > The root window of the frame, just as it is
 > now.   Control panel modes could use, in some
 > cases, (frame-root-window (window-parent-frame))

Maybe it would be simpler to call framelets just frames and the "outer"
(nil-parent) frame something different so there would be no changes in
the naming conventions.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Mon, 2009-07-27 at 08:40 +0200, martin rudalics wrote:

> `next-window' has a MINIBUF and an ALL-FRAMES argument.  I'm not sure
> whether and how their semantics would change with nested frames.

Ok.  One interesting case might be `compare-windows', 
as follows:

* Current behavior

  I've two visible frames, one window each - I run
  `compare-windows'.  The comparison will be
  between the two windows in the visible frames.

* After behavior

  With no changes to `next-window', assume that 
  I have two frames.  In each frame there is but
  one edit-area window.  However, the selected frame
  also has a visible control panel frame.  One of
  the two visible edit areas is the current window.
  Depending on where in the frame list the 
  control panel is, `compare-windows' might compare
  the two edit area windows or it might compare an
  edit area window to a control panel window.

At first glance, that sounds bad and, in that sense,
you have a good point.  Where I think you're off is
in the notion to fix that by changing `next-window'.

The problem is that sometimes it will be The Right
Thing to compare the two edit area windows and other
times it will be TRT to compare an edit area window
with a control panel window.  It really depends on
what the user wants to do and on what is displayed
in each window.

The order of windows per `next-window' can't 
depend on "what the user means when invoking
the current command".   That is why `compare-windows'
already contains two calls to `next-window'
with various parameters.  It calls `next-window'
one way and finds out if the result "makes sense"
for the `compare-windows' function.  If not, it
tries calling `next-window' a different way and
again checks if the result "makes sense".

My conclusion is that IF users are unhappy with
what `compare-windows' does after control panels
are introduced, then it is `compare-windows'
rather than `next-window' that has to change.
And that's a big IF, it's not a forgone conclusion
that people will be unhappy with the interaction
of control panels and the existing `compare-windows'
code.  Note that nothing about "framelets" vs. 
"window groups" changes this conclusion: with EITHER
approach, the question of whether and how to 
modify the window-selection logic in `compare-windows'
still comes up.

Another function with similar issues would be
`server-switch-buffer'.  If the default logic
for selecting a window in which to display the
buffer requested via the server returns a 
minibuffer window, `next-window' is used 
to find a better window.   It is conceivable
that it might wind up picking a control
panel window when an edit area window is
more desirable.  (Equally conceivable that
a control panel window might be more desirable.)
However, the existing logic in `server-switch-buffer'
to honor `window-dedicated-p' looks as if it
would handle this case properly, provided that
programs `set-window-dedicated' for control 
panel windows that shouldn't be casually re-used.

In any event, there is no single change to 
`next-window' that would DTRT for all cases
of either `compare-windows' or `server-switch-buffer'
and no change to `next-window' that would be 
right for both functions.   It looks more like
IF, in practice, the default behaviors of those
functions have to change then the logic in those
functions themselves has to change.

>  >>  > Maybe.  There are other possibilities.
>  >>  > It could also be done with something like
>  >>  > the layout engines found in some GUI
>  >>  > toolkits.
>  >>
>  >> These would have to be rewritten and adapted accordingly.
>  >
>  > It shouldn't be very much code.
> 
> Fine.  This might also help frame resizing code DTRT in general.

I'm not sure what problem with frame resizing
you are referring to but, ok.

> Maybe it would be simpler to call framelets just frames and the "outer"
> (nil-parent) frame something different so there would be no changes in
> the naming conventions.

I don't want to confuse this immediate discussion
with new names for the same thing but...

I would say they are all simply "frames".  

Perhaps a good name for a frame with a nil
parent is a "primary frame".   One with a 
non-nil parent is an "attached frame".

(frame-p a-primary-frame) => t
(frame-p an-attached-frame) => t

(frame-attached-p primary) => nil
(frame-attached-p attached) => a-primary-frame

Analogous to `window-dedicated-p' but
with no corresponding `set-*' function
(yet?).

-t

Re: Infrastructural complexity.

[martin rudalics]

 > I'm not sure what problem with frame resizing
 > you are referring to but, ok.

Currently frame widths and heights can be only full columns and lines.
I suppose you have to "fix" this limitation when you want to tile a
frame into subframes.

 > I don't want to confuse this immediate discussion
 > with new names for the same thing but...
 >
 > I would say they are all simply "frames".
 >
 > Perhaps a good name for a frame with a nil
 > parent is a "primary frame".   One with a
 > non-nil parent is an "attached frame".

I'd consider a primary frame an artifact useful for tiling and for
giving the window manager something with a title, a menubar, and a
handler for resize requests to play around.  Nothing more.

martin

RE: Infrastructural complexity.

[Drew Adams]

> Currently frame widths and heights can be only full columns and lines.
> I suppose you have to "fix" this limitation when you want to tile a
> frame into subframes.

Dunno if it helps here (probably not), but I have code that tiles (normal)
frames horizontally or vertically across/down the screen. The char-size
precision limitation you mention is not, at least for that application,
noticeable in practice. But I can see why it might matter more for "internal"
frames, which must fit exactly. FWIW, the code is here (commands
`tile-frames-*'):

http://www.emacswiki.org/emacs/frame-cmds.el

Re: Infrastructural complexity.

[martin rudalics]

 >> Currently frame widths and heights can be only full columns and lines.
 >> I suppose you have to "fix" this limitation when you want to tile a
 >> frame into subframes.
 >
 > Dunno if it helps here (probably not), but I have code that tiles (normal)
 > frames horizontally or vertically across/down the screen. The char-size
 > precision limitation you mention is not, at least for that application,
 > noticeable in practice. But I can see why it might matter more for "internal"
 > frames, which must fit exactly.

I recall distracting gaps with Emacs 21 somewhere in the minibuffer,
especially when using maximized frames.

 > FWIW, the code is here (commands
 > `tile-frames-*'):
 >
 > http://www.emacswiki.org/emacs/frame-cmds.el

Interesting.  But doesn't `tile-frames' tile in one direction only?
BTW, do you enlarge frames when changing fonts?  What are your
experiences with window manager interventions when using such layed-out
frames?

martin

RE: Infrastructural complexity.

[Drew Adams]

>  > FWIW, the code is here (commands `tile-frames-*'):
>  >
>  > http://www.emacswiki.org/emacs/frame-cmds.el
> 
> Interesting.  But doesn't `tile-frames' tile in one direction only?

Yes, horizontally _or_ vertically; not both at once.

> BTW, do you enlarge frames when changing fonts?

If you're referring to `enlarge-font', yes.

But I use my library `zoom-frm.el', with commands `zoom-in' and `zoom-out'. They
let you zoom either by enlarging/shrinking the frame font (a la `enlarge-font')
or the buffer text (a la `text-scale-decrease' - Emacs 23 only). `C-u' acts as a
toggle between the two modes.

In the first case (`enlarge-font'), yes, the frame size changes with the font
size.

And for the text-scaling mode, I use the patch I sent to the list (with zero
response), which automatically adjusts the window or frame size to accommodate
the font-size change. But that resizing is controlled by a user option. 

http://www.emacswiki.org/emacs/face-remap%2b.el - user option to control whether
window/frame resizes to reflect font size change

http://www.emacswiki.org/emacs/SetFonts#ChangingFontSize - description of my
font resizing stuff (zoom-frm.el, frame-cmds.el, face-remap+.el).

> What are your experiences with window manager interventions
> when using such layed-out frames?

Sorry, dunno what you mean. I use MS Windows - dunno about other window mgrs.
What kind of interventions did you have in mind?

Re: Infrastructural complexity.

[martin rudalics]

 >> Interesting.  But doesn't `tile-frames' tile in one direction only?
 >
 > Yes, horizontally _or_ vertically; not both at once.

Too bad.  I suppose Thomas wants them both at the same time.

 >> BTW, do you enlarge frames when changing fonts?
 >
 > If you're referring to `enlarge-font', yes.
 >
 > But I use my library `zoom-frm.el', with commands `zoom-in' and `zoom-out'. They
 > let you zoom either by enlarging/shrinking the frame font (a la `enlarge-font')
 > or the buffer text (a la `text-scale-decrease' - Emacs 23 only). `C-u' acts as a
 > toggle between the two modes.
 >
 > In the first case (`enlarge-font'), yes, the frame size changes with the font
 > size.

So you probably can't assure that two frames displayed above each other
match the height of another frame displayed on the side of them.  This
is the problem that a frame layout mechanism has to solve.  We do need
functions like `set-frame-pixel-height' and `set-frame-pixel-width'.

 > And for the text-scaling mode, I use the patch I sent to the list (with zero
 > response), which automatically adjusts the window or frame size to accommodate
 > the font-size change. But that resizing is controlled by a user option.
 >
 > http://www.emacswiki.org/emacs/face-remap%2b.el - user option to control whether
 > window/frame resizes to reflect font size change
 >
 > http://www.emacswiki.org/emacs/SetFonts#ChangingFontSize - description of my
 > font resizing stuff (zoom-frm.el, frame-cmds.el, face-remap+.el).

I have to admit that I'm not interested in frame resizing functions as
long as the the current line/columns restrictions prevail.  I simply use
one maximized frame all the time (which is not perfect either but I try
to not look at the echo-area too often).

 >> What are your experiences with window manager interventions
 >> when using such layed-out frames?
 >
 > Sorry, dunno what you mean. I use MS Windows - dunno about other window mgrs.
 > What kind of interventions did you have in mind?

I meant how window manager interventions like displaying/deleting the
windows of other applications can affect the layout of your Emacs
frames.  I suppose they don't.  So at least on Windows the problem of a
window manager interfering with the layout of individual Emacs frames
doesn't seem to exist ;-)

martin

RE: Infrastructural complexity.

[Drew Adams]

>  >> What are your experiences with window manager interventions
>  >> when using such layed-out frames?
>  >
>  > Sorry, dunno what you mean. I use MS Windows - dunno about 
>  > other window mgrs. What kind of interventions did you have in mind?
> 
> I meant how window manager interventions like displaying/deleting the
> windows of other applications can affect the layout of your Emacs
> frames.  I suppose they don't.  So at least on Windows the 
> problem of a window manager interfering with the layout of individual
> Emacs frames doesn't seem to exist ;-)

No, at least I've never noticed such problems.

The only thing I see sometimes, with Emacs 23, is that an Emacs frame will, out
of the blue (i.e. when using some other app), suddenly be raised to the front
occasionally. Dunno what causes that, or whether it has anything to do with the
window mgr. It could be some Emacs 23 problem in connection with some of my code
somehow - no idea.

In any case, I've never seen the Emacs frame layout get changed, other than
changes I make to it explicitly, myself. What kind of window mgr does something
horrible like that? ;-)

Re: Infrastructural complexity.

[martin rudalics]

 > The only thing I see sometimes, with Emacs 23, is that an Emacs frame will, out
 > of the blue (i.e. when using some other app), suddenly be raised to the front
 > occasionally. Dunno what causes that, or whether it has anything to do with the
 > window mgr. It could be some Emacs 23 problem in connection with some of my code
 > somehow - no idea.

You could try to have `select-frame-set-input-focus' write a backtrace
to a separate buffer whenever it gets called and inspect that buffer
whenever a frame gets raised spontaneously.

 > In any case, I've never seen the Emacs frame layout get changed, other than
 > changes I make to it explicitly, myself. What kind of window mgr does something
 > horrible like that? ;-)

Tiling window mangers.  They don't have another choice.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Mon, 2009-07-27 at 18:53 +0200, martin rudalics wrote:

>  > I would say they are all simply "frames".

>  > Perhaps a good name for a frame with a nil
>  > parent is a "primary frame".   One with a
>  > non-nil parent is an "attached frame".

> I'd consider a primary frame an artifact useful for tiling and for
> giving the window manager something with a title, a menubar, and a
> handler for resize requests to play around.  Nothing more.

I think a primary frame should also have the "edit area".
That is, not every Emacs window exists within an "attached
frame" - some exist within primary frames.

That's based on the use cases for these features.
The "edit area" conceptually corresponds to the frame
which represents the entire window system window.

For example, if an elisp programs hides the selected
frame and the selected frame is a control panel, then
just that control panel is hidden.  If the program
hides the frame from the edit area, that should minimize
the window system window and thereby effectively hide
all attached frames (control panels).

-t

Re: Infrastructural complexity.

[martin rudalics]

 >> I'd consider a primary frame an artifact useful for tiling and for
 >> giving the window manager something with a title, a menubar, and a
 >> handler for resize requests to play around.  Nothing more.
 >
 > I think a primary frame should also have the "edit area".
 > That is, not every Emacs window exists within an "attached
 > frame" - some exist within primary frames.

It wouldn't be too difficult to make Emacs windows only exist within
"attached frames" aka as frames.  The "primary frame" aka as something
that isn't even called a frame would then simply serve as container for
at least one and sometimes more attached frames.  Whatever we have to
pay for this in storage space can be made up by the fact that if we
implement both primary and attached frames within the current frame
concept, many slots in a frame structure (like glyph pools and matrices,
face caches, and the like) remain _conceptually_ unused for one of them.

 > That's based on the use cases for these features.
 > The "edit area" conceptually corresponds to the frame
 > which represents the entire window system window.
 >
 > For example, if an elisp programs hides the selected
 > frame and the selected frame is a control panel, then
 > just that control panel is hidden.

I suppose hiding a control panel would affect the appearance of the
containing primary frame.

 > If the program
 > hides the frame from the edit area, that should minimize
 > the window system window and thereby effectively hide
 > all attached frames (control panels).

That would be the simple case.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Tue, 2009-07-28 at 09:38 +0200, martin rudalics wrote:
> >> I'd consider a primary frame an artifact useful for tiling and for
>  >> giving the window manager something with a title, a menubar, and a
>  >> handler for resize requests to play around.  Nothing more.
>  >
>  > I think a primary frame should also have the "edit area".
>  > That is, not every Emacs window exists within an "attached
>  > frame" - some exist within primary frames.
> 
> It wouldn't be too difficult to make Emacs windows only exist within
> "attached frames" aka as frames. 


I agree that that would not be difficult.  
I think, however, that that would be a mistake
in the design.  In every window system window
there should be a set of Emacs windows for which
the selected frame corresponds to the window
system window.  If one of those Emacs windows
is selected then minimizing the corresponding
frame (etc.) should have its effect on the window
system window (and by extension on any "attached
frames").

The "edit area" frame should, at least from
the perspective of elisp and interactive 
commands, be "the frame which corresponds to 
the window system window".   



>  > That's based on the use cases for these features.
>  > The "edit area" conceptually corresponds to the frame
>  > which represents the entire window system window.
>  >
>  > For example, if an elisp programs hides the selected
>  > frame and the selected frame is a control panel, then
>  > just that control panel is hidden.
> 
> I suppose hiding a control panel would affect the appearance of the
> containing primary frame.

Yes.  It would contract the control panel, enlarging
the other attached frames and/or the edit area.  
There are two sets of diagrams in my "16" messages
from a ways back.  The second set of diagrams (second
message) illustrates.



>  > If the program
>  > hides the frame from the edit area, that should minimize
>  > the window system window and thereby effectively hide
>  > all attached frames (control panels).
> 
> That would be the simple case.

Minimizing the frame from the edit area minimizes
the attached frames and changes the window system
window.  Minimizing an attached frame just changes 
the visibility of that attached frame within a 
window system window, leaving the window system window
otherwise unaffected.

-t


> martin

Re: Infrastructural complexity.

[martin rudalics]

 >> It wouldn't be too difficult to make Emacs windows only exist within
 >> "attached frames" aka as frames.
 >
 > I agree that that would not be difficult.
 > I think, however, that that would be a mistake
 > in the design.  In every window system window
 > there should be a set of Emacs windows for which
 > the selected frame corresponds to the window
 > system window.  If one of those Emacs windows
 > is selected then minimizing the corresponding
 > frame (etc.) should have its effect on the window
 > system window (and by extension on any "attached
 > frames").

The `window-frame' of any window would be an attached frame that has an
associated primary window aka window-system window.  Why would that be a
mistake in the design?

 > The "edit area" frame should, at least from
 > the perspective of elisp and interactive
 > commands, be "the frame which corresponds to
 > the window system window".

If the edit-area frame is an attached frame it doesn't correspond to a
window-system window.  If it's a primary frame the size of its windows
don't sum up to its size.  What am I missing?

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Wed, 2009-07-29 at 11:06 +0200, martin rudalics wrote:
> >> It wouldn't be too difficult to make Emacs windows only exist within
>  >> "attached frames" aka as frames.
>  >
>  > I agree that that would not be difficult.
>  > I think, however, that that would be a mistake
>  > in the design.  In every window system window
>  > there should be a set of Emacs windows for which
>  > the selected frame corresponds to the window
>  > system window.  If one of those Emacs windows
>  > is selected then minimizing the corresponding
>  > frame (etc.) should have its effect on the window
>  > system window (and by extension on any "attached
>  > frames").
> 
> The `window-frame' of any window would be an attached frame that has an
> associated primary window aka window-system window.  Why would that be a
> mistake in the design?

Let's talk it through.  Perhaps you can change
my mind though I still think it is a mistake.

In your system, a window system window corresponds
to a frame for which most properties are ignored.
The edit area and all control panels are separate
frames, nested in that outer frame.

In mine, the edit area frame is the frame of
the window system window while the control 
panels are separate frames, nested in that 
edit area frame.

Consider a command like `delete-frame'.

If invoked within a control panel, we'd like 
it to kill the windows in the control panel
and make the control panel invisible.  (Perhaps
its frame object is then a dead frame or perhaps
not.)

If invoked in the edit area, we'd like it to 
kill all of the frames found within the window 
system window, and for that window system window
to go away.

How can differences like that most naturally be 
explained?  I think it's by making the window system
window frame and the edit area frame one in the same
thing.

Similarly, let's suppose that in a control panel
I turn on the toolbar.  We want the toolbar to appear
in just that control panel.

On the other hand, turning on a toolbar in the edit
area should create a toolbar that runs across the
entire window system window.

So, again, it's natural to identify the edit area
frame with the window system window frame.



>  > The "edit area" frame should, at least from
>  > the perspective of elisp and interactive
>  > commands, be "the frame which corresponds to
>  > the window system window".

> If the edit-area frame is an attached frame it doesn't correspond to a
> window-system window.  If it's a primary frame the size of its windows
> don't sum up to its size.  What am I missing?

It doesn't sum to the size of the frame, that's true.
Isn't it already the case, however, that the window
widths and heights don't necessarily add up to the 
full size of the frame?  What are you worried about?

-t




> martin

Re: Infrastructural complexity.

[martin rudalics]

 > It doesn't sum to the size of the frame, that's true.
 > Isn't it already the case, however, that the window
 > widths and heights don't necessarily add up to the
 > full size of the frame?  What are you worried about?

For example `window-full-width-p' is currently calculated as

#define WINDOW_FULL_WIDTH_P(W) \
   (WINDOW_TOTAL_COLS (W) == FRAME_TOTAL_COLS (WINDOW_XFRAME (W)))

This would fail with your approach when invoked on a window in the edit
area.  We'd probably have to redefine it by asking whether that window
is as wide as the root window of its frame.  But such things haven't
been investigated on a wide scale yet and we'd also have to cope with
the somewhat paradoxical situation that the root window of a frame is no
longer as wide as the containing frame.

You haven't yet sketched the details of how your approach would handle
things like `set-frame-position' or `set-frame-size'.  IIUC you have to
intercept these functions in some sense to handle the case where someone
wants to move or resize an attached frame.  I also have no idea how
functions that let a user resize attached frames with the mouse and how
mouse tracking in general will be implemented with nested frames.

For example, if in your

_______
|_|_|_|    template
|_|_|_|
|_|_|_|

I have the two attached frames named 1 and 2 as this:

_______
|_|_|1|    template
|_|_|2|
|_|_|_|

What happens if I "move" the imaginary border between 1 and 2 up or down
(provided I can do that at all).  Does that also resize the edit area?

Also an application might want to know whether the coordinates returned
by `mouse-position' refer to the upper-left corner of the edit area or
the primary frame.  If they refer to the upper-left corner of the
primary frame, we probably have to, for each primary frame, specify the
offset of the root window of that frame (the upper-left corner of the
edit area) in order to be able to determine in which window of the edit
area the mouse is (provided the edit area can be split).

OTOH how would `set-mouse-position' invoked on a primary frame interpret
its X Y arguments?  Could this move the mouse to an attached frame?

I understand that you are mostly concerned with user visible functions
like `delete-frame' or `other-frame' DTRT without changing them.  But
having `delete-frame' DTRT wrt whether its argument is the edit area or
an(other) attached frame is trivial.  If you specify that a primary
frame can't live without an edit area, it goes without saying that if
you delete the attached frame constituting the edit area, this will
delete the containing primary frame too.

Changing the underlying functions is the hard thing.  If you eventually
come up with a sketch of how you want to address issues like the ones I
sketched above I might be able to tell you more.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Thu, 2009-07-30 at 11:07 +0200, martin rudalics wrote:
> > It doesn't sum to the size of the frame, that's true.
>  > Isn't it already the case, however, that the window
>  > widths and heights don't necessarily add up to the
>  > full size of the frame?  What are you worried about?

> For example `window-full-width-p' is currently calculated as

> #define WINDOW_FULL_WIDTH_P(W) \
>    (WINDOW_TOTAL_COLS (W) == FRAME_TOTAL_COLS (WINDOW_XFRAME (W)))

> This would fail with your approach when invoked on a window in the edit
> area.  We'd probably have to redefine it by asking whether that window
> is as wide as the root window of its frame.  But such things haven't
> been investigated on a wide scale yet and we'd also have to cope with
> the somewhat paradoxical situation that the root window of a frame is no
> longer as wide as the containing frame.


Suppose that the edit area contains a
window that is the full width of the edit
area but that there are control panels to
the left and right.

Would it not DTRT to, for that window, count
the space taken by the control panels as "fringe"?
That is to say that the TOTAL_COLS of the 
edit area window would match the total width
of its (whole window system window) frame. There
would be largish "fringe".  It would so happen
that the attached frames are drawn in that fringe.



> You haven't yet sketched the details of how your approach would handle
> things like `set-frame-position' or `set-frame-size'.  IIUC you have to
> intercept these functions in some sense to handle the case where someone
> wants to move or resize an attached frame.  I also have no idea how
> functions that let a user resize attached frames with the mouse and how
> mouse tracking in general will be implemented with nested frames.
> 
> For example, if in your
> 
> _______
> |_|_|_|    template
> |_|_|_|
> |_|_|_|
> 
> I have the two attached frames named 1 and 2 as this:
> 
> _______
> |_|_|1|    template
> |_|_|2|
> |_|_|_|


That's a misunderstanding of the diagrams.
To get from the template to an actual configuration
of attached frames you must erase one line
segment of the two between each vertex of the
central square and the outer square.  You should
be left with four rectangles around the side 
surrounding the edit area in the middle.  There
are 16 ways to make those erasures.  That said,
however, your questions stand so let's go
over them:

Repositioning an attached frame should either
do nothing or signal an error.  An error is
probably preferable.

Resizing an attached frame should also cause
bordering attached frames and the edit area to
resize.  Resizing an attached frame should be
constrained to not exceed the size of the containing
frame, not make the edit area too small, and not
underflow the size of the containing frame.
(For comparison, try setting frame size to 1000x1000:
the frame size is actually set to something smaller
that fits.)

Mouse control of attached frame size:  Draw
attached frames with internal borders and 
let clicks on them generate a new event type,
e.g., FRAMELET-HORIZ-BORDER, analogous to
mode-line events.



> What happens if I "move" the imaginary border between 1 and 2 up or down
> (provided I can do that at all).  Does that also resize the edit area?

Changing the size of a control panel can change the
size of the edit area but with a constraint that it
can not make the edit area (or any control panel)
"too small".


> Also an application might want to know whether the coordinates returned
> by `mouse-position' refer to the upper-left corner of the edit area or
> the primary frame.  If they refer to the upper-left corner of the
> primary frame, we probably have to, for each primary frame, specify the
> offset of the root window of that frame (the upper-left corner of the
> edit area) in order to be able to determine in which window of the edit
> area the mouse is (provided the edit area can be split).

Again, I don't see why "fringe" doesn't already
handle this.


> OTOH how would `set-mouse-position' invoked on a primary frame interpret
> its X Y arguments?  Could this move the mouse to an attached frame?

Same answer: fringe.   The (0,0) position is the
character cell in the upper left corner of the 
text box of the upper left Emacs window of the
edit area.


> I understand that you are mostly concerned with user visible functions
> like `delete-frame' or `other-frame' DTRT without changing them.  But
> having `delete-frame' DTRT wrt whether its argument is the edit area or
> an(other) attached frame is trivial.  If you specify that a primary
> frame can't live without an edit area, it goes without saying that if
> you delete the attached frame constituting the edit area, this will
> delete the containing primary frame too.

I don't see why there should be distinct first class
frame objects in elisp for the window-system-window
and the edit area.   If it is helpful to have two
frame structures internally, for implementation,
then so be it but from elisp just the one frame
that corresponds to the edit area is enough.


> Changing the underlying functions is the hard thing.  If you eventually
> come up with a sketch of how you want to address issues like the ones I
> sketched above I might be able to tell you more.

Well, there you go.

-t

Re: Infrastructural complexity.

[martin rudalics]

 > Suppose that the edit area contains a
 > window that is the full width of the edit
 > area but that there are control panels to
 > the left and right.
 >
 > Would it not DTRT to, for that window, count
 > the space taken by the control panels as "fringe"?
 > That is to say that the TOTAL_COLS of the
 > edit area window would match the total width
 > of its (whole window system window) frame. There
 > would be largish "fringe".  It would so happen
 > that the attached frames are drawn in that fringe.

Mixing concepts like frames, windows and fringes is beyond my
imagination.

 >> Also an application might want to know whether the coordinates returned
 >> by `mouse-position' refer to the upper-left corner of the edit area or
 >> the primary frame.  If they refer to the upper-left corner of the
 >> primary frame, we probably have to, for each primary frame, specify the
 >> offset of the root window of that frame (the upper-left corner of the
 >> edit area) in order to be able to determine in which window of the edit
 >> area the mouse is (provided the edit area can be split).
 >
 > Again, I don't see why "fringe" doesn't already
 > handle this.

I don't see why and how it does.

 >> Changing the underlying functions is the hard thing.  If you eventually
 >> come up with a sketch of how you want to address issues like the ones I
 >> sketched above I might be able to tell you more.
 >
 > Well, there you go.

Sorry, that's too much Infrastructural complexity for my taste so I
shall give up here.  You'll have to talk this over with someone else.

martin

Re: Infrastructural complexity.

[Thomas Lord]

Martin,

Thank you for the time you've taken.  I, at least,
found your input helpful (see below).

On Fri, 2009-07-31 at 11:08 +0200, martin rudalics wrote:

> Mixing concepts like frames, windows and fringes is beyond my
> imagination.

FWIW, it's a simple point.  You raised concern
that if the edit area is regarded as the same
frame as the frame that owns the window system
window, full width edit area windows won't be as
wide as the frame.  I pointed out that that the
redisplay code already has support for that
situation in the form of fringes.  (That answers
the question for width.  I'm less certain how
height works out.)

>  > Again, I don't see why "fringe" doesn't already
>  > handle this.

> I don't see why and how it does.

You asked how a macro that checks to see if
a window is full width would work and I 
explained how it might work with minimal 
changes to the redisplay engine.

> Sorry, that's too much Infrastructural complexity for my taste so I
> shall give up here.  You'll have to talk this over with someone else.

Please feel no need to apologize.

Again, allow me to thank you for the time you
took and especially for your pointed question 
about the full width window macro.  That question
helped orient me better towards the relevant redisplay
code.

Not to perpetuate an argument but just to sum up
my view, for what it's worth:

At the elisp and command level, one of two concepts must bear
the brunt of newly added complexity: frames or windows.

Windows are already the more complicated abstraction.
They are the more venerable.  They are the more commonly
encountered at the command level.  Window configurations
are an area ripe for improvement and complicating windows
for the sake of control panels will make that improvement
harder.

Frames are a simpler abstraction upon which less relies.
The command set encourages fewer, weaker assumptions by
users about how frames work.

So, adding the new complexity mainly to frames seems
a better idea.  It better fits the mental model that
users already have.  It better preserves some of the 
longest lasting and most successful parts of the elisp
interface.

Additionally, it has been mentioned that if we have
"window groups", there will follow desire to make them
visually distinct.   It seems to me that this will introduce
a mechanism isomorphic to frame properties, and yet
strangely, arbitrarily distinct from frame properties.

Additionally, in "other applications", control panels
often have elements such as toolbars - just as do
Emacs frames.   Having used such applications, I'm inclined
to think that that's a nice feature.  Adding toolbar
support to window groups would be another way in which
the question arises: "Why aren't these frames?  Isn't
this a redundant abstraction?"

I can think of but one advantage to window groups 
instead of attached frames and that is simply that
*initially* window groups can probably be implemented 
without touching the redisplay code.   That is not a 
small advantage, I'm sure.   The price for claiming that
advantage seems a bit too high, to me.

-t

Re: Infrastructural complexity.

[martin rudalics]

 > Frames are a simpler abstraction upon which less relies.
 > The command set encourages fewer, weaker assumptions by
 > users about how frames work.
 >
 > So, adding the new complexity mainly to frames seems
 > a better idea.  It better fits the mental model that
 > users already have.  It better preserves some of the
 > longest lasting and most successful parts of the elisp
 > interface.

We mostly agree on that.  But I cannot seriously agree on a concept that
has frames contain windows and other frames and have some parts of Emacs
consider those other frames as fringes.  That way madness lies.

martin

Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-31 at 18:58 +0200, martin rudalics wrote:

> We mostly agree on that.  But I cannot seriously agree on a concept that
> has frames contain windows and other frames and have some parts of Emacs
> consider those other frames as fringes.  That way madness lies.

I'm torn between replying and not replying
because I don't want to abuse your time
and I'm not hung up on "having the last word"
but... but...but.... I can't help myself:

It's not madness, darn it.  Emacs has been
gradually accumulating features that "draw
stuff in margins" both of frames and windows.
What is drawn in margins has grown more 
sophisticated over time (e.g., first just
menu-bars, then tool-bars...)  

It's not too much of a stretch to draw
frames in those margins.

And, how about this (and this is half joking
but only half, maybe less than half):

Consider attached frames in connection with the
ability to parent an arbitrary X window in an
attached frame (instead of displaying buffers
there).  Consider that in combination with
treating the X root window as a single (parent)
frame display.  By happy coincidence, you very
nearly get a complete Emacs-based tiling X window
manager - almost for free.  It's also a floor
wax.

-t

Re: Infrastructural complexity.

[Thomas Lord]

On Wed, 2009-07-22 at 20:23 +0200, martin rudalics wrote:

>  > The four child frames around the edge of a normal
>  > frame, though - the four control panel areas - can
>  > have a nil configuration.  When they do, they are
>  > invisible, not reached by `next-frame', and don't
>  > appear in the frame list.
> 
> So why have them exist at all?  One can always recreate them.

So that they can have properties that persist
between periods of having non-nil window 
configurations.

-t

Re: Infrastructural complexity.

[martin rudalics]

 > So that they can have properties that persist
 > between periods of having non-nil window
 > configurations.

One could save these properties in separate lists but I admit that one
would also want to keep pointers to such frames from somewhere else.
But IMHO it would be simpler to make such frames temporarily invisible.

martin

Re: Infrastructural complexity.

[martin rudalics]

 > I recall that we had an inconclusive discussion over the relative merits
 > of two proposals, one by Joakim that (IIRC) relied on window parameters,
 > and another by Martin that uses more built-in code.  Does anyone have
 > any new thoughts about this?

 From earlier discussions I'm fairly convinced of one thing: A window
group should correspond to an internal window.  IIRC Klaus Berndl
confirmed that ECB configurations always form rectangles so there should
not be problems with ECB.  If, however, someones wants to combine
non-rectangular subregions of a frame to form a group, this approach
won't work (in that case, however, a number of features like cloning a
window group into a separate frame would have no intuitive solution
anyway).

FWIW, the following issues are still unresolved:

- Whether we should allow nested or intersecting window groups.  This is
   a fundamental issue.

- Whether we want special naming conventions for window groups and
   whether we should permit unnamed window groups.  This is not a serious
   issue since all this can be easily resolved on top of internal windows
   but would be good to know.

- Whether, which and how window properties (fixed-size, dedicated, ...)
   apply to window groups.  This is a subtle issue since a fixed-size
   window group should probably allow to vary the sizes of the individual
   windows within the group but not the size of the rectangle covered by
   the group.  A dedicated window group would likely forbid to replace
   the entire rectangle by something else and allow to replace the
   contents of individual members of the group but this seems far less
   intuitive already.

- Whether and how window groups interact with window parameters: We can
   easily extend window parameters to apply to internal windows and, as a
   rule, store all group relevant information there - like, for example,
   whether `delete-other-windows' invoked within a window of a group
   should delete all other members of that group or all other windows of
   the containing frame.

- Whether and how window groups can be distinguished visually within the
   containing frame.

martin

Re: Infrastructural complexity.

[Juri Linkov]

>> Because messages missing by the user is a real problem in Emacs.
>> Most modern IDEs has no such problem since they have a special
>> `Log' tab/window.  We are gearing towards IDE so our efforts
>> will count for this goal.
>
> I'm not sure this argument is valid, since one can set up a dedicated
> *Messages* window in Emacs, if desired.

Yes, and this means we have almost all necessary pieces except
a decent window configuration manager.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[martin rudalics]

 > Yes, and this means we have almost all necessary pieces except
 > a decent window configuration manager.

Could you please list the features of such a manager?

martin

Re: Infrastructural complexity.

[Juri Linkov]

>> Yes, and this means we have almost all necessary pieces except
>> a decent window configuration manager.
>
> Could you please list the features of such a manager?

Like most window managers Emacs should allow the user to create
persistent window configurations, specify window placement, group windows
to window layouts, easily change, save and restore window groups with
window parameters like dedicatedness.

There are already a few packages that partially implement this like
winner.el (restores old window configurations), winring.el (named
window configuration rings), escreen.el (emacs window session manager),
gnus-win.el (window layouts in `gnus-buffer-configuration').

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[Lennart Borgman]

On Sat, Jul 18, 2009 at 11:57 PM, Juri Linkov<juri@jurta.org> wrote:
>
> There are already a few packages that partially implement this like
> winner.el (restores old window configurations), winring.el (named
> window configuration rings), escreen.el (emacs window session manager),
> gnus-win.el (window layouts in `gnus-buffer-configuration').

And some of them also allows restoring a frame window configuration
into a single window, which could be useful for the framelettes.

Re: Infrastructural complexity.

[Stefan Monnier]

> There are already a few packages that partially implement this like
> winner.el (restores old window configurations)

I think something like winner.el would be desirable.


        Stefan

Re: Infrastructural complexity.

[martin rudalics]

 > Like most window managers Emacs should allow the user to create
 > persistent window configurations, specify window placement, group windows
 > to window layouts, easily change, save and restore window groups with
 > window parameters like dedicatedness.
 >
 > There are already a few packages that partially implement this like
 > winner.el (restores old window configurations), winring.el (named
 > window configuration rings), escreen.el (emacs window session manager),
 > gnus-win.el (window layouts in `gnus-buffer-configuration').

IIUC most of these serve to save and restore earlier constructed window
configurations, though not across sessions (which, I suppose, is what
"persistent" stands for).  But wouldn't ECB implement all the missing
parts?  ISTR that ECB comes with some predefined configurations which is
probably the most important part for beginners.

martin

Re: Infrastructural complexity.

[Lennart Borgman]

On Sun, Jul 19, 2009 at 12:38 PM, martin rudalics<rudalics@gmx.at> wrote:
>
> IIUC most of these serve to save and restore earlier constructed window
> configurations, though not across sessions (which, I suppose, is what
> "persistent" stands for).  But wouldn't ECB implement all the missing
> parts?  ISTR that ECB comes with some predefined configurations which is
> probably the most important part for beginners.

Winsav.el does save and restore across sessions and I think there is
one other package that does it too.

Re: Infrastructural complexity.

[Juri Linkov]

>> Like most window managers Emacs should allow the user to create
>> persistent window configurations, specify window placement, group windows
>> to window layouts, easily change, save and restore window groups with
>> window parameters like dedicatedness.
>>
>> There are already a few packages that partially implement this like
>> winner.el (restores old window configurations), winring.el (named
>> window configuration rings), escreen.el (emacs window session manager),
>> gnus-win.el (window layouts in `gnus-buffer-configuration').
>
> IIUC most of these serve to save and restore earlier constructed window
> configurations, though not across sessions (which, I suppose, is what
> "persistent" stands for).

Yes, I meant to save window configurations across sessions in
~/.emacs.desktop.  There are corresponding tasks in etc/TODO:

** Make desktop.el save the "frame configuration" of Emacs (in some
  useful sense).

** Give desktop.el a feature to switch between different named
  desktops.

> But wouldn't ECB implement all the missing parts?  ISTR that ECB comes
> with some predefined configurations which is probably the most
> important part for beginners.

ECB layout definitions are powerful but rely on `defadvice' and
IMO they are over-complicated.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[Lennart Borgman]

On Sun, Jul 19, 2009 at 8:31 PM, Juri Linkov<juri@jurta.org> wrote:
>
> Yes, I meant to save window configurations across sessions in
> ~/.emacs.desktop.  There are corresponding tasks in etc/TODO:
>
> ** Make desktop.el save the "frame configuration" of Emacs (in some
>  useful sense).

As I said before, I have code for that in winsav.el. It needs a bit
better integration with desktop.el currently, but it works.

Re: Infrastructural complexity.

[Juri Linkov]

> As I said before, I have code for that in winsav.el. It needs a bit
> better integration with desktop.el currently, but it works.

BTW, do you now have a fix to the problem of breaking the 'window
property of overlays when restoring windows?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[Lennart Borgman]

On Mon, Jul 20, 2009 at 1:11 AM, Juri Linkov<juri@jurta.org> wrote:
>> As I said before, I have code for that in winsav.el. It needs a bit
>> better integration with desktop.el currently, but it works.
>
> BTW, do you now have a fix to the problem of breaking the 'window
> property of overlays when restoring windows?


No, I consider that a "dynamic property", tied to the state of the
buffer+window.

I think there have to be some restore functions specific for major and
minor modes to do something like this. (And not even this will do it,
it might be about an overall state, not a per buffer state.)

So to fix this we have to define states to restore. I have done
miniscule work on this, restoring hi-lock overlays, but that is of
course a very minor (but useful) thing. But as an example that is what
I mean.

Re: Infrastructural complexity.

[martin rudalics]

 >> As I said before, I have code for that in winsav.el. It needs a bit
 >> better integration with desktop.el currently, but it works.
 >
 > BTW, do you now have a fix to the problem of breaking the 'window
 > property of overlays when restoring windows?

There's no easy fix for that unless you scan all overlays in all live
buffers to check whether they have a 'window property.  More than 99% of
overlays do not have a 'window property so this introduces considerable
overhead with hardly any benefits.

martin

Re: Infrastructural complexity.

[Lennart Borgman]

On Mon, Jul 20, 2009 at 11:32 AM, martin rudalics<rudalics@gmx.at> wrote:
>>> As I said before, I have code for that in winsav.el. It needs a bit
>>> better integration with desktop.el currently, but it works.
>>
>> BTW, do you now have a fix to the problem of breaking the 'window
>> property of overlays when restoring windows?
>
> There's no easy fix for that unless you scan all overlays in all live
> buffers to check whether they have a 'window property.  More than 99% of
> overlays do not have a 'window property so this introduces considerable
> overhead with hardly any benefits.

I believe saving them this way does not make sense. It kind of assume
that the user has created them which we know nothing about.

I think it is better to think of them just as font-lock faces. We do
not save that, it is recreated autmoatically (if we recreate the
state).

Re: Infrastructural complexity.

[Stefan Monnier]

>>> BTW, do you now have a fix to the problem of breaking the 'window
>>> property of overlays when restoring windows?
[...]
> I think it is better to think of them just as font-lock faces.  We do
> not save that, it is recreated autmoatically (if we recreate the
> state).

I'd tend to agree (at least it corresponds to the use of the `window'
property in doc-view.el).


        Stefan

Re: Infrastructural complexity.

[Juri Linkov]

> Yes, I meant to save window configurations across sessions in
> ~/.emacs.desktop.  There are corresponding tasks in etc/TODO:
>
> ** Make desktop.el save the "frame configuration" of Emacs (in some
>   useful sense).
>
> ** Give desktop.el a feature to switch between different named
>   desktops.

And this one from etc/TODO:

  ** "Perspectives" are named persistent window configurations.  We have
  had the window configuration mechanism in GNU Emacs since the
  beginning but we have never developed a good user interface to take
  advantage of them.  Eclipse's user interface seems to be good.

  Perspectives work well even if you do the equivalent of C-x 4 C-f
  because of the distinction between view windows vs file windows.  In
  Emacs this is more or less the "dedicated window" feature, but we have
  never really made it work for this.

  Perspectives also need to interact with the tabs.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[martin rudalics]

 > Yes, I meant to save window configurations across sessions in
 > ~/.emacs.desktop.  There are corresponding tasks in etc/TODO:
 >
 > ** Make desktop.el save the "frame configuration" of Emacs (in some
 >   useful sense).

Did anyone ever specify what the "useful sense" of saving a frame
configuration is?

 > ** Give desktop.el a feature to switch between different named
 >   desktops.

I don't use desktop so I suppose this means to let the user choose (at
the beginning of a session) among different saved desktops.  Does
this have any peculiar relevance for window configurations (as soon as
it has been resolved in a more general sense)?

 > ECB layout definitions are powerful but rely on `defadvice' and
 > IMO they are over-complicated.

Removing the defadvice dependency is a goal of the window groups
concepts.  In what sense are ECB layouts over-complicated?

martin

Re: Infrastructural complexity.

[Juri Linkov]

>> Yes, I meant to save window configurations across sessions in
>> ~/.emacs.desktop.  There are corresponding tasks in etc/TODO:
>>
>> ** Make desktop.el save the "frame configuration" of Emacs (in some
>>   useful sense).
>
> Did anyone ever specify what the "useful sense" of saving a frame
> configuration is?

I guess "useful" means an ability to restore a frame configuration
to the state that was before saving.

>> ** Give desktop.el a feature to switch between different named
>>   desktops.
>
> I don't use desktop so I suppose this means to let the user choose (at
> the beginning of a session) among different saved desktops.  Does
> this have any peculiar relevance for window configurations (as soon as
> it has been resolved in a more general sense)?

I misread this task as "a feature to switch between different named
frame configurations" that makes sense for the current discussion.

>> ECB layout definitions are powerful but rely on `defadvice' and
>> IMO they are over-complicated.
>
> Removing the defadvice dependency is a goal of the window groups
> concepts.  In what sense are ECB layouts over-complicated?

ECB layouts are too specific to the code browser and can't be used
stand-alone that would be a useful feature.  But there are many good
ideas in ECB.  It uses procedural definitions for layouts like:

(ecb-layout-define "left1" left
  (ecb-set-directories-buffer)
  (ecb-split-ver 0.3)
  (ecb-set-sources-buffer)
  (ecb-split-ver 0.5)
  (ecb-set-methods-buffer)
  (select-window (previous-window))
  (ecb-split-hor 0.5)
  (ecb-set-history-buffer)
  (select-window (next-window (next-window))))

Such procedural definitions insure that created and restored
window trees will be the same.  Maybe desktop.el should try
saving window trees with similar procedural structures where
content of each restored window will be filled with either
a file or the result of `desktop-buffer-mode-handlers'.
I mean replacing `ecb-set-directories-buffer', `ecb-set-sources-buffer',
`ecb-set-methods-buffer' in the example above with a single call
to `desktop-create-buffer'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Infrastructural complexity.

[Lennart Borgman]

On Wed, Jul 22, 2009 at 2:38 AM, Juri Linkov<juri@jurta.org> wrote:

>> Did anyone ever specify what the "useful sense" of saving a frame
>> configuration is?
>
> I guess "useful" means an ability to restore a frame configuration
> to the state that was before saving.

As you notice below
> ECB layouts are too specific to the code browser and can't be used
> stand-alone that would be a useful feature.  But there are many good
> ideas in ECB.  It uses procedural definitions for layouts like:
>
> (ecb-layout-define "left1" left
>  (ecb-set-directories-buffer)
>  (ecb-split-ver 0.3)
>  (ecb-set-sources-buffer)
...
>  (select-window (next-window (next-window))))
>
> Such procedural definitions insure that created and restored
> window trees will be the same.  Maybe desktop.el should try
> saving window trees with similar procedural structures where
> content of each restored window will be filled with either
> a file or the result of `desktop-buffer-mode-handlers'.

Is there any other way? But perhaps you mean saving the commands that
lead to this structure and then the replay them?


> I mean replacing `ecb-set-directories-buffer', `ecb-set-sources-buffer',
> `ecb-set-methods-buffer' in the example above with a single call
> to `desktop-create-buffer'.
>
> --
> Juri Linkov
> http://www.jurta.org/emacs/
>
>
>

Re: Infrastructural complexity.

[martin rudalics]

 >> Did anyone ever specify what the "useful sense" of saving a frame
 >> configuration is?
 >
 > I guess "useful" means an ability to restore a frame configuration
 > to the state that was before saving.

Sure.  But what goes into a frame configuration?  Overlays?

 > I misread this task as "a feature to switch between different named
 > frame configurations" that makes sense for the current discussion.

IIUC desktop only affects what Emacs does when starting a session.  Or
am I wrong?

 > ECB layouts are too specific to the code browser and can't be used
 > stand-alone that would be a useful feature.  But there are many good
 > ideas in ECB.  It uses procedural definitions for layouts like:
 >
 > (ecb-layout-define "left1" left
 >   (ecb-set-directories-buffer)
 >   (ecb-split-ver 0.3)
 >   (ecb-set-sources-buffer)
 >   (ecb-split-ver 0.5)
 >   (ecb-set-methods-buffer)
 >   (select-window (previous-window))
 >   (ecb-split-hor 0.5)
 >   (ecb-set-history-buffer)
 >   (select-window (next-window (next-window))))
 >
 > Such procedural definitions insure that created and restored
 > window trees will be the same.

IIRC ECB records the entire history of window changes for saving such
procedural definitions.

 > Maybe desktop.el should try
 > saving window trees with similar procedural structures where
 > content of each restored window will be filled with either
 > a file or the result of `desktop-buffer-mode-handlers'.
 > I mean replacing `ecb-set-directories-buffer', `ecb-set-sources-buffer',
 > `ecb-set-methods-buffer' in the example above with a single call
 > to `desktop-create-buffer'.

I'm afraid that we have to use a "procedural" instead of an internal
object like `set-window-configuration' does.  Otherwise, we risk
crashing Emacs when a user stores a "non-procedural" configuration on
file and deliberately changes it.  However, I profoundly dislike
procedural specifications for saving states :-(

martin

Re: Infrastructural complexity.

[Stefan Monnier]

> Sure.  But what goes into a frame configuration?

That's indeed a difficult question in some cases (e.g. window-parameters).

> Overlays?

But for overlays, it's pretty clear they're not part of
frame configurations.


        Stefan

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Stefan Monnier]

>>>> In particular, the File Style and local variables settings are rarely
>>>> used precision instruments, for configuring unusual files unusually.
>>> This indicates that we should not set c-file-style in the .dir-locals.el
>>> file of the Emacs source tree.
>> Actually, I wonder: why would it be correct to use another style than GNU
>> for C files inside the Emacs source tree?
>> I don't think it's a feature that dir-locals.el takes precedence over
>> mode-hooks (it's more of an accident that we consider sufficiently
>> harmless not to fix it, especially since a fix would probably be
>> difficult/inconvenient/buggy), but in this case it seems to provide just
>> the behavior we want.  I mean we do want to "impose" the GNU style in
>> our files, no matter what the user usually prefers.
>> What am I missing?

> That setting space-before-funcall in c-cleanup-list is a very reasonable
> thing to do in the context of the GNU-style (why isn't it on by default for
> GNU?), and in no way breaks the imposed style.  But the old ways of doing
> that in the Emacs source tree doesn't work anymore, and there is nothing in
> NEWS, and AFAIK, no discussion about it has taken place.  It is just one of
> those frustrating WTF-discoveries.

Doesn't this rather point to a problem in C-mode's interaction between its
various config variables?


        Stefan

Re: Blunderbuss ".dir-locals.el" raises everything in its path!!

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> Why on earch does .dir-locals.el take precedence over values set in a
> top-level `setq' or `c-mode-hook'?  This is surely the Wrong Thing to
> do.  Jan hat set his own desired value of c-cleanup-list (as a top-level
> command), only to have it obliterated by this line:
..
> Yes, we both agree on what is happening.  My point is that the contents
> of .dir-locals.el should not override explicit values given by the user
> in his .emacs.

That seems quite arguable... most hook settings are probably intended
for the average case, and are done unconditionally.  For something like
C indentation settings, probably .dir-locals.el _should_ override the
hook, as those settings are more specific than the hook settings.

There are probably other examples where the opposite order seems better,
but I dunno...

-Miles

-- 
Dictionary, n.  A malevolent literary device for cramping the growth of
a language and making it hard and inelastic. This dictionary, however,
is a most useful work.