Jakie są wady elastycznych stoperów? [Zamknięte]


83

Spójrz tutaj: typowa święta wojna na kartach kontra spacje .

Teraz spójrz tutaj: elastyczne tabstopsy . Wszystkie problemy rozwiązane i dodano kilka bardzo przydatnych nowych zachowań.

elastyczne tabstopsy

Czy elastyczne tabstopy są nawet wspomniane w dyskusji o kartach i spacjach? Dlaczego nie? Czy wady elastycznego pomysłu tabstop są tak poważne, że nikt nigdy nie wdrożył ich w popularnym edytorze?

EDYCJA : Przepraszam za zbyt duży nacisk na „dlaczego nie są wymienione”. Nie tak naprawdę zamierzałem; to pytanie jest prawdopodobnie nawet nie na temat. Chodzi mi o to, jakie są największe wady tego rozwiązania, które uniemożliwiają szersze przyjęcie ewidentnie korzystnego pomysłu? (w idealnym świecie, w którym wszystko już to obsługuje)

(Okazuje się, że na Microsoft Connect jest już prośba o implementację elastycznych tabstopsów w Visual Studio , a także w Eclipse . Ponadto pojawia się pytanie o inne edytory, które implementują elastyczne tabstopsy )


4
To byłoby świetne pytanie dla ux.stackexchange.com
JonnyBoats

11
Nigdy nie wspomniano o nich w dyskusji „tabulatory i spacje”, ponieważ pracujący programista prawie nie ma możliwości korzystania z tych rzeczy. Może jeśli masz implementację Eclipse, VS, gvim i emacs, może się to zmienić.
Paul Tomblin

2
Naprawdę podoba mi się ten pomysł, ale tylko wtedy, gdy mieszkasz z nim przez około miesiąc, naprawdę wiesz, jakie są pułapki. Jak zawsze, są pewne przypadki, w których robi się rzeczy, których nie można się spodziewać ...
Chris Burt-Brown

3
@ ChrisBurt-Brown To zawsze ryzyko, tak. IntelliSense ma również swoje pułapki, takie jak zastępowanie tekstu, gdy go nie chcesz. Ogólnie jednak IntelliSense w C # to duża wygrana.
Roman Starkov

4
Chcę tego w notatniku ++ ... Chcę tego teraz
Ben Brocka

Odpowiedzi:


32

Święte wojny są subiektywne

Elastyczne tabulatory Nicka to niesamowita koncepcja, która mogłaby pomóc wielu ludziom zgodzić się na realne rozwiązanie, choć bardzo wątpię, aby całkowicie zakończył tę Świętą Wojnę: w końcu jest to również kwestia gustu i wielu programistów nie poruszy cale od ich stanowiska w tej sprawie, nawet kosztem kompromisu. To byłby pierwszy powód.

Na przykład wiele osób po stronie „spacji” nadal go nie polubi, ponieważ wymaga to dodatkowej logiki w oprogramowaniu do przyzwoitego renderowania (np. Po prostu przeglądanie zestawu zmian w widoku sieci SCM).

Problemy z implementacją

Ale najbardziej oczywistym powodem jest tylko techniczna bariera wejścia : jest to całkowicie inna koncepcja niż ta, która była wdrażana przez wiele lat (jeśli nie dekady) w IDE i edytorach tekstowych. Wymagałoby to przepisania niektórych z nich, aby przetwarzać linie w zupełnie innym stylu, co utrudnia starszym i większym systemom, które mają większe szanse na głębokie i ścisłe sprzężenie w kodzie przetwarzania linii. Jest jednak o wiele łatwiej zrobić, gdy zaczynasz od zera (myśleć demo Nicka lub Go „s tabwriter pakietu).

Dla osobistej anegdoty pamiętam, jak kiedyś zwracałem się do autora z pytaniem, czy w zasięgu wzroku było wsparcie emacsa, aw tym konkretnym przypadku wspomniał o tym jako o przyczynie braku trywialności. Poprosił także o pomoc ze strony społeczności, aby pomóc we wdrożeniu tej funkcji i udostępnieniu jej masom.

