Если ты меня не понял, значит пока не время.

Я тебя понял (как мне кажется). Ты говоришь о том, что не до конца осознаешь почему нравится FAR - согласен. Но ты тут же говоришь что не можешь это осознать - вот это неправда, можешь. Также ты, судя по всему, не хочешь осознавать причины любви к FAR. На что я и ответил, что такой подход пагубен.

Кроме того, я тебе подсказал пару моментов, которые уберут некоторые из твоих неудобств из mc. Это должно тебе, как привыкшему к FAR, помочь в случае, если ты все-таки решишь пользоваться mc.

Сорри

Принято.

Не хочешь - пожалуйста. А вот тот же Паскаль тебе такого не даст.

У обоих грамматики не завязаны на перевод строки, отформатировать можно как угодно. Скажется отсутствие #define-а в C-шном смысле. В остальном — записать все в строку никто не запрещает и в паскале.

Почему нельзя обходиться одним товарищем комманд комом?

а при чём тут команд ком?

Я выбрал другой метод: просматриваю прямо с флэшки, удаляю всю шевеленку и прочий брак (прямо в geeqie, делитом). Потом скопом все копирую во временную директорию для последующего разбора. Вот тут уже, теоретически может и mc пригодиться.

Гуёвый файловый менеджер

Кстати, да. Можно смотреть миниатюры. Хотя это не всегда помогает. Очень часто попадаются два почти идентичных кадра, но на одном резкость чуть получше, или меньше засвечен. На миниатюре этого не видно.

позволяет быстро перейти куда надо

На это есть алиасы. Крайне удобная вещь в zsh. Например ~enbook = /media/main/Books/English

Насчет «сравнить директории», соглашусь - тоже mc пользуюсь в таких случаях.

И когда не могу понять, «куда делись мои файлы?!!». Но в последнее время заметил, что это случается все реже. ls | grep *name* и все находится. Если не находится, то надо вспоминать, чего натворил. Двухпанельник не поможет, если удалять файлы, не думая.

А с непомуком у меня не сложилось. Во-первых он все время что-то индексирует (такое чувство, что ты попал под ревизию). Во-вторых, не совсем понимаю, зачем он мне. Разве что в распухшем Downloads копаться. Но и там - своя тематическая структура.

Но давай посмотрим правде в глаза Atl+что_то_там - тоже две клавиши ;)

Для поиска и истории автодополнения в Far никаких Atl+что_то_там нажимать не нужно, просто начинаешь набор и все.

Нет.

Я и говорю, жаль. Было бы удобно.

Вот это реально неудобно.

Тут спорить не буду. Как уже заметил KRoN73, в фаре все что касается работы с ftp/sftp/scp/ssh так себе. Только самба на высоте. Но это понятно.

Это ты знаешь что это tar пожатый gz, а как это узнает mc?

Я тут не причем - ключа z нет.

Думаю он не полагается на имена а распаковывает пока может.

Сильно сомневаюсь. Решение о том что в файл можно зайти явно по имени принимается.

У обоих грамматики не завязаны на перевод строки, отформатировать можно как угодно.

Я не про то.

Вот смотри, допустим есть массив arr целых чисел из 10 элементов. Считаем сумму.

Классический цикл C:

for ( int i=0 ; i<10 ; i++ )
  sum=sum+arr[i];

Все просто и понятно. Но, например, после PHP мне больше по душе такая запись:

for ( int i:arr )
  sum=sum+i;

Еще проще, и дает понять, что обход идет по всем элементам массива, а из прошлого примера это не очевидно.

А если нужно начать не с первого элемента, а того, на котором поиск остановился в прошлый раз, и значение которого уже в i?

for ( ; i<10 ; i++ )
  sum=sum+arr[i];

Здесь сразу бросается в глаза, что инициализации нет. Как ты будешь на Паскале писать? for i=i... ?

А если то же, но мы копируем в другой массив?

for ( ; i<10 ; i++, j++ )
  arr2[j]=arr[i];

