StreakyCobra

Let us know the project URL if you start it, so we can follow your work!

If I would be doing it, I would probably go with python because of the existing ecosystem: NLP, readability, beautifying, image processing or deep learning, … Probably everything is already existing, the goal would be to assemble the pieces like playing lego :-) in a much more complicated way of course.

But I'm not doing it, so your choice is the correct :-) Have a nice time working on this project!

PS: Even the image captioning is almost already implemented, amazing https://github.com/tensorflow/models/tree/master/im2txt

The system I propose would be for sure space-consuming. Removing the ads and other unneeded contents would probably help to shrink down the page size though. This is the price to pay to keep the bookmarked content available in the long-term, and I'm ready to pay this "price".

Assuming 1 bookmark per day during 10 years, this will sum up around 8 Go. Storage is cheep enough nowadays so I can support these 8 Go over 10 years. This will probably not be mobile-friendly, but I'm almost never consulting bookmarks from my phone anyway.

Your project seems interesting, thanks for sharing! This may be especially useful to see how you implemented the readability part.

Oh, I'm not bookmarking such kind of content usually. I guess in any case a system that check the type of content (html/image/sound/video) will be needed to select the storage format, so the annotation may then also be adapted to the content type. In any case a way to manually add tag would exist so it's feasible to add such content.

Glad to hear!

I like the HN community, it gather a lot of enthusiastic people!

I'm not sur at which level you ask this. For storing the images, Base64 encoded in the HTML files. For making them useful, I don't think it's the most important feature, but if need be it is possible to think about using OCR for extracting text, or Deep Learning for describing them [1].

[1] https://research.googleblog.com/2014/11/a-picture-is-worth-t...

Ads removal and "git/simple file structure" are mandatory features for me (PDF export is optional though).

But first and foremost, it should be an open-source tool, I forgot to mention it. I don't want to be stuck because (as already said) a company/website closes. Yes backups are possible, but when the tool is gone, it's gone, and backups are not really useful. People will have to spend days trying out to figure a new tool and how to import existing data. Open-source protect from such kind of issues.

I don't say this tool is bad, it is probably really nice for some people. But at least for me it does not fulfill my wills/needs.

It already seems to have some nice features, but for me the dream bookmark manager would be something really simple with two commands like:

$ bookmark add http://...

That will:

1. Download a static copy of the webpage in a single HTML file, with a PDF exported copy, that also take care of removing adds and unrelated content from the stored content.

2. Run something like http://smmry.com/ to create a summary of the page in few sentences and store it.

3. Use NLP techniques to extract the principle keywords and use them as tags

And another command like:

$ bookmark search "..."

That will:

* Not use regexp or complicated search pattern, but instead;

* Search in titles, tags, AND page content smartly and interactively, and;

* Sort/filter results smartly by relevance, number of matches, frecency, or anything else useful

Storing everything in a git repository or simple file structure for easy synchronization, bonus point for browsers integrations.

Sooner this evening I had to open a 144'000 lines CSV file, 3.5MB. This is not big, but it is the kind of file I have to open from time to time for my work. No noticeable delay to open the file in VSCode, the cursor moves smoothly, and scrolling with the minimap through the whole 144'000 lines is also smooth. The VIM plugin for VSCode start to have troubles over 10M it seems, but if I have to edit files bigger than this I can open them with spacemacs anyway. I spend most of my time in small text files like Python, CSV or Makfiles, so this is not a problem. Of course if you have other requirements, like you are passing a lot of time in big files, then VSCode is not the correct tool.

I would suggest you to try VSCode for curiosity, if you have not done it yet. You could be surprised. Maybe it is not the right tool for you, but it is quite well made, and compared to atom, bracket or other web-based text editor, it feels like a supersonic jet.

Indeed, this bug is pretty nasty for the battery. I don't have it though, so my remark was about non-buggy battery usage. Web-based text editors consumes more battery, but the difference is not significant from my point of view.

> Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js.

I don't really know poppler. If there are Poppler bindings for the language you are developing in, I believe you that this is possible. This is only one use case though, I'm not sure you will find native libraries in your language for all features that VSCode can offer almost for free, like live markdown preview for instance.

> 10x faster and 10x more memory/battery efficient editor?

Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors ans VSCode. There is one, but I don't notice it. Human are much more slower than computers, so as long as it is not taking more time that I need to notice it, I don't care.

Nowadays my computer has enough memory so I can afford to not care about the 116M that VSCode is currently using, especially in regard to what my browser consumes, and in regards of the wide range of features it offers.

