emacs <--> file-browser as coroutines

[Rustom Mody]

For my students I put together something about setting up emacs as server:
https://bitbucket.org/rustom/vit-projects/wiki/emacsasdefault

Note: This is more targetted to newer users of emacs -- my students -- who
are used to point-n-click than to oldtimers (like myself)

Comments/corrections appreciated

The first part is more straightforward -- emacs as server

The second (needs first) is more experimental -- its about emacs not using
its usual C-x C-f method of opening files but calling out to the file
browser
[In my experiments that's nautilus]
Similar on other gnu-linux-variants should be much the same

Windows/Mac likely need more work

Just a curious thought:
When writing file browsers in/for emacs is such a cottage industry -- ido,
icicles, helm etc etc] how come this -- default file browser approach -- is
not talked of??
Am I missing something in what to google for?

[Yuri Khan]

On Mon, Jun 27, 2016 at 1:09 PM, Rustom Mody <rusto...@gmail.com> wrote:

> The second (needs first) is more experimental -- its about emacs not using
> its usual C-x C-f method of opening files but calling out to the file
> browser
> [In my experiments that's nautilus]
> Similar on other gnu-linux-variants should be much the same

If you pull down the File menu and select the Open File item there or
click on the Open File button on the toolbar, you will be presented
with an Open File dialog that is specific to and appropriate for your
desktop environment.

<menu-bar> <file> <open-file> runs the command
menu-find-file-existing, which is an interactive compiled Lisp
function in `menu-bar.el'.

The actual code that decides whether to ask for a file name in the
minibuffer or to pop up a dialog is in read-file-name-default and
next-read-file-uses-dialog-p. The latter returns t if the current
frame is graphical, the variables use_file_dialog and use_dialog box
are non-nil, and the command was invoked with the mouse.

You might be able to circumvent that last condition and get
read-file-name-default to use the dialog even if invoked from the
keyboard.


The file manager as such is usually not an appropriate method of
asking for a file name in response to an Open File command; that calls
for a modal dialog. However, the file manager can invoke Emacs or
emacsclient in response to a double-click on a file of a suitable
type, to a menu or context menu command, or a drag-and-drop of a file
into an Emacs window or on an Emacs launcher button or icon. (All of
the above actually works for me in Thunar, provided that I set up file
type associations.)

[Rusi]

On Monday, June 27, 2016 at 1:48:40 PM UTC+5:30, Yuri Khan wrote:

> On Mon, Jun 27, 2016 at 1:09 PM, Rustom Mody wrote:
>
> > The second (needs first) is more experimental -- its about emacs not using
> > its usual C-x C-f method of opening files but calling out to the file
> > browser
> > [In my experiments that's nautilus]
> > Similar on other gnu-linux-variants should be much the same
>
> If you pull down the File menu and select the Open File item there or
> click on the Open File button on the toolbar, you will be presented
> with an Open File dialog that is specific to and appropriate for your
> desktop environment.
>
> <menu-bar> <file> <open-file> runs the command
> menu-find-file-existing, which is an interactive compiled Lisp
> function in `menu-bar.el'.
>
> The actual code that decides whether to ask for a file name in the
> minibuffer or to pop up a dialog is in read-file-name-default and
> next-read-file-uses-dialog-p. The latter returns t if the current
> frame is graphical, the variables use_file_dialog and use_dialog box
> are non-nil, and the command was invoked with the mouse.
>
> You might be able to circumvent that last condition and get
> read-file-name-default to use the dialog even if invoked from the
> keyboard.

Thanks Yuri for pointing out the open-file entry in that dialog

>
>
> The file manager as such is usually not an appropriate method of
> asking for a file name in response to an Open File command; that calls
> for a modal dialog.

The question (at least the 2nd part) could well be:
Why are we stuck on Open File being modal?
Think ecb/speedbar etc -- the file-browser exists, it can be used...
Or ignored and one can keep working on/with other things.
It does not need to go away or come in the way -- almost the definition of
'modal dialog'

> However, the file manager can invoke Emacs or
> emacsclient in response to a double-click on a file of a suitable
> type, to a menu or context menu command, or a drag-and-drop of a file
> into an Emacs window or on an Emacs launcher button or icon. (All of
> the above actually works for me in Thunar, provided that I set up file
> type associations.)

Hey Thanks for that -- Ive added it to the writeup

This mode of working -- drag-n-drop -- is sufficiently alien to me that
I did not think of trying to drop a file in (or is it on?) to emacs.

Just strengthens the alternative model I was suggesting:
- Keep both emacs and file browser open
- Navigate to files one desires to view/edit in the browser
- Drag-n-drop into emacs as required

The one thing I miss is an option to ensure that only one browser window opens
There seems to have been one such in the past but now cant find it

[Yuri Khan]

On Mon, Jun 27, 2016 at 3:14 PM, Rusi <rusto...@gmail.com> wrote:
>> The file manager as such is usually not an appropriate method of
>> asking for a file name in response to an Open File command; that calls
>> for a modal dialog.
>
> The question (at least the 2nd part) could well be:
> Why are we stuck on Open File being modal?

No particular reason, just that most other editors already work that way.

> Just strengthens the alternative model I was suggesting:
> - Keep both emacs and file browser open
> - Navigate to files one desires to view/edit in the browser
> - Drag-n-drop into emacs as required
>
> The one thing I miss is an option to ensure that only one browser window opens
> There seems to have been one such in the past but now cant find it

That’s very dependent on the platform and the actual file manager in use.

In practice, it is ensured by not starting the file manager from the
editor. If you arrange for no more than one instance of file manager
opened on startup, and for Emacs to run as a daemon, and for
Emacsclient to be started from the file manager, that will be
sufficient.

The user can then opt to start more instances of the file manager, or
open more Emacs frames, or both, as demanded by his/her workflow.

Also, it might be a good idea to start Emacs with a Dired open at the
user’s home or Documents directory. That’s one more workflow for
opening files in Emacs; one that I personally use the most.

[Drew Adams]

> Also, it might be a good idea to start Emacs with a Dired open at the
> user’s home or Documents directory. That’s one more workflow for
> opening files in Emacs; one that I personally use the most.

Absolutely! That's what I've always done. It just makes sense, to me.