Horrible File menu

Horrible File menu

[Juri Linkov]

Recent development turned the nicely designed File menu into an eyesore.
The already overly long menu was extended further with two more useless items.
So by default, even when you don't use frames, these items take much space
on the File menu:

  (disabled) Delete frame
  (disabled) Undelete frame
  [X] Allow Undeleting Frames

where the last item with the checkbox looks very ugly.

These useless items are pushing off-screen other useful items
that are below them such as the Quit item and the Print submenu
with Print items that were originally on the File menu but were
moved to the submenu from the overgrowing menu.

I don't understand what obstacle prevents from making this menu
more user-friendly?  Why not to show the Undelete frame item only
when at least one frame was deleted?  And why require enabling
this feature before the deleted frame can be undeleted?  Are a few
kilobytes of memory used by the deleted frame data a real concern?

Re: Horrible File menu

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> And why require enabling this feature before the deleted frame can be
> undeleted?

My opinion is that it shouldn't require enabling.

> Are a few kilobytes of memory used by the deleted frame data a real
> concern?

I don't think so.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Horrible File menu

[Po Lu]

Juri Linkov <juri@linkov.net> writes:

> So by default, even when you don't use frames, these items take much
> space on the File menu:
>
>   (disabled) Delete frame
>   (disabled) Undelete frame
>   [X] Allow Undeleting Frames

"Delete Frame" is not a recent development.  It's been there for a long
time, along with New Frame and the various monitor and multi-tty related
variants of that.

> where the last item with the checkbox looks very ugly.

It doesn't.  Anyway, I'm open to implementing a feature in the Lucid
menu bar widget that prevents all menu items from being aligned to
accommodate checkboxes, so if you want that, just let me know.

You started a discussion about this a few weeks ago, where we agreed to
keep the status quo, so please give the subject a break.

> These useless items are pushing off-screen other useful items
> that are below them such as the Quit item and the Print submenu
> with Print items that were originally on the File menu but were
> moved to the submenu from the overgrowing menu.

I find it hard to believe that two extra items "push offscreen" such
important items as the Print menu and Quit.

> I don't understand what obstacle prevents from making this menu
> more user-friendly?

It already is user friendly.

> Why not to show the Undelete frame item only when at least one frame
> was deleted?

We agreed to not do that in the discussion you started earlier.

> And why require enabling this feature before the deleted frame can be
> undeleted?

Likewise.

> Are a few kilobytes of memory used by the deleted frame data a real
> concern?

Yes, which was discussed in detail in the discussion in the bug report.

Re: Horrible File menu

[Phil Sainty]

On 2022-01-31 10:45, Lars Ingebrigtsen wrote:
> Juri Linkov <juri@linkov.net> writes:
> 
>> And why require enabling this feature before the deleted frame can be
>> undeleted?
> 
> My opinion is that it shouldn't require enabling.
> 
>> Are a few kilobytes of memory used by the deleted frame data a real
>> concern?
> 
> I don't think so.

I haven't been following these changes, but if it "requires enabling"
on account of such an inconsequential amount of memory, I would agree
that it should be enabled by default.

After all, I assume the memory was *already* used for the frame before
it was deleted, so all that's happening is that it's not being released
when the frame is deleted (but held until such time as another frame is
subsequently deleted IIUC).

I can't imagine it being worth making the UI clunkier (and likely
preventing many users from getting the benefit of the feature the
very first time they actually need it) for that reason.


-Phil

Re: Horrible File menu

[Juri Linkov]

>> So by default, even when you don't use frames, these items take much
>> space on the File menu:
>>
>>   (disabled) Delete frame
>>   (disabled) Undelete frame
>>   [X] Allow Undeleting Frames
>
> "Delete Frame" is not a recent development.  It's been there for a long
> time, along with New Frame and the various monitor and multi-tty related
> variants of that.

To make the menu shorter, does it make sense to hide "Delete frame"?
Especially the users who don't use frames would benefit from this.
Or at least not to show the disabled "Undelete frame" until
"Delete frame" changes to the enabled state.

