unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Doug Lewan <dougl@shubertticketing.com>
To: "Adrián Martínez Larumbe" <adrianml@alumnos.upm.es>,
	"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: RE: Shell scripting mode
Date: Thu, 10 Oct 2013 14:01:28 +0000	[thread overview]
Message-ID: <155DEC68569B714B86C2C7075F5EDA9852F9A9DC@DAKIYA1.pegasus.local> (raw)
In-Reply-To: <87mwmhp881.fsf@alumnos.upm.es>

Thanks for the list.

Some of your suggestions are almost there already. (And maybe that's why they're not all there. The community may have settled for "good enough".)

Here are my thoughts:

- Code completion ...
    M-/ comes close. I agree that something shell-specific would be a good thing. 
    Handling previously defined functions from other files might be tricky.
    After all, which previously defined function from which other file sounds a little vague to me.
- Navigation ...
    Exuberant ctags should do exactly what you want.
    (I don't think the etags that comes with emacs handles shell, but I could be wrong.)
- Flymake for shell
    Not there. This would be *very* useful.
    Shells are so full of syntax that it's often very hard to find a mistake.
- Interaction with lower process
    This would be very useful too. And probably not hard to write. 
    All the screwy syntax might mess such a thing up. 
    (Think unterminated string or an unterminated ${variable.)
    A command like M-x sh-eval-region that always starts (and terminates) a clean shell might work though.
- Online Documentation of shell builtins
    Info for bash is pretty good.
    Something that navigates it directly would indeed be nice.
    As far as other shells go, it's probably a hard thing to do.
    You'd have to get all the authors/publishers to definitively declare their help locations, formats, etc.
    Better yet, they could all agree on one location, one format, etc. (Ha! I made a joke!)
- Yassnippet library
    Personally I'm happy typing almost everything in shell.
    (The exception is option handling. 
    I never remember if getopt or getopts is the built-in, and that's the one I want.)
    I don't happen to know yassnippet since I use very few emacs applications that aren't delivered with emacs.
    Sorry.

,Douglas
Douglas Lewan
Shubert Ticketing
(201) 489-8600 ext 224

These are my principles and if you don't like them... well, I have others. - Groucho Marx


-----Original Message-----
From: help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org [mailto:help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org] On Behalf Of Adrián Martínez Larumbe
Sent: Thursday, 2013 October 10 09:27
To: help-gnu-emacs@gnu.org
Subject: Re: Shell scripting mode

This is a short wishlist I've compiled that pretty much sums up
everything I was looking for when I wrote the post:

- Code completion of shell bultins and previously defined functions
        (I guess this could be done by writing a wordlist for autocomplete mode)
- Navigation: imenu, buffer definitions, etags, gtags?
        (I'm wondering whether etags has shell scripting support, I'll
        look this up myself)
- Flymake for shell
        (There seems to be a mode for this on elpa repositories)
- Interaction with lower process
        (It'd be awesome if I could send arbitrary regions into the
        shell for immediate execution)
- Online Documentation of shell builtins
        (I guess the best way is turning to woman and reading the
        matching section)
- Yassnippet library
        (The sh scripting mode that ships with emacs has predefined
        functions for skeletons of common constructs, but I think this
        is unnecessary if you put it all into a yasnipet mode directory)





  reply	other threads:[~2013-10-10 14:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-09  9:16 Shell scripting mode Adrián Martínez Larumbe
2013-10-09 14:18 ` Tassilo Horn
2013-10-09 14:34 ` Doug Lewan
2013-10-09 15:59 ` Andreas Röhler
2013-10-10 13:26 ` Adrián Martínez Larumbe
2013-10-10 14:01   ` Doug Lewan [this message]
2013-10-10 17:56   ` Stefan Monnier
2013-10-10 20:27   ` Bob Proulx

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=155DEC68569B714B86C2C7075F5EDA9852F9A9DC@DAKIYA1.pegasus.local \
    --to=dougl@shubertticketing.com \
    --cc=adrianml@alumnos.upm.es \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).