Czy nam zależy?

Trzeci powód jest taki, że niektórzy programiści nie są zbytnio rozwieszeni w tej sprawie i tak naprawdę nie dbają o to, aby dołożyli wszelkich starań, aby wesprzeć ten wysiłek. W większości przypadków konflikt między spacjami a tabulatorami nie jest blokerem biznesowym, więc za tym problemem nie kryje się tak duży dysk.

Jeśli chcesz, będziesz musiał o to walczyć. Co jest możliwe w oprogramowaniu typu open source. A jeśli zmienisz wystarczająco dużo z nich, te o zamkniętym źródle będą musiały ponieść ryzyko utraty części swoich baz użytkowników, jeśli nawet tak niewielka ich część.

Więc jeśli chcesz, pomóż Nickowi.


(poza tematem) Często zastanawiam się, w jaki sposób inne „to miłe, ale bardzo niewielkie” funkcje kiedykolwiek przekształciły się w produkty takie jak Visual Studio. Wygląda na to, że ktoś z zespołu po prostu znalazł czas na wdrożenie go z powodów osobistych. Pomyśl na przykład o wpisywaniu kilku wierszy jednocześnie w Visual Studio; to nie jest tak, że prosili o to dziesiątki tysięcy ludzi, ale raczej to lubię.
Roman Starkov

3
@romkyns: Jeśli chodzi o wiele rzeczy, wystarczy jeden cichy informator lub tysiąc głosów krzyczących u bram.
haylem

35

Wiele razy musiałem walczyć z edytorem tekstu, aby dokument wyglądał tak, jak chcę, bez jakiejś ukrytej automatycznej reguły kontrolującej rozmieszczenie moich słów. Nie chcę spędzać ani sekundy próbując dowiedzieć się, dlaczego redaktor nalega na umieszczenie tam tych słów.


11
Ja też nie. Całkowicie sympatyzuję z tym sentymentem, ponieważ takie zasady naprawdę mnie frustrują. Ale jest inaczej na dwa sposoby. Po pierwsze: Tak jak teraz tabstopsy, nie musisz ich używać, jeśli nie chcesz. Możesz zostawić tekst kolegom w spokoju, jeśli z nich korzysta. Po drugie: elastyczne tabstopsy nie mają ukrytych reguł, ale rażąco oczywiste. Zachowanie jest całkowicie naturalne - być może nawet bardziej naturalne niż tradycyjne tabulatory, które występują w dowolnej arbitralnej, zwykle nieistotnej pozycji w tekście. Dlatego nikt już nie używa tabstopsów do niczego innego niż wcięcia.
Timwi

10
@ Timim: Pytanie dotyczyło wykazania wad. Zrobiłem.
mhoran_psprep

14
To może nie być oczywiste z GIF-a, ale jedynym wymyślonym zagadnieniem jest to, że po naciśnięciu „TAB”, wszystko, co nastąpi później, wyjdzie właściwie ustawione pionowo. Nie ma to jak edytor tekstu. Po prostu wypróbuj rzeczywiste interaktywne demo pod linkiem, który opublikowałem, a zobaczysz, jak naturalny jest.
Roman Starkov

3
@mhoran_psprep: W porządku, doceniam twój wkład. Chyba patrzyliśmy na różne interpretacje tego pytania. Wymieniasz wady korzystania z tej funkcji, podczas gdy myślałem, że chodzi o wady związane z wprowadzeniem tej funkcji (tj. Udostępnieniem jej i nieobowiązkowym ).
Timwi

27

Po raz pierwszy o nich słyszałem. Nie jestem pewien, czy są dobrym pomysłem, ale wydają się mało przydatne, ponieważ mamy narzędzia (takie jak wcięcie), które już automatycznie formatują kod.