Здесь сразу видно что на каждой итерации идет приращения двух индексов. То же, но если мы хотим прервать цикл не только по значению i.

for ( ; i<10, arr[i]<>0 ; i++, j++ )
  arr2[j]=arr[i];

Преимущество - все действия, которые относятся к циклу в одном месте насколько это возможно.

А если у тебя не arr, а что-то типа someObj.someMember[anotherObj.index].somePointer->arr ?

for ( auto i=someObj.someMember[anotherObj.index].somePointer->arr.begin() ; 
           i!=someObj.someMember[anotherObj.index].somePointer->arr.end() ;
           i++ )
  sum=sum+*i;

(Здесь, правда, не совсем простой массив, но не суть). Заголовок громоздок, но внутри у нас остается только *i. Кроме того такая конструкция более универсальна в плане работы со структурами данных, ведь ты данные можешь хранить не только в очереди, но и в списке, и т. п.

Зачем все это? Затем что код должен рассказывать сам о себе. Он должен описывать то, что задумал программист. Так легче разбираться в своем коде, да и в чужом. Именно поэтому есть несколько видов циклов: цикл for так вообще заменяется на while, а в C можно и наоборот, еще есть do ... until. Да что там - можно вообще делать циклы с помощью goto. Но так ведь не делают, верно? Потому что затрудняет понимание кода.

Конечно, тот кто плохо владеет языком, может наоборот запутать. И это №1 претензия к C++: непонятный код. Но на самом деле это претензия к программисту, а не к языку. Дело в умении. С++ просто дает массу вариантов.

Да, Паскаль я давно пробовал, может он это тоже все умеет. Тогда напиши аналог для моих примеров вверху. Но то, что мне бросилось в глаза при изучении С - его гибкость. Ну, и возможность не делать чего-то, что не нужно делать - ориентированность на производительность и ресурсы компьютер. Но это отдельная история.

for a in arr do sum+=a;

for i:=i to ... do

вполне очевидно происходящее.

for ( ; i<10 ; i++, j++ )
  arr2[j]=arr[i];

for i:=i to 9 do begin
  arr2[j]:=arr[i]; inc(j);
end;

move(arr[i],arr2[j],sizeof(arr[0])*(10-i));

for ( ; i<10, arr[i]<>0 ; i++, j++ )
  arr2[j]=arr[i];

for ( ; i<10 && arr[i]<>0 ; i++, j++ )
  arr2[j]=arr[i];

for i:=i to 9 do begin
  if arr[i]=0 then break;
  arr2[j]:=arr[i]; inc(j);
end;

for ( auto i=someObj.someMember[anotherObj.index].somePointer->arr.begin() ; 
           i!=someObj.someMember[anotherObj.index].somePointer->arr.end() ;
           i++ )
  sum=sum+*i;

for i in someObj.someMember[anotherObj.index].somePointer^.arr do
  sum=sum+*i;

Только все это не показатель ни сильных, ни слабых сторон одного и другого языка. К тому же, воспроизводить подходы одного в другом буквально — дурное занятие, лучше достигать алгоритмической эквивалентности с использованием обычного для каждого из языков подхода.

mc mc mc mc mc mc mc mc mc mc mc

Много чего в mc не хватает, если Far'ом не только как запускалкой файлов пользоваться :)

DoubleCommander? Krusader?

Я тебя понял (как мне кажется). Ты говоришь о том, что не до конца осознаешь почему нравится FAR - согласен.

Да, это что-то по Фрейду.

Это должно тебе, как привыкшему к FAR, помочь в случае, если ты все-таки решишь пользоваться mc.

Пробовал. Расскажу про ощущения - для меня это всё равно что с Тойоты пересесть на Калину (было реально). Хотя, в Тойоте нет ничего такого, чего не могла бы Калина. Просто другой уровень.

Также предлагаю записывать почему FAR круче MC

