Loading ...
Sorry, an error occurred while loading the content.

Re: [jasspa] Major mode - request for feedback

Expand Messages
  • Thomas Hundt
    ... Well, if it s a question of menu space, that s an easy one: Kill off that Insert menu. That thing s pretty useless, menu-wise. Buffer or File menu could
    Message 1 of 6 , Jun 8, 2006
      > However at 80 char width (i.e. a standard terminal) there is no room
      > for another main menu item

      Well, if it's a question of menu space, that's an easy one: Kill off
      that Insert menu. That thing's pretty useless, menu-wise. Buffer or
      File menu could have the Insert File command; Edit could have the Insert
      Symbol command; and the Macro thing, why isn't it under Execute with the
      rest of the macro stuff? Done!

      Speaking of which... I never, ever, use the Execute menu, because I have
      those functions memorized from long ago. (Probably, we all do.)
      Everything in it could be
      under Tools, since macros are actually tools. Execute Buffer could be
      under a Buffer menu, Execute File could be under File... or it all could
      be under Macros somewhere... But, since Tools is getting pretty long, if
      nothing else, how about we rename Execute to Macro as the menu title,
      since that's what it's actually concerned with? (People know what a
      macro is; they may not know that one "executes" them. Many people "run"
      theirs. Especially the VB folks!)

      The Search menu is pretty useless and could all be under Edit (search)
      and/or Buffer/File (goto/bookmark). Most programs have Search/Replace
      under Edit.

      > So who fancies creating a new main menu layout? Or at least proposing
      > a set of top level menu names which will fit into 80 chars?

      To summarize: remove Insert menu; remove Search menu; rename Execute
      menu to Macro; add Buffer menu. That'd be my proposal.


      Phillips, Steven wrote, On 6/8/2006 6:00 AM:
      >> -----Original Message----- From: jasspa@yahoogroups.com
      >> [mailto:jasspa@yahoogroups.com] On Behalf Of Thomas Hundt Sent: 07
      >> June 2006 22:49 To: jasspa@yahoogroups.com Subject: Re: [jasspa]
      >> Major mode - request for feedback
      >>> b) Should we change the current buffer-mode command to
      >>> buffer-minor-mode to help create the distinction between
      >> the existing
      >>> buffer modes (exact, wrap, justify, backup, autosv etc) and
      >> the new major mode concept?
      >> The word "mode" is overloaded.
      >> I would rename "modes" (the list of toggles/flags) to "settings".
      >> As in: "the buffer is SET to create automatic backups", "the buffer
      >> is SET to wrap words automatically".
      >> Then, if you want to introduce a "major mode", you can state quite
      >> clearly what that is. And leaves the door open to introducing
      >> "minor modes" for subsections of a file (e.g., a java code listing
      >> inside a text file). That's what you're moving towards, isn't it?
      >> (That's what GNU does, to my knowledge. Maybe I'm wrong about what
      >> they call a "minor mode".)
      > I agree that 'mode' is overloaded, but isn't set/setting/setup even
      > more overloaded? Looking specifically at 'over' buffer-mode as this
      > is available in most editors, the phases 'overwrite mode' or
      > 'overtype mode' (as Word's help calls it) seem dominant; in Big emacs
      > you change this mode by executing the command 'overwrite-mode'. So
      > given your point that the term 'minor-mode' should be used so
      > sections of a file (I.e. java code within a html file - which does
      > seem to be what Emacs uses the term for) perhaps the following is
      > correct:
      > buffer-mode - to set modes like 'over', 'exact' etc. as per today
      > buffer-major-mode - to set the buffer's file type (or 'fhook')
      > buffer-minor-mode - term which could be used to refer to the
      > 'file-type' of the buffer at the current location.
      > I think this makes sense and has the further benefit of not being a
      > big change.
      >>> c) Given the new buffer-setup command will have all the settings
      >>> currently found in indent-setup (Format -> Indentation
      >> Setup ...) is
      >>> this command still required?
      >> Indent Setup doesn't look too useful, especially if you migrate its
      >> content to Buffer Setup.
      > Agreed
      >> BUFFERS
      >>> d) Where should the new buffer-setup be placed in the main menu?
      >>> I don't think the Help menu is correct, is it a File, Format
      >> or Tools item??
      >> Put all the things having to do with buffers in a Buffer menu next
      >> to the File menu. Buffer "modes" (settings), buffer major mode
      >> setting, buffer minor mode setting, buffer restyle command, list
      >> buffers... all that stuff.
      >> That way, all the dynamic (temporary, not permanent) settings would
      >> be under Buffers, and all the permanent settings would be
      >> somewhere else (see below).
      >> If Buffer items can't be under their own menu, the second choice is
      >> under File. Since everything there pertains to operations dealing
      >> with the entire file one is currently viewing (and a buffer is
      >> just the window into that file), that is a logical place for
      >> buffer-global settings and operations.
      > Like you I think this is a buffer operation and not a file one, after
      > all it does not change a file. However at 80 char width (i.e. a
      > standard terminal) there is no room for another main menu item, and
      > without a 'Buffer' main menu my second choice would not be File, I
      > would go for Tools. Emacs has these settings in a top level 'Options'
      > menu which I think is a little limp (I don't like the Emacs main
      > menu at all). I have several issues with the layout of the current
      > main menu: - I agree with you point about user-setup and the Help
      > menu so that should be fixed - The 'Find Tags' should be moved to
      > Search->Goto Tag - The Execute & Tools menus probably should be merge
      > So who fancies creating a new main menu layout? Or at least proposing
      > a set of top level menu names which will fit into 80 chars?
      > BTW, I understand and equally suffer with the OSD help interface,
      > however I still have not managed to find a sensible solution. When I
      > do I'll throw it your way,
      > Steve

      Thomas Hundt <tom@...> +1-415-867-6698
    Your message has been successfully submitted and would be delivered to recipients shortly.