Co się stanie, gdy otworzę twoje sprytne elastyczne tabulatory w vimie i dokonam edycji? Czy zakładka czyści się automatycznie, czy masz bałagan?

Główne wady, jakie widzę, to prawdopodobnie łamanie różnic, kontrola wersji i brak zgodności z edytorami, które ich nie obsługują. Może to wymagać wielu modyfikacji kodu i są ważniejsze rzeczy niż funkcja „jeszcze jedna karta do formatowania kodu”. W końcu wszyscy możemy korzystać, indentco robi wszystkie powyższe, jeśli pamięć służy.


9
Co za myślenie wstecz. Nie osiągajmy żadnych postępów, ponieważ ulubione, stare, przestarzałe narzędzia nie są jeszcze w stanie sobie poradzić ! (Ironia polega oczywiście na tym, że te narzędzia (takie jak vim) są oprogramowaniem typu open source, więc jeśli byłoby to dla ciebie naprawdę ważne, możesz (i prawdopodobnie powinien ) dodać do tego elastyczne wsparcie tabstop)
Timwi

14
@Timwi: Całkowicie brakuje ci punktu, o którym mówiłem. Co się dzieje, gdy plik kodu jest analizowany przez coś, co nie jest świadome elastycznych tabstopsów? Czy skończysz z bałaganem, czy dadzą sobie radę? Co z kontrolą wersji i różnicami? Żałowanie, że wszystkie narzędzia nie obsługują funkcji $, jest nierealne, nawet jeśli narzędzia te są typu open source.
Sardathrion

14
@Timwi: Zakładasz, że wszyscy uważają elastyczne tabstopsy za tak niesamowite, jak ci się wydaje. To może nie być prawda.
Sardathrion

7
@Sardathrion ma rację. Co się stanie, gdy będę musiał zdalnie podłączyć się do mojego serwera * nix bez zainstalowanego systemu okien i muszę sprawdzić kod za pomocą Vima / Emacsa / Pico / Cokolwiek? Jeśli istnieje mechanizm umożliwiający jego odczytanie, byłoby dobrze ... w przeciwnym razie byłby to koszmar. Zresztą nie widzę korzyści, by elastyczna zakładka przestała być tak korzystna. Mogę już automatycznie sformatować mój kod, aby wyglądał jak powinien w IDE, których używam.
Przypon

7
Punkt kontroli wersji jest dobry - nie sądzę, że ludzie docenią edytor, który po cichu zaczyna zmieniać umieszczanie / format komentarzy w kodzie arbitralnie daleko od modyfikowanego kodu (zobacz sekcję magenta w animowanym OP gif). Przydałoby się mieć referencyjną implementację do zabawy, ale to, co do tej pory widzę, nie jest niezwykłe - emacs już robi wiele z tego, tylko z kilkoma dodatkowymi naciśnięciami klawiszy (co prawdopodobnie jest dobrą rzeczą).
mcmcc

13

Szczerze mówiąc, nie uważam ich za użyteczne po przejściu początkowego podniecenia. Na przykład i tak nie lubię komentarzy na końcu wiersza - zawsze umieszczam komentarze w osobnym wierszu. Dzięki temu elastyczne zakładki tracą swoje główne zastosowanie.

Następnie możesz oczywiście nadal używać ich do wyrównywania argumentów funkcji (i parametrów) i długich list przypisań.

Ale w przypadku tego pierwszego zwykle wciskam wszystkie argumenty o jeden dodatkowy poziom i to działa ze mną całkiem dobrze:

void foo(
    int x,
    int y,
    string z
)

I nie widzę żadnej potrzeby, by to zmienić.

A jeśli chodzi o wyrównanie zadań, nie robię tego. Umieszczam pojedyncze spacje wokół zadań, to wszystko. Staram się również nie grupować wielu zadań razem, więc rzadko występuje problem z czytelnością.