>> These useless items are pushing off-screen other useful items
>> that are below them such as the Quit item and the Print submenu
>> with Print items that were originally on the File menu but were
>> moved to the submenu from the overgrowing menu.
>
> I find it hard to believe that two extra items "push offscreen" such
> important items as the Print menu and Quit.

What do you think about another variant to make the menu shorter:
to move frame items to the File>Frame submenu?

>> I don't understand what obstacle prevents from making this menu
>> more user-friendly?
>
> It already is user friendly.

No, it's not.  It requires the user to select the item "Allow Undeleting Frames"
on the "File" menu, then to select "Save Options" on the "Options" menu
to be able to occasionally undelete an accidentally deleted frame.

>> Are a few kilobytes of memory used by the deleted frame data a real
>> concern?
>
> Yes, which was discussed in detail in the discussion in the bug report.

This concern was recently addressed, this is why the discussion is reopened.

Re: Horrible File menu

[Po Lu]

Juri Linkov <juri@linkov.net> writes:

>>> So by default, even when you don't use frames, these items take much
>>> space on the File menu:
>>>
>>>   (disabled) Delete frame
>>>   (disabled) Undelete frame
>>>   [X] Allow Undeleting Frames
>>
>> "Delete Frame" is not a recent development.  It's been there for a long
>> time, along with New Frame and the various monitor and multi-tty related
>> variants of that.

> To make the menu shorter, does it make sense to hide "Delete frame"?

It does not.

> Especially the users who don't use frames would benefit from this.  Or
> at least not to show the disabled "Undelete frame" until "Delete
> frame" changes to the enabled state.

How does someone "not use frames"?  I thought that stopped being
possible with Emacs 19, when every X window became a frame.

> What do you think about another variant to make the menu shorter: to
> move frame items to the File>Frame submenu?

That I can agree with (but please let Eli and some other regulars
comment first), thanks.

Re: Horrible File menu

[Robert Pluim]

>>>>> On Mon, 31 Jan 2022 17:46:04 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> Juri Linkov <juri@linkov.net> writes:
    >>>> So by default, even when you don't use frames, these items take much
    >>>> space on the File menu:
    >>>> 
    >>>> (disabled) Delete frame
    >>>> (disabled) Undelete frame
    >>>> [X] Allow Undeleting Frames
    >>> 
    >>> "Delete Frame" is not a recent development.  It's been there for a long
    >>> time, along with New Frame and the various monitor and multi-tty related
    >>> variants of that.

    >> To make the menu shorter, does it make sense to hide "Delete frame"?

    Po> It does not.

If anything needs deleting from that menu, itʼs 'Make frame on
display'. Thatʼs useful to a vanishingly small percentage of users,
and I doubt they'd use the menu to do it.

    >> Especially the users who don't use frames would benefit from this.  Or
    >> at least not to show the disabled "Undelete frame" until "Delete
    >> frame" changes to the enabled state.

    Po> How does someone "not use frames"?  I thought that stopped being
    Po> possible with Emacs 19, when every X window became a frame.

Some people only use a single frame. Some people use multiple frames
on tty. Tomayto, tomaato.

    >> What do you think about another variant to make the menu shorter: to
    >> move frame items to the File>Frame submenu?

    Po> That I can agree with (but please let Eli and some other regulars
    Po> comment first), thanks.

Fine by me: I have the menus turned off :-)

FWIW, Iʼd vote to have undelete frame enabled by default, which would
obviate the need for the menu item. Having to turn on a mode to get
'undo' behaviour just seems unfriendly.

Robert
-- 

Re: Horrible File menu

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> If anything needs deleting from that menu, itʼs 'Make frame on
> display'. Thatʼs useful to a vanishingly small percentage of users,
> and I doubt they'd use the menu to do it.

I agree entirely.

Re: Horrible File menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 31 Jan 2022 10:13:04 +0200
> Cc: emacs-devel@gnu.org
> 
> What do you think about another variant to make the menu shorter:
> to move frame items to the File>Frame submenu?

IMO, it will only make sense if we also move the "windows" and the
"tabs" items to their separate sub-menus.

Re: Horrible File menu

[Stefan Monnier]

