This functionality is provided by `xref-find-definition`[1]. For many languages this defaults to using keywords from a generated tags index file, but many modes have a language server or some other more specific facility to provide this functionality at runtime. I'm not familiar with what provides that functionality for C/C++, but Ruby has `robe`, python has `jedi`, clojure has `cider`, rust has `racer`, etc. It generally requires a some setup for each language you use, but there is broad support for this functionality (and it often provides some form of symbol auto-completion as well).
Some modes also support limited refactoring tools[2], but that's not quite as common.
Allowing new packages to support platform specific FFI is not going to decrease the portability of the existing ecosystem. In addition, I don't think there is anything precluding FFI calls from working on multiple platforms so long as those libraries are available.
And this is the key part. As soon as we start getting Linux only packages that depend on some library easily available only on Linux, Windows users will be pushed off.
So far Emacs has been, for many users, nice abstraction over the OS. As soon as I'm not able to use the same packages and have the same setup on both Linux and Windows, I won't use it anywhere and start looking at the alternatives.
How is this any different than functionality that requires a specific executable to be called from Emacs. Some of those executables are platform specific. Last I checked using ispell on windows meant playing games with cygwin or some other fix.
The purpose of this is not to limit functionality to a specific platform, it's to expand the capabilities of Emacs. My understanding is FFI is intended to work on all platforms that Emacs support, so it just means the library authors need to provide platform specific support, just the same as they do with packages that depend on specific binaries in the path.
Throwing out a new feature that provides obvious benefits because of imagined future packages that may choose against being platform agnostic seems rather short sighted.
I just wanted to thank you -- I'd never heard of freenet. I know sometimes "how is this different than x" is not considered constructive to some, these posts genuinely pique my interest. Anyone who is interested - https://freenetproject.org/ & http://en.wikipedia.org/wiki/Freenet
edit: "While Freenet provides an HTTP interface for browsing freesites, it is not a proxy for the World Wide Web; Freenet can only be used to access content that has been previously inserted into the Freenet network. In this way, it is more similar to Tor's hidden services than to anonymous proxy software like Tor's proxy."
This doesn't even seem to be anywhere near as advanced as Freenet.
To call it a "new Internet" is a huge stretch and an insult to actual projects that are dedicated to building a successor that extends the present infrastructure, like cjdns (which itself originated from Kademlia, largely known for being used in the eMule network).
I only remember to check in on freenet when stories like this one pop up, so I was very surprised to see that the project is sporting a healthy 5-figure bank account. I had been used to seeing it in the vicinity of $500 or maybe $2000, for years at a time.
It is great to see organizations step up and support a project like freenet, despite the realities of what a truly anonymous network could mean in terms of content and behavior. Maybe a separately funded independent security audit is in order though.
So launch it in tmux, and reconnect the next time you jump to that server. If you want faster start time you can also start emacs, run start-server, and then use emacsclient everywhere else to quickly open files from the commandline. In general though, opening and closing emacs all time is the wrong workflow to use with emacs.
> In general though, opening and closing emacs all time is the wrong workflow to use with emacs.
Depends what you are doing. When I'm remote I almost always have an "emacs --daemon" running. Remote admining a custom server ends up with me editing random .conf files in multiple tmux windows. Emacsclient is heaven sent in that case—it pops up faster than vim, with all context already there.
For coding, I tend to run a GUI locally and just have a bunch of buffers open. I still do server-start/emacsclient so the occasional random git command that spawns an editor just pops open a new frame instead of launching a whole new Emacs process...
Note however you can't use emacs-server/emacsclient with the GUI over a SSH connection and tmux. With remote sessions and emacs you really have to choose between long start-up times and terminal-only editing.
Are you sure you can't? Pretty sure I have used a remotely started emacs --daemon and used emacsclient -c with DISPLAY set correctly and X forwarding to bring a GUI frame locally, and then use emacsclient on that machine to pop open files from the remote command line to the existing, local gui frame. If you lose your connection the gui client might kill your daemon (at least with gtk) though.
Or do your editing from ansi-term or eshell from within the long startup gui you have running on the remote system. Eshell find-file will pop to that buffer from the commandline.
It is unfortunate that tramp often feels too slow for these tasks, as that would seem like another logical approach. Maybe it's faster without ido and friends doing lots of completion requests?
I'm probably misunderstanding you, but that is exactly what I'm doing. I have an emacs-server running on a remote server to which I connect via SSH to a tmux session and from there start an emacsclient gui via SSH X forwarding (you might have to set DISPLAY). Works like a charm.
I think parent was saying that you can't run a single daemon on machine emacs-host and launch clients from needs-editing-a-conf-server1...n (possibly with x11 only running on different host workstation1)?
You seem to be running n daemons on needs-editing-a-conf-server1..n and launching n clients on each of these, and "just" transporting the display(s) back to your workstation via x11 forwarding over ssh.
Henche - either run "redundant" daemons or suffer long-ish startup times.
How much resources does your typical long-running daemon consume?
He's using tramp to copy an auth key to the remote system, but then using that to allow the remote emacsclient to talk back to the host. Has some caveats, but it's essentially the single daemon, many remote clients approach?
I went to school with ekarulf above, can confirm he had the skillset and held that position. I can also think of a couple other folks with skillsets that covered the full gamut. Discussion about pay aside, it's not a mythical skillset. I don't know about the "Rockstar" nomenclature, but the right generalist can do a lot.
I'm curious why they mention uploaded SSH keys. I presume they mean cases where SSH keypairs have been uploaded? The public key is public, and in fact anyone can use the github API to pull the verified public keys for any user in the system, http://developer.github.com/v3/users/keys/. If there is code uploaded with private keys in it, then it's likely there are other security problems in the organization.
Didn't get aorund reading it till this year, but I highly recommend _The Windup Girl_ by Paolo Bacigalupi. _Pump 6 and Other Stories_ by him is also quite good. Finally got around to reading the Takahashi Kovec's novels, _Altered Carbon_ by Richard K Morgan and it's sequels.
I'm having a little trouble following your examples. In particular some of the examples are wrapped in (streams) which I am interpreting as the data source to query, but then many of the examples are just a bare (where) with clause. Or is that the final target ie you wrap it in streams if you want to make a new stream? The system looks pretty slick, but I am having some problems with understanding some of the core concepts in the query DSL.
Ah, yeah I should standardize the docs a bit. It'll be clearer when you've looked at the stock config: (streams ...) just denotes the section of the config where streams live. Since most streams are composable, I sometimes omit the context.
It might be easier to think of streams as literal streams, rivulets, deltas, and tributaries, which events flow through, rather than a query language with well-defined clauses like sql.
Some modes also support limited refactoring tools[2], but that's not quite as common.
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Xr...
[2] https://github.com/clojure-emacs/clj-refactor.el, https://github.com/Wilfred/emacs-refactor, https://www.emacswiki.org/emacs/SemanticRefactor