Podsumowując, elastyczne zakładki są dla mnie absolutnie zerowe . Jest to oczywiście bardzo osobiste preferencje, które mogą się różnić, ale uważam, że działa dobrze i wydaje mi się, że brak wsparcia dla elastycznych zakładek jest spowodowany tym, że inni ludzie myślą podobnie.

Jeśli edytor je zaimplementuje, nadal ich nie użyję.


Doceniany. Wygląda na to, że z chęcią mógłbyś również użyć czcionki o zmiennej szerokości, jeśli tylko chcesz, ponieważ i tak nie wyrównujesz niczego poza początkiem linii. Program Visual Studio ma całkiem dobrą obsługę tego, a poprawa czytelności jest dobra.
Roman Starkov

1
@romkyns Mieliśmy dyskusję o tym, jak iw trakcie jednego próbowałem przy użyciu czcionki proporcjonalnej do programowania przez jakiś czas. Rezultatem było to, że czcionki o stałej szerokości działają lepiej, nawet przy pominięciu wcięcia. Poza tym pracuję obecnie wyłącznie w Vimie i konsoli, z których żadna z nich najprawdopodobniej nie będzie obsługiwać czcionek proporcjonalnych.
Konrad Rudolph

1
@romkyns To powiedziawszy, problemy te można rozwiązać (a może nawet rozwiązać, stosując czcionkę proporcjonalną zaprojektowaną do programowania). Ale nadal nie widzę potrzeby.
Konrad Rudolph

13

Jedną wadą jest to, że nie działa, jeśli chcesz wyrównać na jednej grupie linii, a następnie wcięcia na następnej, ponieważ grupuje tabulatory sąsiednich linii.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

Czego chciałem:

def foo( bar,
         xyzzy ):
    wibble()

W przypadku języków nawiasów klamrowych może to być mniejszy problem, ponieważ zwykle można to rozwiązać, umieszczając nawias otwierający w osobnej linii (jak w animacji), ale w przypadku języków wrażliwych na spacje szybko staje się to problemem, i ostatecznie musisz wrócić do korzystania ze spacji.


Zgoda. Implementacja Nicka nie działa w ogóle dla języków takich jak Python.
Roman Starkov

3
Dlaczego to nie zadziała? To nie jest podstawowe ograniczenie, algorytm musi być tylko świadomy języka. Ale do pewnego stopnia jest to prawdą nawet dzisiaj, na przykład Vim określa różne reguły wcięć w zależności od języka. Może to z łatwością pomieścić wcięcia w języku Python.
Konrad Rudolph

1
@KonradRudolph Nie, nie mogli. Rysowanie elastycznych tabulatorów to możliwość automatycznego wcięcia / cofnięcia grup tekstu razem. Jednym prostym przykładem jest koniec instrukcji „jeśli”: Próbujesz cofnąć wcięcie, ponieważ wychodzisz z instrukcji, ale „inteligentne” elastyczne tabstopsy decydują, że chcesz również cofnąć wcięcie linii lub dwóch powyżej, itd. i tak dalej ... A jeśli musisz jawnie pogrupować tekst razem, to - o co chodzi? To więcej pracy, niż samodzielne naprawianie wcięć ...
Izkata,

1
@ Izkata Unindenting ręcznie po prostu (powinien) po prostu zakończyć bieżącą grupę. Dlaczego miałbyś kiedykolwiek kontrolować wcięcia za pomocą elastycznych ograniczników zakładki? Nie zrobiłbyś tego, więc algorytm wie, że kiedy to zrobisz, ma to zakończyć blok, a nie cofać wcięcia powyższego bloku.
Konrad Rudolph

1
Dobra racja. Hmm ... może mógłbyś podwoić argumenty? Zatem wibble()miałby tylko jedno wcięcie i dlatego nie byłby dopasowany do argumentów funkcji?
Ajedi32

12