https://docs.google.com/document/d/1IXdrtybnKC7Sl2i94qxIOVQTytk-2hOmdjptjXSGp...

Предлагаю ближе к «телу». Будет LinFAR, будем сравнивать, а сейчас сравнивать пока нечего. Посему создай пожалуйста два таких же документа: первый - список пожеланий (свободный формат); второй - техническое задание, нужны спецы - расписать архитектуру.

При том, что лишние сущности не нужны.

На это есть алиасы

Я про юзкейс «вот у нас тут проект, в нём от десятка до полусотни директорий на каждом уровне. В частности, есть директории Lib, LIBS, Db, DBM, CommonDB и _DB. Мы знаем, что в одной из директорий, название которой похоже на lib, находятся нужные нам файлы. Нет, мы не знаем, как их зовут, но если увидим - тут же узнаем в лицо».
Это, конечно, клиника, но это и реальная жизнь :(

В разумных пределах же.
Если есть файл мэнэджер, зачем ещё какой-то? Почему нельзя пользоваться одним годным? FAR вот вполне в себе объединял всё необходимое.

Только комманд.ком, только хардкор! Фары твои - оболочки дешёвые.

FAR вот вполне в себе объединял всё необходимое

Понятно, это уже медицинский случай. Влияние оболочки дешёвой на неокрепшую дестскую психику. Куда смотрит Госдума, куда смотрит Астахов?

Да, Паскаль я давно пробовал, может он это тоже все умеет. Тогда напиши аналог для моих примеров вверху. Но то, что мне бросилось в глаза при изучении С - его гибкость. Ну, и возможность не делать чего-то, что не нужно делать - ориентированность на производительность и ресурсы компьютер. Но это отдельная история.

все бы ничего, но блять работа со строками в С - это просто пиздец. грабли просто на каждом шагу. То же с указателями всякими.

все бы ничего, но блять работа со строками в С - это просто пиздец. грабли просто на каждом шагу.

Открой для себя тип string (компилить с помощь 'g++ -std=c++11' ):

#include<iostream>
#include<string>
#include<stdio.h>

using namespace std;

int main()
{
        string s;

        s="This is a string"; // Присваивание - легко
        s.insert( s.find("string"), "cool " ); // Вставить строку - очевидно
        if ( s == "This is a cool string") // Сравнение - как для всего остального
                s[10]='C'; // Обращение к конкретному символу - как всегда
        s+=" of size "; // Конкатенация - как два пальца
        s+=to_string( s.length()+2 ); // Число в строку - легко

        cout << s << "\n"; // Канонически правильный способ
        printf( "%s\n", s.c_str() ); // Кто еще не отвык от старого С

        return 0;
}

This is a Cool string of size 32
This is a Cool string of size 32

Про указатели тоже в большинстве случаев можешь забыть.

Добро пожаловать в C++ :)

Открой для себя тип string (компилить с помощь 'g++ -std=c++11' ):

намного лучше! теперь буду знать, что делать есличо. Я конечно С++ ненавижу, но ради такого случая можно и поюзать.

Но с другой стороны - это все в паскале хз с каких времен уже есть :)

Но с другой стороны - это все в паскале хз с каких времен уже есть :)

Паскаль - язык более высокого уровня, чем С. Так и задумывалось, чтобы С был максимально близко к ассемблеру, но удобней ассемблера. Ты ж не будешь критиковать, что в asm'е нет работы со строками.

А вот С++ уже почти другой язык. Хоть на 99% совместим с С.

а вот такой развитой системы плагинов в линуксах нет ни у кого.

emacs

если часто занимаешься подобным говном - проще иметь флешку с портабл версиями нужного софта

В альфе даже редактора не было, если не запамятовал.

а он и не нужен, там отлично вешаются внешние утилиты

Товарищ комманд ком на пенсии давно.

Файл менеджер - костыль для неосиливших стандартные средства системы (там не нужно что-то «объединять» - это уже система, а «объединяет» он только для тех, у кого нет представления о как раз стандартных средствах). Что в винде, что в линуксе.