> If anything needs deleting from that menu, itʼs 'Make frame on
> display'.  Thatʼs useful to a vanishingly small percentage of users,
> and I doubt they'd use the menu to do it.

But that's also a nice way to advertise this feature that's obviously
not shared by very many applications.


        Stefan

Re: Horrible File menu

[Robert Pluim]

>>>>> On Mon, 31 Jan 2022 08:04:35 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

    >> If anything needs deleting from that menu, itʼs 'Make frame on
    >> display'.  Thatʼs useful to a vanishingly small percentage of users,
    >> and I doubt they'd use the menu to do it.

    Stefan> But that's also a nice way to advertise this feature that's obviously
    Stefan> not shared by very many applications.

My conditional 'if' was obviously not conditional enough. "If it is
decided that the length of that menu needs to be reduced by
sacrificing an entry, then this is the one that should go". But my
opinion on menus should not be given great weight, given that I donʼt
use them (except when I accidentally hit F10).

Robert
-- 

Re: Horrible File menu

[Po Lu]

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

>> If anything needs deleting from that menu, itʼs 'Make frame on
>> display'.  Thatʼs useful to a vanishingly small percentage of users,
>> and I doubt they'd use the menu to do it.
>
> But that's also a nice way to advertise this feature that's obviously
> not shared by very many applications.

It could use some clarification of what consistutes a "display", though,
since these days most computer users expect that to mean "monitor".

Re: Horrible File menu

[Robert Pluim]

>>>>> On Mon, 31 Jan 2022 21:16:54 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> Stefan Monnier <monnier@iro.umontreal.ca> writes:
    >>> If anything needs deleting from that menu, itʼs 'Make frame on
    >>> display'.  Thatʼs useful to a vanishingly small percentage of users,
    >>> and I doubt they'd use the menu to do it.
    >> 
    >> But that's also a nice way to advertise this feature that's obviously
    >> not shared by very many applications.

    Po> It could use some clarification of what consistutes a "display", though,
    Po> since these days most computer users expect that to mean "monitor".

Would it make sense to say "remote display"? And since weʼre at it,
how about filling in some sensible defaults?