Dlaczego po prostu nie wykorzystujemy znaku tabulacji pionowej (VT, ASCII 11) do wskazania zastosowania elastycznych tabstopsów? Nie służy żadnemu celowi w żadnym głównym języku programowania, ale jest analizowany jako ważna biała spacja we wszystkich AFAIK.

Oznaczałoby to, że stosowanie elastycznych tabstopsów nie jest już konwencją zewnętrzną (np. „Ten plik został sformatowany za pomocą elastycznych tabstopsów, włącz je”), ale coś, na co zdecydujesz się indywidualnie.

Istniejące edytory tekstu zwykle wyświetlają glif lub pojedynczą spację zamiast pionowej tabulacji. To nie jest idealne, ale niewielka cena do zapłaty, IMO.


10

Nie są wspomniane, ponieważ nie są zaimplementowane w większości IDE edytorów tekstowych; są nowością mało użyteczną w projekcie.

Od czasów kart dziurkowania używane są spacje do układania programów. Pojawiły się tabs i ktoś najwyraźniej pomyślał, że to dobry pomysł (byli w błędzie: p).

W czasach, w których większość współczesnych edytorów może automatycznie konwertować tabulatory na spacje ... są dość bezcelowe.

Konieczność zainstalowania kolejnego narzędzia do radzenia sobie z czymś tak trywialnym, jak tabulacje i spacje, z pewnością nie podoba mi się i nie sądzę, by podobało się to większości moich kolegów.


Wyczyściłem komentarze, gdy stały się one obelgą.
ChrisF

1
Pomyślałem, że zwrócę uwagę, głównym powodem, dla którego podoba mi się pomysł elastycznych tabulatorów, nie jest to, że rozwiązuje ono problem tabulacji w porównaniu ze spacjami, ale z powodu zachowania pokazanego w pliku GIF w pierwotnym pytaniu; automatyczne, bezbolesne wyrównanie. Dodatkowo dla różnic VCS istnieje dodatkowa korzyść polegająca na tym, że w tym przykładzie nie były wymagane zmiany białych znaków.
Ajedi32

„Konieczność zainstalowania kolejnego narzędzia ...” nie jest wystarczającym argumentem… Jakby nie było już wystarczającej liczby używanych narzędzi.
Milind R

@MilindR Niezależnie od tego, czy uważasz to za wystarczająco dobry argument, czy nie, to jest powód, dla którego (w tamtym czasie trzy lata temu) nie byłbym tym zainteresowany. Używanie wielu narzędzi, które robią coś pożytecznego, nie jest powodem do dodawania kolejnego, który tak naprawdę nie dodaje niczego do twojego środowiska.
TZHX

Takie postawy są powodem, dla którego firmy takie jak MS decydują się zmusić użytkowników do nowych UX ... wzdrygam się na myśl, co by się stało, gdyby to samo podejście zastosowano do dyskietek -> przejście na CD.
Milind R

4

Myślę, że przydałyby się, gdyby IDE je wspierały (Microsoft!). Gdy ludzie odkryją, że mogą uderzyć skrzynkami kwiatowymi z boku i mieć je dobrze czytelne, zrobią to. Możesz nagle dodać więcej komentarzy do kodu źródłowego (co może być tylko dobrą rzeczą).

Przypuszczam, że moglibyśmy również dodać „podpowiedzi” do listy „czy dobrze by było, gdyby ...”, aby duże bloki komentarzy można było ukryć i łatwo przeglądać w razie potrzeby. Być może moglibyśmy mieć również bloki komentarzy, które stanowią część dokumentacji (nie rzeczy typu sandcastle, odpowiednie fragmenty dokumentacji czytelne dla użytkownika, które zostały osadzone w kodzie, a nie tylko nagłówki metod)

