Re: Translations and Transifex
Hello, On Tue, 9 Jun 2015 21:17:35 +0200 Morten Bo Johansen m...@spamcop.net wrote: On 2015-06-09 Oswald Buddenhagen wrote: do you see what is right below that button on the pricing page? No, nothing that contradicts what I said. Please open my eyes. That's general misunderstanding and confusion which surrounds Github too. Github is proprietary crap, it will die, and die painfully for everyone. What does that mean? It means that you should drop everything and move your open-source project to Github yesterday, to get more of that tremendous boost which it gives to open-source projects. To get more of it, before it dies. If Github is really *that* good. And it is. The same applies to Transifex - if it's really that good that there're many people who do utterly boring task of translating something for god knows which purpose, then everyone should drop their stuff-to-translate there and pray that it's translated before the service dies. When the services like Github and Transifex die, when we go back to stone age, will be living in caves with candles again, people who are able to upgrade a firmware on a builder or figure out a Trac problem in a mere couple of months will be in great demand and honor. Until then, they're just ball-and-chain on project's future, like was pointed out by several independent speakers on this list already. Morten ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
mc clone in C#
Hello, From github annals: subj, and by whom? https://github.com/migueldeicaza/mc README is an interesting read. The project last updated in 2011, but feels like from last weeks' discussions. Feels timeless. Random quotes: Many features that were added to Midnight Commander over the years in retrospect were not very good ideas. ORLY? Nothing but a public condemnation of Gnome's involvement with mc can save your name, Miguel. http://www.softpanorama.org/OFM/Paradigm/Ch04/mc.shtml#MC-gnomegate Although MC had an hex editor, very few people knew how to activate it (Open viewer, activate hex mode, hit Edit). I for one didn't. -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
Hello, On Thu, 28 May 2015 12:11:04 +0200 Egmont Koblinger egm...@gmail.com wrote: Hi guys, [] Instead, I believe it should be a core with 3-5 people who have similar working style and similar vision of the project, and each contribute just a few hours per week. Yes. And generally, it would be nice if these people would be driven not by personal ambitions of something to do regarding mc, but by desire to serve community. And their core responsibilities would be to process submissions, and guide contributors into producing patches suitable for merging. [] I'd be happy to see Mooffie on the team right away, his work (along with his style and the contents of the homepage) totally convinced me. There's concern (which Mooffie himself raises) of de-anonymization. Indeed, for a tool which can be run as root, it would be nice to know who's really that guy who maintains it. I'm sorry to say this, but I myself cannot guarantee anything and cannot make any commitments. I'm spending a long vacation right now where I was planning to do some coding on my primary hobby project (gnome-terminal), and maybe address one or two issues on my secondary hobby project (mc); all subject to my mood. After this vacation I'll start a new job which will require 100% of me. So I'd rather stay an occasional contributor as I am now, and not devote myself to anything with mc. Thanks for finding time to respond during your vacation. But there's a bit of contradiction: you said that you would have Moofie on the team, but then say you can't make *any* commitments (we're already on the same line that there can't be any extraordinary commitments like 20hrs/week or something). So, let me just ask: what do you think should be done now (refarding this whole maintainership situation), and in what timeframe? It would be very nice if there was fresh start right from the start, otherwise it's just the same situation as before: the procrastination, and most people don't know what and how it will be. G-t is my personal hobby project in the sense that I do hunt down and address bugs that cause problems to other people but I myself don't particularly care about. Mc never reached this level for me, I never took time to look at bugs and patches that I myself wasn't personally interested in. Don't ask me why it turned out this way, I don't know - maybe it was because on g-t I got quick feedback of my work, whereas on mc I often had to wait for so long that I almost lost interest, and often missed the free time I had when I could have worked on these issues. Yes, feedback people get on first submission and overall impression is very important. That's why I think that timely responses and formal criteria for processing patches (instead of I don't like) are very important. And that's IMHO what maintainers should work on, anything else can be done by community as guides by maintainers. As for the current segfault issue, I think the broken change should be reverted for now and a .15 released until we come up with a proper solution. I won't say this is obvious, I just say +1. Giant thanks to you guys who maintained this project for years, I'm sad to see you go, and wish you all the best! That's certainly true, and there're a lot to learn from them (while some things to change too). Again, would be nice to have timely and smooth transition, while they still in loop and oversee/help with various issues. e. -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
Hello, On Sat, 30 May 2015 13:56:54 +0200 Oswald Buddenhagen oswald.buddenha...@gmx.de wrote: On Sat, May 30, 2015 at 02:08:37PM +0300, Paul Sokolovsky wrote: On Sat, 30 May 2015 11:53:58 +0200 Oswald Buddenhagen oswald.buddenha...@gmx.de wrote: On Thu, May 28, 2015 at 12:46:08AM +0300, Paul Sokolovsky wrote: You again trying to over-complicate. Start from a clean page on github, while invite community to migrate issues from trac to github. Most content on trac from people who gave up on mc long ago. It makes sense to process what active people are interested in and leave old stuff where it is. nonsense. the old infrastructure is going to disappear at some point, and everything on it will be lost. it is entirely irrelevant that many of the people lost interest - most of the issues are still valid, and a lot of time went into discussing solutions. it would be plain stupid to throw this away, never mind the disregard for other people's work. I didn't propose to throw it away. I proposed to leave it where it is for now and work on github issues/patches (which are also issues/patches, surprise), while ask help from wider community to migrate issues to github. If/when new maintainers ran out of github issues, they certainly will look into trac themselves, either at individual issues, or en-masse migration. The talk is about smooth start for new maintainers without extraordinary efforts. i think you are being a tad overly optimistic here. And you, as few other folks, try to frighten away people with how hard it is. What's the point, what's the plan with such behavior? Hope that someone else will come and tell, yeah, I have 20hrs/week, and I already brought bucket and a mop to start cleaning your Augean stables? Previous cases show that it takes 1+ year for such event to happen, which is not smooth transition at all. just for some perspective: a year ago or so i went through the effort of un-botching the previous import. more than half a decade after the fact. at this rate, there is no reason whatsoever to think that the infra will still be even there when somebody finally feels like doing a migration (midnight-commander.org is owned privately by slavaz). I know, hope Slava/Yury/whoever can maintain it, say, till the end of this year. Again, not doing anything at all and waiting for a knight to save it won't help either. also, the longer you wait, the more work gets duplicated, and the harder it will be to merge the data sets in a useful way. Let's get to a productive tone: your help with the migration will be much welcome and appreciated. that's why i would expect some serious commitment to a migration from somebody who wants to take over with the blessing of the previous maintainers. Sorry, but you cannot expect anything like that. Everything will be done on best effort basis, just the same as was done before, and as always the case with OpenSource projects. Acceptance is the first step. If that is achieved, we can discuss technical and organizational/personal commitments aspects. [] So, you started an argument in githib ticket, then came here just to criticize and repeat 'tis not possible? there is no contradiction whatsoever in that. i can review and discuss despite full awareness that i won't be able to put a final stamp of approval under it. No problem, but there should be finite time put into that, we can't go in circles forever or even too long. Come on, time for productive actions - are *you* ready to be a maintainer? no. exactly because i lack the time (or personal motivation) to make the commitment. it's not like i haven't been tempted during a decade of lurking. Indeed, we talk here not about the best solution, but of not allowing the worst, when project went unmaintained for a prolonged time, and at the same time improving some aspects wrt previous practices. -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
Hello, On Sat, 30 May 2015 11:53:58 +0200 Oswald Buddenhagen oswald.buddenha...@gmx.de wrote: On Thu, May 28, 2015 at 12:46:08AM +0300, Paul Sokolovsky wrote: On Wed, 27 May 2015 22:28:15 +0200 Yury V. Zaytsev y...@shurup.com wrote: For example, one could have set up a script to import Trac tickets into Github Issues. There are many half-way working scripts floating around, but they need testing and fixing. Last time, Savannah import into Trac took quite some effort, but it turned out to be very worthwhile. You again trying to over-complicate. Start from a clean page on github, while invite community to migrate issues from trac to github. Most content on trac from people who gave up on mc long ago. It makes sense to process what active people are interested in and leave old stuff where it is. nonsense. the old infrastructure is going to disappear at some point, and everything on it will be lost. it is entirely irrelevant that many of the people lost interest - most of the issues are still valid, and a lot of time went into discussing solutions. it would be plain stupid to throw this away, never mind the disregard for other people's work. I didn't propose to throw it away. I proposed to leave it where it is for now and work on github issues/patches (which are also issues/patches, surprise), while ask help from wider community to migrate issues to github. If/when new maintainers ran out of github issues, they certainly will look into trac themselves, either at individual issues, or en-masse migration. The talk is about smooth start for new maintainers without extraordinary efforts. I have couple of my patches accepted into mc (trivial, yes, it's on a non-trivial thing I stuck due to lack of discussion), so pass one criteria I myself proposed. My maintainership program would be: 1. Tear off all the unmaintainable code. see, statements like that make me hope very much that you never get direct write access to the repository. Certainly I'm keen to provide full disclosure of my programme, so people aren't surprised later. As for being a maintainer, I'm certainly hope that there will be more suitable people to take that role. But I was asked would I take maintainership myself, and I provided the answer. 3. Require patches with good descriptions (including references), try to respond to pull requests quickly with suggestion, close those which weren't got into shape in 1 month as unmaintainable. that's a nice plan, but requires a quite substantial committment to put into action. which brings us back to yury's conclusions. So, you started an argument in githib ticket, then came here just to criticize and repeat 'tis not possible? Come on, time for productive actions - are *you* ready to be a maintainer? What's *your* maintainership plan? -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Paul Sokolovsky's maintainership application, was: Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
Hello, On Sat, 30 May 2015 13:57:32 +0200 Yury V. Zaytsev y...@shurup.com wrote: On Sat, 2015-05-30 at 14:08 +0300, Paul Sokolovsky wrote: But I was asked would I take maintainership myself, and I provided the answer. Sorry, I missed the answer in your numerous emails. Please see numbered list at the bottom of https://mail.gnome.org/archives/mc-devel/2015-May/msg00069.html , tehn number list at https://mail.gnome.org/archives/mc-devel/2015-May/msg00073.html . My understanding was that there was no answer, that is you don't want to make any clear commitments yourself, but rather prefer to consult other people as to how they should proceed, is that right? No, not right. If not, it would be helpful to know how much time and how regularly you are ready to commit, and what exactly you are going to be working on. As a maintainer, I would consider the most important job is to provide timely response to submissions, and lead submitters into preparing patches in a way suitable for merging. I don't have immediate plans to commit something myself (except for my own patches, once they're reviewed). But if I see that there're many issues reported for some non-core subsystem, or repeated attempts to fix it fail, I way raise the question of removal of that subsystem, and if initial discussion warrants, will prepare patches for that. All my idea of maintainership is based on the fact that I already use github daily, and already maintain many projects. github specifically improved my productivity a lot, while on previous-generation hosting sites I less than a dozen of projects, on github I have 100+ (I don't work on all of them at the same time, usually in round-robin fashion on 3-5 at the same time, plus regularly submit bugs/discuss issues with other projects). On top of that, I don't have free time last 3 years, having even less time last 1.5 years, and with all that I participate/maintain dozens of projects, and come up with new regularly. So, having one more project to look after doesn't add or take much from my situation (with maintenance efforts as described above). Feel free to look at my activity stats on github for perspective: https://github.com/pfalcon I can't give any firm numbers on how much I could spend on mc specifically. But if you want to hear something still, let it me 15min a day, than an extra hour on weekend, 2 hrs per week. If yes, then I'll rather not answer the rest of the mails, because it's going to cost me many hours. Yes, I also consider this proposal to be final, and ready to wait agreed-upon time (max 1 month, my suggestion is 2 weeks) to see if it's useful. I will be only glad if better (like, truly better, which care about community, not some code features) candidates will be found. I will be unhappy if better candidates won't be found and my proposal won't be found useful, but then I tried to be useful for a project which is important to me, and otherwise I don't have lack of projects to maintain. I'll try to post my own plan separately as time permits. Thanks, looking forward to it. Per above, I'd appreciate if there was timeframe set for applicants, so that they knew that if that time passed, and they were not selected, they are free to make other commitments elsewhere. -- Sincerely yours, Yury V. Zaytsev -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
Hello, On Sat, 30 May 2015 14:59:04 +0200 Yury V. Zaytsev y...@shurup.com wrote: On Sat, 2015-05-30 at 15:22 +0300, Paul Sokolovsky wrote: Everything will be done on best effort basis, just the same as was done before, and as always the case with OpenSource projects. That's nonsense; most successful open source projects have drivers who are either employed to invest time into it, or have other circumstances that allow them to invest 10 hours per week as a bare minimum and above. We're talking majority open-source projects here, and mc is for a very long time is far from being successful (but indeed, for a project like mc it's enough to be just existing and maintained). This is where the community shines: if you have several drivers who are able to process contributions in a timely manner, it adds a lot of value, innovation, diversity, etc. Acceptance is the first step. If that is achieved, we can discuss technical and organizational/personal commitments aspects. I don't buy this; the first step is getting some real work done. Then we can discuss the acceptance. Example: Moofie is convincing, because he's done some excellent work and then went public with it. You think that adding more bloat is excellent, I think that it's bad, actually, the only way I can agree to adding more features is *replacing* older bloat, not adding more. He didn't start by showing up and saying: hey, this is my plan, you have to accept it first, and then we can see if I'm actually going to do anything. I'm doing stuff - see my github account. I can do (more) for mc too, given opportunity. But whatever I do, I do step by step, and so far my patch is stuck in the queue without proper review, so I'm not going forward until this problem is solved - replying to people, reviewing their stuff, working with them to make it better to lead into mainline. And that's exactly what I'm ready to start with. And if that's too little - well guys, it's exactly the area where you had problems and clearly need help/improvement. He's already proven everything to me. Good, take him to your team. Please pay attention to everyone's issues anyway. You are not convincing at all, because all you have done so far is to waste a lot of time with your delusional posts (also in the thread started by Moofie!), and it seems that I'm not the only one who isn't very much impressed. Ok, I consider my application rejected, and I'm generally not surprised (I indeed objectively didn't do too much for mc - but again, that's the problem which I'd like to be resolved - for everyone, not just for me - mc should be welcoming of contributions, and help people to help it). -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Article about Midnight Commander on OpenSource.com
Hello David, On Wed, 27 May 2015 08:14:00 -0400 David Both db...@millennium-technology.com wrote: I like Midnight Commander very much. And I have authored several articles for OpenSource.com. My latest, which has been in progress for several weeks - long before the current developers announced that they would be retiring from the project - is about Midnight Commander. Please check it out. That looks very nice, and thanks for these efforts - I'd say that's the area to which few other folks pay attention to, so it's really helpful to know that some people don't just think what will happen when current generation of mc user will die off, but actually try to make sure that new users get acquainted with it. If you want feedback beyond it's cool!, I'd say that you should use default mc theme for screenshots (to give least surprise to users who actually will try it out). Or perhaps have a screenshot with a default theme and your custom theme and then mention in the text that mc is configurable down to the level of theme and colors. http://opensource.com/business/15/5/midnight-commander -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
Hello, There was a post on a popular Russian-speaking IT site geektimes.ru authored from an account with an associated full name Ilia Maslakov titled (translated) ms is over!?: http://geektimes.ru/post/250964/ Link to author's account is at the bottom of the article: http://geektimes.ru/users/smind/ , it has 6th position in user's ratings on site, so likely belongs to the person named. The summarized translation is: Lately, a leading developer wrote in developer's conference: andrew_b: I closed bunch of tickets, but that's likely it. All comes to its end. It weren't worst 5 years in my life. mc is currently as briefcase without a handle: pity to drop, pity to carry. I'm tired of all that, I quit. So, mc development history led by our team comes to a milestone. Myself, I haven't done a commit to master in over a year. The post is written in a clear FUD manner, and implies too many far-fetched things, like: that departure of a maintainer means death of the project, that not this list titled mc-devel is where important discussion and announcements happen, but on delevoper's conference where people speak Russian, etc. The current maintainers, namely Andrew Borodin, Slava Zanko, Ilia Maslakov, Sergei Trofimovich - please provide full disclosure of what happens within your team. Whatever it is, please show goodwill by adding Egmont Koblinger to the maintainer team, if he agrees (including discussions and commit access), to show that the project wasn't usurped by Soviet Obkom. Thanks, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
Hello, On Wed, 27 May 2015 21:04:33 +0200 Yury V. Zaytsev y...@shurup.com wrote: [] If you have been following the development, it would have been known to you that, as a matter of fact, all relevant discussions to the development of mc in the last 4-5 years were happening in Russian speaking Jabber conference at mc-...@conference.jabber.ru . [] to show that the project wasn't usurped by Soviet Obkom. -25 points to adequacy So, there's a bug tracker which doesn't get responses or even triaging, actually for months it's not even possible to submit a ticket at all. There's development mailing list, where it's barely possible to get a response from maintainers either. And yet there's Russian speaking Jabber conference. Keep counting points on adequacy of such maintainership, Yury. Keep suggesting people maintaining their own forks, for years, like you did. One of the problems mc projects has is all this infrastructure. It's stuck on the project model of 90ies. Gosh, it's hard, bloated, time-consuming, inefficient, leading to frustration. But you clutch to it and don't want to try the easy way, until people who support all that Sisyphus work ran out of resources. The last active committer was Andrew, but (unexpectedly to me) he decided to resign as well. Other people gave early warnings that not everything is right with project maintainership, so one can only guess why it's unexpected to you. I have personally publicly asked Egmont to take over the maintaintership multiple times, however, he is understandably reluctant to do so, and no one can force him to do it, if he doesn't want to. It's his decision. Perhaps it should be done step by step, while simplifying infrastructure. Initial steps are very easy: 1. Switch development process to github. Nothing needs to be done, except declaration - everything is already there. People should be just encouraged to submit bugs to github bugtracker, patches - as github pull requests. 2. People with mc experience should be given commit access to github repo. Basic criteria should be patches already accepted from a developer and presence of maintainership program (to be posted on the list). 3. Encourage all interested people to triage new bugreports and review patches. 4. Provide timely response to tickets/patches - point 3 should help with that, but that's the main work of maintainers - communicate with the community (not in the closed circle). 5. Then the hard part is left - quality standards for a release, and making a release. But this should come as natural step after all the above, so hopefully won't be frightening to new maintainers any longer. (But this step will require active involvement of old team, unlike the steps above which are automagic). -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 21:01:38 +0200 Egmont Koblinger egm...@gmail.com wrote: [] Your arguments make me feel that you're personally offended because your pet peeve bug didn't get fixed so far, and in turn you'd like to stop getting something new accepted, just because you'd do it differently. Come on, how can I stop something new being accepted if I can't get even a reasonable response and dialog from maintainers regarding a 5-year old issue with 2-years old patch at iteration #5, to which maintainers themselves contributed?. You overestimate my powers. Otherwise, I do feel for any contributor who submits patches and get ~zero response, so only glad for Mooffie whose patch spurred so unbelievable for this mailing list's last year (or that years?) discussion. (No conspiracy theories please about me and Mooffie playing good and bad cop trying to trick you into accepting it, lol). Well, do _it_ (not something else) the way you'd like to see it, and I'm sure we'll seriously consider accepting that. I do not care about plugins, though glad to discuss approach to them with people who care (I'll get them in software I run too after all). But I'm taking chance to remind that beside exciting new things there're old basic things which has patches, etc. - and waiting for review and progress. And I'd appreciate you consider (seriously or normally) *that*. Until then, Mooffie's work is what we have, and I see no reason to put any obstacle to this. Just beacuse, oh my god, there's another bug that we could've fixed so far but we haven't... Again, please don't put it upside down. I *don't* use my issue as excuse to not look into other things. The maintainers can also consider not taking other issues (which are fixed all the time) as an excuse for not looking into that one. e. -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 13:18:52 +0200 Egmont Koblinger egm...@gmail.com wrote: On Sun, May 10, 2015 at 1:05 PM, Yury V. Zaytsev y...@shurup.com wrote: The problem is that the definition of important is in the eyes of the beholder. I'm sorry, but I personally couldn't care less about #1652, simply because I don't. I recognize that it might be a deal breaker for you, but not for me. However, do I personally care a lot about the list of tickets that mooffie has shown a solution for with his patch. Is it surprising that I'm excited about it? Big +1 for this response. Mooffie's work doesn't address one-off bugs or feature requests, but provides a much better ground for speeding up development and adding cool features. It's way more interesting to me than any other open mc bug. Here we go again - Gnome3 support, hurrah! Adding cool features is **bad** if old basic features cannot be gotten right. cheers, egmont -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 13:44:25 +0200 Egmont Koblinger egm...@gmail.com wrote: On Sun, May 10, 2015 at 1:25 PM, Paul Sokolovsky pmis...@gmail.com wrote: Brief response, and we've heard each other's opinion, and I'm not trying to convince anyone or go into endless debates/flames. Trivia quiz or what? Ok, unix rewrote multics bloat, lives so far, multics dead for big decades. gcc rewrote a lot of older vendor compiler crap. llvm/clang rewrote gcc to let vendors do more compiler crap. Etc, etc. And compare the engineer staffing of these projects to mc's. Okay, I should rephrase my question: in a project that hardly has resources to fix even the most critical bugs (e.g. currently there's a segfault in 4.8.14 and no solution yet), what are the changes of successfully reimplementing 20 years of work from scratch? I believe it's 0. Not zero-point-lots-of-zeros-one, but zero. Egmont, things you're saying are very depressing ;-). Maybe looking around for some inspiration would help ;-) I for example find http://litcave.rudi.ir/ very inspiring - the guy is not too shy to write his linker, assembler, compiler, mail client, mailer, pdf reader, etc. And he's not afraid of 20 years of work because stuff he does just works, and dozens of years are needed for bloat, not real thing (also, living somewhere by the warm sea in an orange garden and sequencing DNA as day jobs probably helps too ;-) ). (This passage, as some other, not directly related to mc hacking of course, but rather a generic weekend software engineering gossip). Does that mean that you've got commit access? No, I don't have. (Why is it relevant?) Because you spend time communicating on mailing list. And we know, the biggest problem mc project has is lack of communication from decision- and commit- makers. [] Nice speech, but can we please have simpler issues which waited in queue for years be tackled first? Not sure what you mean by this. I know that many bugs weren't addressed, but in the mean time many others were. Mooffie's work provides a better ground for quicker development in the future. He's not solving issues one by one, but helps solving any subsequent ones more effectively. Yet you argue that instead we should focus on continuing fixing bugs one by one... Yes, please fix handful of bugs in core/basic things in components. Leave bugs which can be fixed with Mooffie's work for later. If mc is 20-old project, then it should have some quality, and there shouldn't be more than that handful of core/basic bugs. And the editor is a core component (you're not writing it in a scripting language), and bugs are certainly - for example, after you fixed copy/paste in editor, working with it no longer an ordeal (I can't believe I used it with paste like it was before - I must be a real hardcode mc fan). Only few bugs left. Reasons for fixing them are provided. Patches are provided. Leave aside any VFS and similar stuff - it's obvious that the only way to get it right is to rewrite in scripting language. Anyway, Mooffie has shown us some code. You don't quite like it, you'd take a totally different approach. Okay, your turn, convince us, show us the code please ;) My whole motive is that before adding exciting new stuff (which is hardly new - as I argued even *rewriting* entire mc in scripting is pretty obvious choice, and scripting support should have been there ages ago) - old stuff should rather be fixed, especially if all data/code for that is provided. So, I showed code - https://github.com/MidnightCommander/mc/pull/49 . If there completely formal fears for editor binary safety, I proposed to have it configurable and off by default. And if that code is not good, someone else can show other code. And if there's no such code, then maybe time to think that mc is used by real people for real tasks, and just take the existing code to let people do them. (Which is the same what I wish to Mooffie with his code - however incompletely perfect it may be). cheers, egmont -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 13:45:09 +0200 Yury V. Zaytsev y...@shurup.com wrote: On Sun, 2015-05-10 at 14:25 +0300, Paul Sokolovsky wrote: Trivia quiz or what? Ok, unix rewrote multics bloat, lives so far, multics dead for big decades. gcc rewrote a lot of older vendor compiler crap. llvm/clang rewrote gcc to let vendors do more compiler crap. Etc, etc. Less features is good. I consider mc a unix tool, it's not replacement for command line (or overbloated vendor IDEs), it should do not too many things, but do it right. So, are you undertaking to rewrite mc in the same way as llvm/clang folks rewrote gcc? I considered that. But mc kinda works, and there're lot of stuff which doesn't exist ore really not good enough (for example, llvm needs to be rewritten in scripting language, yeah), I unlikely will ever get to it. But if this talk will inspire someone else to do it - very nice. (I recently got inspired to start another project I had in queue for ~10 years - that's how it works with people). [] If not, then, I'm afraid that I'm not interested in continuing this line of the conversation. ... and the conversation is focused around priority of things to do, which I argue should be fixing old bugs, then proceed with new things. Because is exciting new is the only thing you're after, then rewriting mc would be the best way to get a lot of that new and exciting. And for mc, I'm sure it's not the first patch to integrate some scripting. I'd be curious to learn about the previous attempts. I don't imply I know them, but I can't believe over 20 years nobody thought about that to a level of hacking something up. I'd have done that long ago, if mcedit inspired me to do that, instead of frustrating ;-). Nice speech, but can we please have simpler issues which waited in queue for years be tackled first? My list of *lacking* (not nice to have, like plugins in scripting language) is simple and short: But wait, I have my own list! It's simple and short: fix the regexp stuff and directory compare. How about my list? And I'm sure that Egmont has his own list. How about his list? What makes your list better than ours? There're half-dozen active people on this list. Couple of issues per person = 12 issues. Let's be fair and consider tickets too: among hundreds multi-year ones, there probably about same half-dozen which still have people moaning behind them. ~20 issues to fix - not too bad. Btw, directory compare would better be handled by scripting - there can be multiple criteria which you may want to use, hacking scripted source on demand would be cool. Regexp is core stuff, needs fixing, yeah. -- Sincerely yours, Yury V. Zaytsev -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 13:05:42 +0200 Yury V. Zaytsev y...@shurup.com wrote: On Sun, 2015-05-10 at 13:12 +0300, Paul Sokolovsky wrote: As a shameless plug, I can offer a better alternative: https://github.com/micropython/micropython . It would offer about the same footprint as Lua, while offering more pleasant data model, and well-known standard library. As a full disclosure, it's rather younger than Lua (but pretty well developed at 4K commits) and it would be first (known, as it's BSD, anyone can do it secretly) standalone project to embed it. I really like Python and, of course, I know about MicroPython. Now, let's do a simple reality check: 1) How many distributions have it packaged so far? You ask as if it was a systemd and you're looking start witchhunt against distro which still didn't include it ;-). 2) Does it already provide a stable embedding API? Nope, that's why I think it would be interesting to have use of it like that, to establish it ;-). 3) How complete is the standard library? (I know...) Good news: there's a standard library, I mean something which really can be called that! Unlike Lua. 4) Does it have a JIT? (okay, this one is unfair) It has AOT, which is cooler, as you get timing guarantees. Also, *Lua* doesn't have JIT. It's a separate project, whose API is compatible or not. Python as a language does have JIT, if you need that for plugin scripting. 5) ... Sorry, but I don't think that MicroPython is a viable choice, unfortunately. However, in the end, I don't think that it's a big deal: there is Lupa and Lunatic Python, so once the support for Lua gets in, you can use Python just as well. At the same time, if you absolutely want to use Python directly, in theory, you can later re-use the same infrastructure for MicroPython. Fairly speaking, Mooffie is very lucky that his random hack got so much attention. There're simpler and more important issues which are open for 5+ years The problem is that the definition of important is in the eyes of the beholder. I'm sorry, but I personally couldn't care less about #1652, simply because I don't. I recognize that it might be a deal breaker for you, but not for me. That's why it's important that *maintainers* take formal criteria of completeness and lack of random gaps in functionality. And higher-level criteria, like mc being an open-source project, which naturally should be expected to be used for, and appreciate needs of open-source software. And OSS is very diversified, including line-endings. I'm, as an open-source developer, deal with at least a dozen new projects each month, and regularly hit cases when mc instead of helping, complicates me contributing to such software (by not allowing to edit files comfortably). So, yes, you personally may not care about it, but this issue - of diversity of real-world files - objectively exists. However, do I personally care a lot about the list of tickets that mooffie has shown a solution for with his patch. Is it surprising that I'm excited about it? Let me translate: you're excited to add yet another toy-like, bloat feature, which will of course be buggy - instead of fixing what's already in queue (and I know not everyone cares about #1652, it's just an example of ~1 thing which makes me frustrated about mc, instead of making me happy, I'm sure it's similar for many other people - there're merely several long-standing issues to fix, new features can wait). I hope that your patch eventually will get reviewed and merged, as long as it doesn't affect the binary safety by default, but this can't be me, sorry about that. I do hope so too, especially that again, it's not exactly my patch, few people contributed to it, they just lost the already, apparently. By the way, I wonder if hooks can be added to the editor so that it would be viable to implement the line endings autodetection via the scripting engine... Please, no! Get it right first, so it worked for 99% cases without any scripts, then work on creeping featuritis to let people do mind-boggling things. -- Sincerely yours, Yury V. Zaytsev -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 15:13:17 +0300 Andrew Borodin aboro...@vmail.ru wrote: On Sun, 10 May 2015 14:25:50 +0300 Paul Sokolovsky wrote: the patch exists http://www.midnight-commander.org/ticket/1652 , and only held by exactly perfectionist attitudes and lack of more general response. I don't have words other than I wrote in ticket comments. Yes, but beyond literal words you wrote (which is, sorry, nitpicking and word-play of hide vs remove), your concern is editor binary safety. I replied that with last iteration, I did all due diligence to minimize (in a real-world sense) possibility of mistaken line-endining detection, but if you still consider that not good enough, I proposed making the detection optional, and off by default. And that's where it stuck, though there really would rather be further discussion. Another obvious choice is that you (or someone else) propose the code to do it right. So please let's have further discussion - leaving it hang for next 5 years is hardly helpful. -- Andrew -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 14:51:17 +0200 Yury V. Zaytsev y...@shurup.com wrote: [] That's why it's important that *maintainers* take formal criteria of completeness and lack of random gaps in functionality. And higher-level criteria, like mc being an open-source project, which naturally should be expected to be used for, and appreciate needs of open-source software. And OSS is very diversified, including line-endings. I'm, as an open-source developer, deal with at least a dozen new projects each month, and regularly hit cases when mc instead of helping, complicates me contributing to such software (by not allowing to edit files comfortably). So, yes, you personally may not care about it, but this issue - of diversity of real-world files - objectively exists. Your argument is zum Besten der Armen; everybody knows that the situation with the maintenance of mc is suboptimal to say the least. However, it's all in your hands: 1) You can maintain your own patchset on top of mc, like I did for years, and it's not as difficult as it might seem That's kinda what I do, but I find myself behind it all the time (mc is basic background tool for me, I don't dream about maintaining my won fork of grep). And when I spawn a new EC2/vagrant/docker box, I want to use it right away, not clone and build source. I also want to grin at the sight of vim/emacs/idea/whatever and say that solution of my community is better (so far I would lie). 2) You can keep pesting the current maintainers and hope for the best (like Egmont does, and more often than not, he is successful at that, so maybe if you aren't, then there is something you could have done differently, if success is your ultimate goal in the first place) My ultimate goal is mc's success, not my patch's. I'd be happy if someone reimplemented that patch with complete binary safety. That's certainly what I tried first, but found that with current editor codebase it will be quite cumbersome (entails lots of bugs), and will make the codebase even more cumbersome. As you guessed, my next step was not to rewrite editor, but to look for realistic and sustainable way to implement it, and I keep pushing it, because other folks actually contributed to it to make it better, so it would be nice to lead somewhere. [] The possibilities are endless. Instead, you keep complaining on the mailing list that somebody who submitted something you didn't like got the attention you think should have been rather given to you. That's your choice. Good luck! I'm discussing it. And attention not to me, but to issues (I just have one to be really concerned about, all other were already resolved.) -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 10:49:40 +0200 Yury V. Zaytsev y...@shurup.com wrote: On Sun, 2015-05-10 at 03:42 +0300, Mooffie wrote: (I already know some places where I'll get criticism. E.g., in places where I didn't wan't to refactor things in the old code (e.g., in src/filemanager/panel.c). Why didn't I? because I didn't think it was wise to refactor/modify old code before I first get an ok on the big picture.) Just to clarify, the fact that I'm excited about your work, think that it's amazing and don't want to bikeshed over Lua (which personally I don't like by the way, but at the same time I see no better practical choice, so let it be Lua!), doesn't mean that somebody else doesn't have a different opinion :-) As a shameless plug, I can offer a better alternative: https://github.com/micropython/micropython . It would offer about the same footprint as Lua, while offering more pleasant data model, and well-known standard library. As a full disclosure, it's rather younger than Lua (but pretty well developed at 4K commits) and it would be first (known, as it's BSD, anyone can do it secretly) standalone project to embed it. Andrew seems to be genuinely interested, which is great, because he can do a proper review. How about Slava and Ilia, what are you guys thinking? Slava, would you be able to make time for a review? Fairly speaking, Mooffie is very lucky that his random hack got so much attention. There're simpler and more important issues which are open for 5+ years, to whose solution number of people contributed over these years, including Slava and Ilia themselves, and which are stuck with no review/response (not counting completely out of way, bureaucratic write-offs): http://www.midnight-commander.org/ticket/1652 https://github.com/MidnightCommander/mc/pull/49 Egmont, would you be able to do as much? Formally you are not part of the core team, but then again, if Andrew ends up being alone to look at all this stuff, another pair of eyes would definitively be of help... -- Sincerely yours, Yury V. Zaytsev -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Thu, 7 May 2015 23:27:23 +0200 Egmont Koblinger egm...@gmail.com wrote: Hi, Did you... er... did you just rewrite half of mc... adding plugins and stuff...?? It would be indeed cool to remove all that gnome-ish bloat accumulated by decades, but - what a disappointment - home page says that to accomplish such feat there is no need to modify MC’s main code.. Generally one good approach to deal with the situation would be to rewrite mc completely in a scripting language. Extra points for using language in which array indexing starts with e or pi, or going straight to Brainfuck. No, I'm ironic with the last sentence on Lua choice, but I really think the way out of the maze is rewriting mc from scratch, and then surely in a decent scripting language. At this moment all I can say is: WOW! e. On Thu, May 7, 2015 at 10:23 PM, Mooffie moof...@gmail.com wrote: Hi guys! I've just published a branch of MC with Lua support: http://www.typo.co.il/~mooffie/mc-lua/docs/html/ See the screenshots link. Also see the other documents link for background (especially HISTORY). Many, many tickets can be solved with mc^2, but I don't want to spam the ticket queue with my posts, so I've prepared a list of some such tickets (see other documents - TICKETS). (But in a few tickets I *will* comment: in tickets I believe a constructive discussion could ensue, or where I feel people are truly in need of a solution.) == Now, I guess I'll be attacked for one reason or another. Let me save your time by attacking myself for you: == Q: Is this a 'fork' of MC? Are you trying to split the community? A: No, this is not a fork (as per Wikipedia's definition). It's intended to be food for thought for the MC community. My hope is that eventually the principle behind mc^2 will be adopted by MC. == Q: Is seems that you've invested a lot of time in this. Gosh, why waste human resources?! Especially on something that nobody's going to use? A: The time I waste here is negligible in comparison to the time and efforts wasted by tens of people who have tried to contribute code to MC over the years. The principle behind mc^2, if adopted by MC, is going to put an end to this waste of human resources. == Q: But why use Lua?!?! Why not pick the language that starts with 'P'?! Why not make it work with any language?!??! A: Let's not talk about languages/VMs *right now*. Please, as much as it's tempting. Right now, the language is not the issue. The issue is the principle, of having some extension language. The language/VM is obviously something everybody will have something to say about. You will. But not now. If every passerby here will now emit his 2 cents opinion/rant, it will kill the vision/project. It will start a Holy War. It will derail the discussion from the mainroad to the gutters. It's the least constructive thing that could happen. It means death. In the future, when we know the principle will be regarded favorably by MC's maintainers, we could open this issue and discuss things. One thing's for sure: You can't give an opinion about the subject without considering it for at least a week (or a month, I'd say). There are various facets to consider. There are threads of thoughts to be picked and discarded. There are insights to be acquired. You can't just barge in with use Python!!, use Parrot!, use GObject!. As the Chinese saying goes, Opinions are like belly buttons: everybody has one. It should take more, much more, than an opinion to affect the discussion. So, again: let's not talk about languages now. (For the record: I recorded my reasons for choosing Lua in other documents - HISTORY.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: HUP poll
Hello, On Mon, 30 Mar 2015 21:25:50 +0200 Egmont Koblinger egm...@gmail.com wrote: Hi, Just for fun: The Hungarian Unix Portal's current poll is about mc (http://hup.hu/szavazasok/20150330/a_midnight_commander), where the options are (in order): - no clue what it is - is only for noobs (not installed) - installed, but I seldom use it - the first thing I install on a new system - other, I'll describe - only interested in the result Check out the site for the current results :) How can one vote? ;-) cheers, e. -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc: (Lack of) Line break type autodetection - 5th year anniversary
Hello, Ping. On Sat, 6 Dec 2014 21:43:01 +0200 Paul Sokolovsky pmis...@gmail.com wrote: Hello, We recently had a nice optimistic thread about mc's 20th anniversary, and I'd like to draw everyone's attention to another anniversary - 5 years of provide better editor support for files with CRLF encoding bugreport: http://www.midnight-commander.org/ticket/1652 . What's more interesting is that it had a patch for 4 years too, and yet it's not fixed in the mainline. Few people contributed to the most authoritative patchset (https://github.com/MidnightCommander/mc/commits/1652_autodetect_lb), 2 of which are mc maintainers, so the patch had good chances being merged long ago. As it wasn't, apparently the party to blame is the original author of patchset, which is me. So, trying to resolve this situation, I rebased 1652_autodetect_lb branch onto the latest master, and made auto-detection much more conservative to address concerns of editor binary safety (note that auto-detection is of course off by default anyway). I tested it to behave as expected, unittests were provided by Slava Zanko and updated to the latest changes too. The pull request is submitted on github, to make it one button click away from being merged - assuming it is ok. I'm also ready to address any concerns raised. https://github.com/MidnightCommander/mc/pull/49 Thanks! -- Best regards, Paul mailto:pmis...@gmail.com -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Bug tracker doesn't work
Hello, On Thu, 18 Dec 2014 14:08:57 +0300 slava zanko slavaza...@gmail.com wrote: Hi all, I've fixed Trac, but have yet another issue: long awaiting time to post comments. So, it's apparently the same problem: there was too long waiting time before, up to frontend webserver timing out waiting for reply from Trac, while operation was actually carried over. Can you please reply something to a proposal of using Github more actively? Thanks. 2014-12-16 9:55 GMT+03:00 Andrew Borodin aboro...@vmail.ru: On Sat, 13 Dec 2014 15:23:03 +0100 Egmont Koblinger egm...@gmail.com wrote: I'd like you to understand that at this point that fixing the development architecture and process of mc is the most critical issue, pretty much blocking everything else. Slava is working on fixing bugtracker. Unfortunately, I can't help him because I don't have any experience of administration and support of real web services. -- Andrew ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Bug tracker doesn't work
Hello, On Sat, 13 Dec 2014 15:23:03 +0100 Egmont Koblinger egm...@gmail.com wrote: [] At this point, you spending your time on fixing issues like pasting in mcedit (to mention one random) won't get the project anywhere other than its grave. You need to fix the development processes so that others can join the effort and they can fix pasting in mcedit and hundreds of similar technical issues, without being blocked by a broken bugtracker and nonresponsive developers. +1 Well, it's certainly not bad that maintainers keep fixing bugs per their local queues, but ignoring most of the other project communication doesn't call for bright thoughts about project process and future. Regarding brokenness of the current project infrastructure, if we really talk about project dying, one approach is not to exert extraordinary (*) effort to revamp it and then keep applying same extraordinary effort to maintain it. Instead, current infra can be frozen and development process switched completely to a quality for free offering, specifically github. (*) If people say I didn't have much free time in last 3-4 years, then any effort taking more 15min average daily is extraordinary. thanks, egmont -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Ctrl-A, Ctrl-E have no effect
Hello, On Sun, 7 Dec 2014 09:51:06 -0800 Graham Lawrence gl00...@gmail.com wrote: [] My laptop lacks certain keys, notably Home, End, PgUp and PgDown. Alt-V and Ctrl-V provide the function of PgUp and PgDown. Supposedly Ctrl-A and Ctrl-E should supply those of Home and End, but in fact do nothing. Hmm, and prooflinks for should part? Not sure what you mean by this, but I'm referring to both /etc/mc/mc.keymap and /etc/mc/mc.default.keymap as the source of should ..., which on my system lists these two entries Home = ctrl-a; alt-lt; home; a1 End = ctrl-e; alt-gt; end; c1 None of these options work for me. Yes, that's what I meant, thanks. I just find it surprising in non-exciting sense that there're too many key combos in mc, not known to many people (for example, I find it quite confusing that Ctrl+V is bound to page down). I've tried putting other key combos in mc.keymap instead, but they also had no effect. Do I need to make a special compile of MC to get their particular functionality, or is there some other means to that end? You can try Learn keys functionality to redefine mc keys to some extent. That I did, with no success. I duly pressed Space with Home and End the current selection, pressed Ctrl-A/E respectively and then repeated that key-combo when the Help message cleared, but in neither case did it then show OK for the choice. I can confirm that it doesn't work for me either (with git master). Out of curiosity, do you have your keys broken, or you one of these laptop novelties which don't have important keys? In the latter case, I gather there should be hardware/firmware key combos to emulate Home, End, PgUp, PgDn, etc. At least, that's what I have on Samsung ARM Chromebook. Otherwise, yes, I guess the only option currently is to patch source code. -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: bad mc-edit paste behavior?
Hello, On Sun, 15 Sep 2013 12:16:53 -0400 Felix Miata mrma...@earthlink.net wrote: http://lists.opensuse.org/opensuse-kde/2013-09/msg00072.html seems to describe a bug in mc-edit. Is the responder there correct that auto-indent switched off would stop the bad behavior? Should it need to be? Adding all those spaces and/or tabs doesn't make any sense to me regardless of how line endings are handled. I've been having that problem for ages - with Gnome though. If you think about it, it's logical, assuming pasting is handled by terminal emulator, and not mc itself. And term emu can only implement pasting by sending pasted content as key presses, including spaces and tab, and mcedit, with autoindent on, has no idea that it's something else but keypresses, so blindly applies autoindent as usual. So, long ago I indeed worked that around by going to setting and turning autoindent off then on (boring!). Then however I noticed that depending on the way you paste you may be able to work it around by several paste attempts. For example, Gnome terminal has 3 ways to paste: menu command, Ctrl+Shift+V, Shift+Ins. So far, my background pattern matcher didn't find exact rule what works better, it seems to be just non-deterministic, though intuitively, Shift+Ins appear to work better. The way to resolve it would be to handle paste on mc side, and knowing that mc already has some X integration, I may imagine, when Shift+Ins works, that's what happens. The culprit is that it doesn't work all the time and with all paste methods. Which probably partly due to braindead X clipboard design (multiple buffers, etc). -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
How screen content saving handled in xterm case?
Hello, Yesterday I spent couple of hours trying to trace how shell screen content is working in case of xterm terminal. While handling in case of linux console is very visible, and otherwise there're some checks for xterm/rxvt stuff, but I couldn't find exact escape sequence(s)/exact place where saving is done in case of xterm. I also tried to approach it from the other side, by looking at xterm escape sequences docs, http://www.xfree86.org/current/ctlseqs.html , and neither could find something which is clearly usable for screen saving, like command read char/rect. So, any hints how that magic is done? What I'm trying to do is to figure out why Android terminal emulators don't save screen content with mc. Thanks, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: How screen content saving handled in xterm case?
Hello, On Mon, 2 Sep 2013 11:44:42 +0200 Egmont Koblinger egm...@gmail.com wrote: I think you're looking for alternate screen buffer. Holy cow! Yeah, I saw this, but nowhere the docs says that content is saved in these buffers when switching. And trying it, when switching from normal to alt then back to normal, normal's content is saved. But from alt to normal, back to alt, alt's content is lost (buf cleared). Holy cow! Whoever will bang their head on this, the sequences to try in shell are: Switch to alt buffer: echo -e \E[?47h Back to normal: echo -e \E[?47l In mc, this is handled in win.c do_enter_ca_mode(), do_exit_ca_mode(), which are of course very insightful names for this kind of stuff. Thanks much! egmont On Mon, Sep 2, 2013 at 11:39 AM, Paul Sokolovsky pmis...@gmail.com wrote: Hello, Yesterday I spent couple of hours trying to trace how shell screen content is working in case of xterm terminal. While handling in case of linux console is very visible, and otherwise there're some checks for xterm/rxvt stuff, but I couldn't find exact escape sequence(s)/exact place where saving is done in case of xterm. I also tried to approach it from the other side, by looking at xterm escape sequences docs, http://www.xfree86.org/current/ctlseqs.html , and neither could find something which is clearly usable for screen saving, like command read char/rect. So, any hints how that magic is done? What I'm trying to do is to figure out why Android terminal emulators don't save screen content with mc. Thanks, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