Battery could be problematic indeed, but before looking at my text editor, I would probably first switch from KDE to i3, and then use a lightweight web browser. This would impact it much more than my text editor.

> If a native editor just gave you a webview that can run JS extensions...

But then you start loosing all the benefits of faster/memory/battery points you mentioned.

Anyway, I'll happily try something like this if you develop it ;-)

By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability.

For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform.

Imagine all the web-based open-source tools that could potentially be integrated in these editors. Integrating a SVG editor in native text editors would be a nightmare. With web-based text editor you can potentially just incorporate an existing tool like [1].

There are lot of other examples like this: Live markdown preview, mini-map, color-picker, integrated VSCode debug panel, …

It is also quite easy to add visual stuff. For instance adding a vertical bar at 80 characters in the background is quite easy to do with web technologies. On the other side emacs has still not managed yet to make the html-mode work nicely with this "fill-column-indicator". It is also probable that it would be much more easy to integrate web services (trello, github, …) directly within VSCode.

At the end people wanting performances have already quite a lot of choice in native text editors (vim, emacs, sublime…), and people who prefer functionalities can go with web-based text editors (atom, vscode, …)

[1] https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/s...

Emacs psychotherapist?

Can be tried online here: http://www.zenjero.net/morezen/doctor/

Exactly this. I tried a lot of text editors, and I ended up with Spacemacs. The "everything is text" concept of emacs in conjunction with vim's modal editing is the most powerful interface that I've used.

But after a while you start noticing that the the fact that emacs is 100% hackable is also its biggest problem: everything is possible, and tons of plugins exists. Because of this, a lot of interactions between plugins start to go wrong. The nice plugin that shows you a bar at 80 characters is working well… except in HTML files where this is breaking the display/indentation/completion. Or this other plugin that fails in a specific language, or that other one that doesn't work for diff editing. I got tired of always fighting and wasting time with plugins and configurations.

So I started to look at other editors. Atom? Too slow. Vim? Not an IDE. Sublime? Not open-source. And then I found VSCode, refreshing. I start to love it (and feel bad about this, because… Microsoft, you know…). My problem now is that Spacemacs has put the barrier of keybinding efficiency so high that none of the other editors can compete. Whenever I try another editor, like VSCode, I miss the efficiency of Spacemacs, and especially Magit (one of the most awesome pieces of software I have used). In Spacemacs I do absolutely everything without mouse, with VSCode I have to use the mouse, so it's less efficient (though this has been widely debated recently [1]).

I'm stuck.

[1] https://news.ycombinator.com/item?id=13847301

For me it is possible that a big breakthrough would be changing our society in a close future, in even less than 200 years. I wouldn't know if 2 events may be happening, but at least one seems really probable. In ~20 years, we went from windows 95 to an overly connected world with small and powerful smartphones, the world is moving faster than ever.

CRISPR is an overview of what the revolution may look like. This technology may offers possibilities to hack DNA, this would be a huge revolution in term of health, but also totally change our world. Until now the medicine was trying to fix the body deficiencies by applying corrections afterwards. When we will reach DNA hacking capabilities, it would open the possibility to fix the real genetic cause of a disease even beforehand. It may be used to increase lifespan or boost human performance. Maybe it will be called the medical revolution?

Glad to hear my comment inspired you :-) Good luck with this!

PS: Another idea: Instead of selecting manually what extensions should be used or not, you may want to try being more general, like enabling by default all text-like files, and disabling all data-like files. Maybe with `file --mime` then looking at charset value:

    test.jpg: image/jpeg; charset=binary
    manage.py: text/x-python; charset=us-ascii

It would be so much nicer to define better defaults. Like what… 99.99% of the users are never, ever, wanting to see notes that are in the `.git` repository, nor in PNG or any other images. Even hidden dirs and files should not be searched by default I think. All this will cause nightmares to users before they start using it, like the first-poster of this thread had. Provide better defaults, make it vcs-aware (ignored files, etc…) and you will have a much more appreciated product!

It is for the same reason that `rg`/`ag`/`pt` are used nowadays instead of `grep`. 99.99% of the time, you don't want to search files that are ignored by your VCS, and you want to search recursively, and also probably in a case-insensitive way. For `grep` you have to fight with tons of options to filter out files, to enable recursivity and to ignore case. With `ag`? just `ag whatever`.

Defaults make the difference.

Serious question: What are the reasons people are still preferring Python2 over Python3? (No troll intended)

Didn't knew that, thanks!

Related: For hackers, a well know example of community using a method other than the simple majority rule is Debian. They use the Condorcet method [1] for the election of their project leader [2]. It's a ranking method «that elects the candidate that would win by majority rule, in all pairings, against the other candidates».