Wady: może sprawić, że różnice w źródłach będą wyglądać źle, jeśli wiązka linii wyglądałaby tak, jakby zostały zmienione, gdy tak naprawdę zmodyfikowano tylko 1 (jeśli edytor zapisał plik z tabulatorami przekonwertowanymi na spacje). Lub, jeśli elastyczna karta została zaimplementowana z pojedynczym znakiem (lub bardziej prawdopodobne, z 2 tabulatorami), wówczas wyświetlanie źródła poza edytorem może wyglądać źle.

Myślę jednak, że podoba mi się ten pomysł, „tabulator” na końcu linii uelastycznia blok komentarza i odpowiednio ustawia wszystkie komentarze w kolejnych wierszach (które mają odstępy podwójnych tabulatorów).


3

Oto, jak to widzę: jeśli większość popularnych narzędzi obsługuje już elastyczne tabstopy, wiele osób będzie ich używać. To samo stało się z trybem nawigacji / edycji vi, z podświetlaniem składni, a później z Intellisense. W każdym przypadku ustalona mądrość była taka, że ​​nie jest użyteczna lub niepotrzebna, ale została wdrożona i wystartowała.

Elastyczne tabstopy mają oczywiście stosunkowo niewielki wpływ. Większość ludzi jest wystarczająco zadowolona ze status quo i dlatego ich to nie obchodzi. Podobne rozumowanie stosuje się w wielu sytuacjach, w których niektórzy ludzie są po prostu zadowoleni z tego, co mają i nie widzą powodu, aby przejść na coś bardziej zaawansowanego. Innymi słowy, największy problem z elastycznymi zaczepami jest taki sam, jak w przypadku każdego innego dobrego pomysłu: musi uzyskać przyczepność.

Ale to nie znaczy, że tej funkcji nie można stopniowo wprowadzać. Każdy język programowania był przyjmowany stopniowo, mimo że cały zespół wymaga nowego kompilatora i nowego środowiska IDE, aby móc z niego korzystać. To samo dotyczy każdej architektury sprzętowej i wielu innych przykładów. Nie jest też tak, że brak integracji z istniejącymi narzędziami jest przeszkodą: to samo dotyczy na przykład „formatu zunifikowanego-różnicowego”, który stopniowo zastępował wcześniej mniej czytelny format, który mimo to był rozumiany przez zautomatyzowane narzędzia (np. łatka). Narzędzia te zostały z czasem zaktualizowane.

Doceniam problemy, o których wspominali inni, ale mimo to na pewno będą zespoły (takie jak moje), które przyjmą to bez wahania, w całości. Narzędzia zewnętrzne, takie jak różnicowanie, scalanie itp. Początkowo nie będą go obsługiwać, ale zrobilibyśmy wszystko, aby zachęcić dostawców do włączenia tej funkcji. Tak zawsze robiono postępy. Wymaga to bólu przez przejściowy okres przejściowy, ale ostatecznie warto.


Argument C vs C ++ wydaje się nieco mylący. Chociaż może tak być w przypadku „niektórych osób” (jak słusznie powiedziałeś), istnieją oczywiste powody, aby trzymać się C lub faworyzować C ++ w zależności od sytuacji. Rozmiar środowiska wykonawczego C ++ jest jednym z nich, domyślnie.
haylem

Jestem z wariatem. Twój punkt byłby bardziej dźwiękowy bez porównania C-versus-C ++. Są to zupełnie inne języki. Moim zdaniem C służy do programowania systemów i innych prac niskiego poziomu, w których potrzebujesz dużej kontroli (na przykład maszyny wirtualnej). C ++ jest bardziej odpowiedni dla aplikacji na średnim poziomie, w których abstrakcja jest przydatna do zarządzania złożonością (przestrzenie nazw, kontenery i algorytmy STL, szablony), ale wydajność nadal stanowi problem (gry są najbardziej widocznym przykładem).
Jon Purdy

@haylem: Dzięki za opinie. Usunąłem odniesienie do C / C ++.
Timwi

@JonPurdy: Dzięki za opinie. Usunąłem odniesienie do C / C ++.
Timwi

2