да знаю vi/emacs и всё такое, но частенько mcedit проще и тупо быстрее.

emacsclient быстрее

Единственный реалистичный способ его портировать

Не единственный, если ты умеешь в кроссплатформенное программирование. Однако, ценность такого переноса по отношению к затратам - зело сомнительна :)

не быстрее, там где его нет :)

это не C

это не C

Я где-то писал обратное?

Даже на мощных современных машинах между нажатием F4 и открытием файла в vim проходит весьма заметное раздражающее время.

emacsclient

ты написал этот код в ответ на вопрос

Что такое можно в сях и нельзя в паскале ?

И никто кроме тебя мне не указал на разницу. Люди очень часто ровняют C и C++ под одну планку.

а шо, паскакаль foreach так и не научили?

бить веником

Я тут не причем - ключа z нет.

Я вообще решении mc выбрать tar.

Сильно сомневаюсь. Решение о том что в файл можно зайти явно по имени принимается.

Может быть, но логичнее проверять с помощью file. А с помощью него tar.gz это gz - я об этом.

Только хардкор, только command.com...

LinFAR - как?

С нуля написать, там делов-то. Я свой первый ФМ в школе на асме написал, консольную гуйню-визуальный аналог нетвари в 11 классе (когда ее увидел), сплошная элементарная банальщина. Еслиб преподавал, я б фм в качестве зачета задавал бы писать. Тем более на pascal'е - нет возни с указателями, жесткие типы, явные приведения, большую часть nc за вечер воспроизвести можно и, что характерно, без глюков. Язык С, имхо, вообще садо-мазохисты придумали.

У тебя остались исходники? Можешь показать? Меня интересует интерфейс - нарисовать две панельки и сделать навигацию по директориям. Затем - ресайзинг панелек влево, вправо, чтобы посмотреть длинные имена файлов в одной из них (в ущерб другой). Посмотреть размер директории по F3. MC-MP это умел. Не знаю, умел ли он ресайзинг вверх, вниз - одна из фишек, которая обсуждалась в этой теме.

Также интересует полноценный shell по Ctrl-O, причем так, чтобы фокус (текущая директория) менялся синхронно с панельками и наоборот.

Кто знает, как в FAR'e реализовать принцип подключения модулей?

И последнее - я пока не представляют, с какой стороны вообще подойти к LinFAR? Это будет надстройка над Bash (чтобы был полноценный синхронный shell) или как?

MC MP

MC-MP для тех, кто не в курсе - http://mc.linuxinside.com/cgi-bin/dir.cgi

Давно не развивается, но идея была хорошая. UTF-8 Олег так и не сделал.

Кто знает, как в FAR'e реализовать принцип подключения модулей?

Хотел спросить - Кто знает, как в FAR'e РЕАЛИЗОВАН принцип подключения модулей?

Не единственный, если ты умеешь в кроссплатформенное программирование. Однако, ценность такого переноса по отношению к затратам - зело сомнительна :)

Это значит переписать FAR и переписать все его плагины, без которых он поклонникам не нужен. Это нереально.

как в FAR'e РЕАЛИЗОВАН принцип подключения модулей?

DLL. Можно посмотреть в его документации для разработчиков, если мало — в SDK и исходниках.

Ну да, такое вполне может быть.

Это было >20 лет назад. Двухпанельник на асме под АГАТ писал. Консольную гуйню на BC++ под дос. Панельки нарисовать ? :) Ты с программированием совсем что-ли никак ?

есть, я язык уже не помню - 15 лет не садился.

Наверное loadlibrary по findfirst/findnext из указанного каталога. Точно надо в исходники смотреть.
Ты вопросы какие-то странные задаешь.

Ты с программированием совсем что-ли никак ?

Сам панели никогда не рисовал, никогда не нужно было. Поэтому интересуюсь - неужели это так трудно сделать их ресайзинг, как в FAR'e ?