diff --git a/lisp/frame.el b/lisp/frame.el
index 86c52dc438..49f18f8522 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -702,7 +702,9 @@ make-frame-on-display
 The optional argument PARAMETERS specifies additional frame parameters."
   (interactive (if (fboundp 'x-display-list)
                    (list (completing-read "Make frame on display: "
-                                          (x-display-list)))
+                                          (x-display-list) nil
+                                          nil (car (x-display-list))
+                                          nil (car (x-display-list))))
                  (user-error "This Emacs build does not support X displays")))
   (make-frame (cons (cons 'display display) parameters)))
 
diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index 849d400be6..3040103eb6 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -121,7 +121,7 @@ menu-bar-file-menu
                   :visible (fboundp 'make-frame-on-monitor)
                   :help "Open a new frame on another monitor"))
     (bindings--define-key menu [make-frame-on-display]
-      '(menu-item "New Frame on Display..." make-frame-on-display
+      '(menu-item "New Frame on Remote Display..." make-frame-on-display
                   :visible (fboundp 'make-frame-on-display)
                   :help "Open a new frame on another display"))
     (bindings--define-key menu [make-frame]

Robert
-- 

Re: Horrible File menu

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

>     Po> It could use some clarification of what consistutes a "display", though,
>     Po> since these days most computer users expect that to mean "monitor".

> Would it make sense to say "remote display"? And since weʼre at it,
> how about filling in some sensible defaults?

An X display might not be remote, and the word "remote" might suggest a
protocol such as VNC or RDP instead of X.

How about "New frame on X server"?

> +                                          (x-display-list) nil
> +                                          nil (car (x-display-list))
> +                                          nil (car (x-display-list))))

This looks great.

RE: [External] : Re: Horrible File menu

[Drew Adams]

> What do you think about another variant to make the menu
> shorter: to move frame items to the File>Frame submenu?

Yes.  I suggested that - a `Frames' submenu.

https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01367.html

Same perhaps for a `Windows' submenu,
and perhaps for a `Tabs' submenu.

(And there are more commands that could
usefully be added to such submenus.)

Re: Horrible File menu

[Robert Pluim]

>>>>> On Mon, 31 Jan 2022 21:48:09 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> Robert Pluim <rpluim@gmail.com> writes:
    Po> It could use some clarification of what consistutes a "display", though,
    Po> since these days most computer users expect that to mean "monitor".

    >> Would it make sense to say "remote display"? And since weʼre at it,
    >> how about filling in some sensible defaults?

    Po> An X display might not be remote, and the word "remote" might suggest a
    Po> protocol such as VNC or RDP instead of X.

    Po> How about "New frame on X server"?

That makes it sound very similar to just 'new frame'. "New frame on
different X server" sounds wrong as well (and Iʼm still hopeful that
at some point Wayland will support display forwarding)

    >> +                                          (x-display-list) nil
    >> +                                          nil (car (x-display-list))
    >> +                                          nil (car (x-display-list))))

    Po> This looks great.

Iʼll queue it up.

Robert
-- 

Re: Horrible File menu

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> That makes it sound very similar to just 'new frame'. "New frame on
> different X server" sounds wrong as well (and Iʼm still hopeful that
> at some point Wayland will support display forwarding)

We could say "New frame on Display server", perhaps that would work just
as well.

As for Wayland, it already supports display forwarding through various
external programs (such as Waypipe), but I think GTK's multihead support
doesn't work well enough for the PGTK port yet.

Thanks.

Re: Horrible File menu

[Robert Pluim]

>>>>> On Tue, 01 Feb 2022 09:03:06 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> Robert Pluim <rpluim@gmail.com> writes:
    >> That makes it sound very similar to just 'new frame'. "New frame on
    >> different X server" sounds wrong as well (and Iʼm still hopeful that
    >> at some point Wayland will support display forwarding)

    Po> We could say "New frame on Display server", perhaps that would work just
    Po> as well.

That sounds good, lets go with that.

    Po> As for Wayland, it already supports display forwarding through various
    Po> external programs (such as Waypipe), but I think GTK's multihead support
    Po> doesn't work well enough for the PGTK port yet.

You mean itʼs 5 years away, like itʼs been for the past 5 years? ;-)

Robert
-- 

Re: Horrible File menu

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> You mean itʼs 5 years away, like itʼs been for the past 5 years? ;-)

It already works, but GTK doesn't support connecting to two different
Wayland servers simultaneously very well.

Re: Horrible File menu

[Rudolf Adamkovič]

Juri Linkov <juri@linkov.net> writes:

> where the last item with the checkbox looks very ugly.

It look great on macOS, FYI.

> These useless items are pushing off-screen other useful items
> that are below them such as the Quit item and the Print submenu
> with Print items that were originally on the File menu but were
> moved to the submenu from the overgrowing menu.

I like the idea of sub-menus.

> Why not to show the Undelete frame item only when at least one frame
> was deleted?

101 "classical" UX, from back when research guided the field instead of
fashion, teaches us that hiding menu items like that leads to confusion.
All menu items should live in one place.  Always.  If not applicable, we
can disable them.  Just because we can make everything dynamic, it does
not mean we should, IMO.

> And why require enabling this feature before the deleted
> frame can be undeleted?  Are a few kilobytes of memory used by the
> deleted frame data a real concern?

I find this strange as well.

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Horrible File menu

[chad]

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

Following up on some of the discussions in this thread (and it's earlier
sibling), I notice that the Frames submenu of the Buffers menu lists both
the only usable frame and also "F1", which I believe is the initial
pseudo-frame used by daemon mode (which I am using).

Is this a bug? If so, I'll file a report.
Is there any way to ever use that entry in the Frames menu? If so, I
couldn't find it.

Thanks,
~Chad

[-- Attachment #2: Type: text/html, Size: 540 bytes --]

Re: Horrible File menu

[Po Lu]

chad <yandros@gmail.com> writes:

> Following up on some of the discussions in this thread (and it's
> earlier sibling), I notice that the Frames submenu of the Buffers menu
> lists both the only usable frame and also "F1", which I believe is the
> initial pseudo-frame used by daemon mode (which I am using).

It's the initial frame, and yes, it's a bug.