Największym problemem, jaki bym z tym spotkał, jest niespójne odstępy w dokumentacji. Wiem, że jako programista denerwowałbym się, widząc pętlę lub stwierdzenie „przy standardowym” wcięciu, a następnie zauważając przy różnych wcięciach. Wiem, że osobiście lubię widzieć wszystkie moje nawiasy klamrowe ułożone w dokumentacji, nie tylko w bloku kodu, na który patrzę.

Ogólnie uważam, że to dobry pomysł, ale osobiście nie podobałoby mi się.


1

Właśnie wypróbowałem implementację elastycznych tabstopsów w jEdit, która działa niesamowicie dobrze z językami programowania, w których jestem zaznajomiony (głównie HTML / XML i języki podobne do C). Jednak w przypadku kodu Python oto sposób, w jaki jest renderowany (spacje używane zamiast tabulatorów do zilustrowania, jak rzeczy się wyrównują):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

W przypadku języka takiego jak Python, który opiera się na odstępach, jest to przełom, chyba że wyłączysz funkcjonalność zapewnianą przez elastyczne tabstopsy. Edytory takie jak Vim i Emacs sprawiają, że wyłączanie większości funkcji jest proste, jeśli znasz nazwę opcji i sposób jej wyłączenia, ale w przypadku kodu podobnego do powyższego funkcja ta byłaby wymagana.

To powiedziawszy, jest świetny dla x86 ASM, C, C ++, Go, XML, HTML i innych, które nie polegają na białych znakach:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Powiem, że dialekty Lisp, takie jak Scheme, mają własne konwencje, które sprawiłyby, że elastyczne tabstopsy renderowałyby „brzydki” kod. Jeśli zmienię ustawienia tabstop, aby pasowały do ​​konwencji 2 kolumn i wstawię tabstops w nietypowych miejscach (między funkcją a jej argumentami):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

vs. bardziej czytelny:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

To prawda, że ​​ten nie jest tak zły, jak przykład w Pythonie, ale zdecydowanie zmniejsza czytelność kodu. Chociaż bardzo podoba mi się funkcjonalność podczas kodowania w języku C # lub C ++, nie znoszę tej funkcji podczas pisania w języku takim jak Python lub Scheme, w którym białe znaki są funkcjonalne i / lub pomocne wizualnie. Elastyczne tabstopsy zostały stworzone specjalnie po to, aby były pomocne bez potrzeby oddzielnego narzędzia wcięcia, ale najwyraźniej nie jest to przeznaczone dla wszystkich języków programowania.


0

Emacs już obsługuje wcięcia w obecności zamkniętych nawiasów i automatycznie dopasuje wilma do fred . Nie mam pojęcia, dlaczego Eclipse nie robi tego samego. Ok, mam pomysł, ale to nie jest komplementarne.

Możesz sprawić, by Emacs również dopasował komentarz, bez większych problemów, ale AFAIK nikt oprócz ciebie tego nie chciał.


2
Mogę tylko zinterpretować twoje ostatnie zdanie jako trolling, ponieważ oczywiście co najmniej jeden inny facet chciał go dość cholernie na tyle, aby stworzyć dobrze uzasadnioną stronę, implementację Java i GIF, aby pokazać, dlaczego jest dobry. Jeśli przeczytasz odpowiedzi, przekonasz się, że Nick też nie jest sam. Och, czekaj, spójrz tutaj .
Roman Starkov

Nawiasem mówiąc, czy Emacs ponownie wcina się wilmapodczas wprowadzania zmian, takich jak zmiana długości nazwy funkcji? Jeśli tak, to dość blisko tego, co robią elastyczne tabstopsy.
Roman Starkov

@romkyns: Nie chciałem być trollingiem, po prostu miałem na myśli, że nigdy nie widziałem stylu wcięcia komentarzy w EMACS. Zasadniczo EMACS nie wcina wielu wierszy podczas pisania, ale można to również zmienić.
kevin cline
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.