[1] https://en.wikipedia.org/wiki/Condorcet_method [2] https://www.debian.org/vote/

I'm in the same boat as you, maybe a little bit less categorical about whether to contribute to projects with CoC. I'm thinking twice before contributing to them, especially for the ones that use it as a showcase, but for sure if once someone start complaining because I made a joke, they won't see me again. For conference I'm even more careful, because of the IRL factor. And when conference use CoC as a showcase, it's a no go. Pycon is on my blacklist for instance.

What I like the most is how they harass people based on a code that said people should not be harassed, because they «do not tolerate harassment of conference participants in any form».

I'm pretty sure I will never be concerned by this because I'm really respectful, but I like jokes in general, about everything. I'm too afraid to become the target of SJWs that have a code that let them harass people because they are not happy with their opinions.

Hi scopatz, thanks for taking time to comment here. I got the feeling from the other comments here that indeed this blog post was kind of a scam.

I played with xonsh a little bit yesterday and went trough the tutorial, so far I'm pleased with it. I changed it as my default shell for the fun today, but damn, it's hard to re-educate my muscle memory. I will have to do some changes in order to make it usable:

- Customize the VI binding (I have some weird keyboard layout)

- Replace my aliases, scripts, functions, and `source` command that are [ba|z]sh specific (like ranger-cd [1]). This will be time consuming.

- Find why `ranger` takes so much time to quit.

I also have kind of a weirdo bug, but I want to be sure to understand where it's coming from before opening an Issue: It slow as hell when I try to open a terminal, and I have a warning about branch-timeout. The problem is that my home repository is not a literally a git repository. I still have some dotfiles versioned as explained in [2], but if I call `git ` commands from the home it says it's not a git repository, so I don't get why this git-related timeout.

Anyway, I will see if I try to continue right away, or if I wait a few weeks for some holidays in order to find time for the transition.

Thanks for this software!

[1] https://gist.github.com/ha7ilm/37c4272b1df6fbfdb0df304642522...

[2] https://developer.atlassian.com/blog/2016/02/best-way-to-sto...

Thanks for the feedback. I think I'll give it a go!

Thanks. Back in the time I read it I also tried to look at issues to verify the criticism, but I was not experienced enough to fully understand all the topics involved in the discussions.

Except for the performance problem (I'll probably not be concerned with my workflow), what are the pros/cons of xonsh for you? Some of my concerns are:

- Does having direct access to Python really make your work in command line faster/easier?

- Is there some paradigms that are more difficult to express in xonsh (redirect, pipes, …)

- Did you happen to encounter bugs, or made mistakes without intent to do it (like overwriting/removing files, …) ?

In other words, without the performance problem, would you continue to use xonsh and recommend it?

It's a nice idea, I haven't thought of doing so. Maybe if I change the ipython prompt to something more fancy it can be a nice solution.

Thanks for the review! Indeed it seems that this criticism is part of the history now.

I would love to drop bash/zsh for some other python-based shell like xonsh. I tried it already a few times, and having access to the python language and built-ins right from the prompt is amazing. The way the found to mix both command prompt and python syntax seems really smart. Nevertheless, the effort to update all my (quite extensive) zsh setup, as well as the cognitive effort to re-educate my brain, is huge. So I want to have to do it only once. This means it should be A) a project that has chances to survive in the long term, so not dependent on a single developer, and B) that has chances to become the reference one, gathering most of the users/contributors.

I don't know about the current craving for such technologies -- if it is a good idea or not -- nor the place of xonsh in all this. My main concern with xonsh is a blog article (Nov 2015) [1], that implies some issues regarding the management and the direction of the project.

Does anyone have opinion/experience on these python-based shells, the existing alternatives, and more specifically about xonsh?

[1] http://www.skepticism.us/2015/11/xonsh-is-no-longer-a-possib...

> In a larger Vue.js project, you would likely abstract the Event Bus into a single file, importing it into every component file where it needs to be used. This way, it does not pollute the global namespace.

Instead of having to import a file everywhere, I'm used to add the bus to the Vue prototype:

    // Create a bus for global events
    var busVue = new Vue()

    // vue properties
    Object.defineProperties(Vue.prototype, {
        $bus: {
            get: function () {
                return busVue
            }
        }
    }

so I can simply use it from any Vue component:

    this.$bus.$emit('error', 'Impossible to connect to the database')

for emitting, and for binding on:

    mounted: function (msg) {
        this.$bus.$on('error', this.alert)
    }