logs archiveIRC Archive / Freenode / #emacs / 2010 / May / 7 / 1
quotemstr
A buffer can only be indirect for one other buffer.
rryouumaa
in a given buffer, you can only have 1 indirect buffer
quotemstr
I'm imagining some special value of the 'display' text property that instead of referring to an image, refers to another buffer.
madpickle
am i nuts or did google change their search page design?
quotemstr
madpickle: I've already changed it back with Stylish.
dim
you want visually 1 buffer, but more than one inside?
cvandusen
madpickle: we're both nuts. I just saw that
dim
I say windows are there for that :)
FunctorSalad
heh thought it was due to my new browser settings madpickle
         

madpickle
(Action) will have to rig some stylesheet stuff in Proximitron
dim
can you have 3 indirects buffers all pointing to the same "base" buffer?
rryouumaa
yes
FunctorSalad
*resets zoom* right, still looks new madpickle
dim
so let's use windows and as much indirect buffers as necessary and improve the navigation
madpickle
(Action) thinks overlays could be made to work (or a concept building on overlays)
FunctorSalad
madpickle: the font size on the left bar seems way ensmallened compared to the results list
madpickle
FunctorSalad: yes. terrible use of my screen real estate.
then again, i mostly zoom in using Opera
FunctorSalad
huh? doesn't it *save* space
madpickle
on 1920x1200 i have about half of that wasted on white space
i was talking about something else
=)
FunctorSalad
since you need to read the labels on the left bar only once, but the search results are different each time
rryouumaa
dim: pass-through org agenda buffers would be far simpler. you could edit headlines in place. no need for separate agenda commands for many operations.
quotemstr
dim: Your approach is possible with the current Emacs core, but it's ultimately has less utility since it doesn't allow seamless editing.
dim
rryouumaa: oh sorry, I was still thinking php/html/js/css in one file
rryouumaa
imagine multi-occur where you can edit lines in place without having to sync.
madpickle
rryouumaa: nods.. i'd love that
quotemstr
(Action) wonders how much work it would be to implement the display property he imagines.
dim
quotemstr: not sure, if next-line gets you to the right window...
quotemstr
This display engine is an eldritch horror, I hear.
FunctorSalad
madpickle: I don't mind the whitespace on google; you're limited by your mental parsing speed anyway (unlike multiwindow programs, where estate is crucial indeed)
         

madpickle
quotemstr: apparently it was "refactored about 10 years ago"
quotemstr
You'd still need chunk recognition; the overall major-mode would have to support that.
technomancy
quotemstr: guile will fix all that
ggole
Wow, dtrace does look cool
technomancy
(not really)
dim
ggole: it's called systemtap under linux
madpickle
so indirect buffers: can i have one 'indirect' buffer contain text from multiple buffers now then?
quotemstr
Whenever you made a change, the overall major-mode would have to re-establish chunk boundaries.
madpickle: No; that's the fundamental missing feature.
rryouumaa
madpickle: that is the new feature under discussion
madpickle
ah yes.
that'd be lovely.
dim
it's the other way round currently
hence the windows + navigation idea
chunck recognition based on heuristics shouldn't be that bad?
FunctorSalad
indirect buffers? learn something new all the time
dim
I mean we know headers and footers of PHP, HTML sections, js and css, don't we
how easy it is to mix them?
ok it shows up that I'm not editing that stuff anymore
(emacs) Indirect Buffers
FunctorSalad
sounds like it might be something for my backquote mess ;) edit backquotes bodies in a restricted buffer? ;)
quotemstr
dim: You might be able to make it somewhat transparent; imagine you have a single buffer containing the usual HTML/JS/CSS/etc. mix. In order to *edit* a section, you'd move point there and press, say, C-c C-c. You'd be taken to another buffer containing just that chunk, and when you're done editing that, you could hit C-c C-c to return to the overall buffer.
madpickle
threads + better indirect + PCRE = happy pickle.
quotemstr
dim: Text properties could be copied on a switch so that the overall buffer is fontified properly.
madpickle
quotemstr: org mode does something like that with #+BEGIN_SRC #+END_SRC.
FunctorSalad
though I think color overlays would be the right thing for backquote/unquote alternations
dim
quotemstr: well in my mind I don't see the overall buffer at all
FunctorSalad
every region of code should have bg colored according to quotation depth
quotemstr
dim: The overall buffer is essential for a lot of people; you have to admit that.
dim
I see chunks in separate windows, each chunk is well colored
FunctorSalad
I wonder why it hasn't been done, seems to useful
jordanb_
I figured out why rudybot is so slow.
He doubles as a wall-street trading program.
dim
quotemstr: you only lose 1 vertical line. come on.
madpickle
dim: problem with that are all the little <% wefwef %> chunks that're inlined in html or what have you.
quotemstr
FunctorSalad: I had a Lisp-mode that maintained an AST in-memory, and did not only that, but also fontified LET-variables correctly and so on.
FunctorSalad: I was stupid and lost all the code I'd written.
dim
it'd be so much better than the current state of affairs
FunctorSalad
quotemstr: cool, but isn't that the strength of lisp? we have the AST trivially parseable from the buffer contents
dim
quotemstr: write it again in a snap :)
FunctorSalad
quotemstr: thought that backquoting level thing could be done using just {forward,backward}-sexp and friend
*friends
quotemstr
FunctorSalad: It's a non-trivial amount of work to establish what change to the AST results from a given buffer modification.
You could just re-read the whole thing on every change, of course.
FunctorSalad
quotemstr: ok right, wasn't thinking about changes yet
madpickle
quotemstr: yep. and it's all done in the main thread too
quotemstr
but on simple.el, say, that'd be a nightmare.
(I love that filename.)
cvandusen
quotemstr: isn't that what js mode does?
rryouumaa
(Action) is forced to give up on the very promising mac port as it doesn't patch cleanly
FunctorSalad
once an intermediate buffer contents isn't a lisp program anymore, we're back to parsing text of course :(
quotemstr
cvandusen: js-mode saves its state every so often in a text property; after a change, it wipes out the state in the part of the buffer after the last known-good point before the change and recalculates from there.
ggole
quotemstr: you can sort of attack that with hacks like considering (defun to be the beginning of a line to start a top-level form
cvandusen
quotemstr: I'm thinking of js2-mode. Yegge's
quotemstr
cvandusen: Sure, if you edit at BOP, all the saved state is wiped out. But you don't need to calculate state for the end of the buffer yet because you're not displaying it, so the impact tends to be small.
cvandusen: Ah.
FunctorSalad
(I wonder if it would be viable to make a usable mode where you can't write syntactically illegal intermediates...)
ggole
s/to be/at/
quotemstr
cvandusen: Yeah, js2 does something far heavier .
s/BOP/BOB/
FunctorSalad
(your editing commands would be list operations, not string operations)
ggole
FunctorSalad: people have written structural editors like that
quotemstr
FunctorSalad: See paredit.
FunctorSalad: It works rather well for Lisp. Some crazy people use it for C somehow.
ggole
They haven't taken off, and I don't think they will
FunctorSalad
quotemstr: paredit does that?
cvandusen
He seems to have gotten a lot of criticism for that (or something else), but I would think that'd be the way to go (generally speaking)
quotemstr
ggole: paredit is fairly popular.
FunctorSalad
(actually protect the syntax, not just offer you new commands)
quotemstr
cvandusen: No; grammar-based fontification is a very promising dead end, sort of like buying a pretty girl drinks at a bar.
FunctorSalad
ggole: *nod* whether you'd want to use it is another matter
ggole
It's convenient having illegal syntax in the buffer
FunctorSalad
ggole: maybe text-editing is just a habit though, not fundamentally easier
quotemstr
cvandusen: It's too inflexible to account for changes to the language or grammar-violating intermediate states resulting from editing.
cvandusen: It's also very slow.
ggole
You can use mental shortcuts like typing ... where you mean to come back later and add some stuff
quotemstr
FunctorSalad: *Try* paredit. You'll like it.
madpickle
speed nowadays would be a non-issue if it could be run in a separate thread
quotemstr
madpickle: You'll take my synchronous fontification from my dead hands.
FunctorSalad
quotemstr: ok, guess I'll have to invent lots of keybindings with viper though :(
quotemstr
madpickle: I do *not* want to type something, then see it fontified a few seconds later.
madpickle
quotemstr: i wasn't advocating that so much as I was suggesting we could have both: fontify the barebones stuff with the standard approach then overlay things extracted from an AST
FunctorSalad
ggole: surely one needs illegal intermediates, but maybe not syntactically illegal ones
DraX
i would like to see that
quotemstr
FunctorSalad: Try to create a structural editor for C. I dare you.
madpickle
quotemstr: i don't mind if errors/warnings are highlighted a few secs after.
DraX
some of the stuff that js2-mode does i find irreplaceable
FunctorSalad
(you could have "holes" for stuff that isn't defined yet, like some modes do)
madpickle
you can ghetto a lot of that with flymake-mode, of course.
DraX
errors/warnings, whether a variable is declared or not
quotemstr
FunctorSalad: Languages with simple grammars are feasible for structural editing, but very few modern languages qualify.
cvandusen
quotemstr: I never had problems with the speed (although I never used it with huge files). Seems like the intermediate states could be handled with some timer of some sort.
madpickle
tie it in with python and pylint or what have you
ggole
And really, structural editing simply doesn't solve an important enough problem
FunctorSalad
quotemstr: I heard the syntax of C depends on the semantics in some corner cases, never looked at C syntax in detail. but in most modern languages parsing is fairly close to context-free, I thought
ggole
Editing text isn't very hard. Compared to the difficulty of comprehending and working with the semantics of code, it's just trivial.
quotemstr
FunctorSalad: Uh, Perl? Ruby? Python? Bourne Shell? C#?
technomancy
ggole: you need to give paredit a try
it's a whole new world
quotemstr
FunctorSalad: The only halfway-common language with a simple-enough syntax is Lisp.
FunctorSalad
quotemstr: depends on where "syntax" ends here
quotemstr
(And Lisp without touching the read-table.)
ggole
Meh. I have bindings to type everything in pairs anyway.
technomancy
(Action) < ( "A dazzling place I never knew; no one to tell me no, or where to go..." 𝅘𝅥𝅮 )
FunctorSalad
quotemstr: e.g., infix operator precedence declarations in haskell are a non-contextfree feature in haskell, but you could just ignore that as a first approximation
madpickle
ggole: paredit is really great; do give it a shot.
quotemstr
FunctorSalad: You can get most of what you want with yasnippet.
FunctorSalad
quotemstr: for creating stuff, yet
technomancy
it's a *lot* more than just pair insertion
FunctorSalad
not for changing sadly
technomancy
it is so awesome it makes me want to break out in song
madpickle
electric pairing is nice and all, but not really what paredit is about.
FunctorSalad
quotemstr: C#? what's the problem there?
quotemstr
FunctorSalad: Transform the code into an AST, serialize the AST to s-expressions, edit the s-expressions, and then regenerate the original code. :)
jordanb_
rudybot: quote
rudybot
I'll download you.
FunctorSalad
quotemstr: can't think of any feature where syntax depends on "deep" analysis of the code
(in C#)
madpickle
ggole: if you find M-) a good start in lisp modes then paredit will make your life better.
quotemstr
FunctorSalad: Try creating a structure definition in C without there being invalid intermediate states. You'd need lots of commands for bracketed insertions, expressions, statements, and so on.
FunctorSalad: Your keyboard would have to turn into a pipe organ console for AST nodes.
rryouumaa
(Action) tries to figure out what m-) does from the docstring
FunctorSalad
quotemstr: seems like we're talking about different things :) I meant whether analysing syntax requires "deeper" than local lexical analysis, for example if correct syntax depends on some declaration that might be at an arbitrary location in the program
madpickle
rryouumaa: tries to inline-insert into the same clause use it in things like let
FunctorSalad
quotemstr: thought C had such situations (sorry, don't remember what exactly), but that C is the exception there
quotemstr
FunctorSalad: And to some extent, that's true in C, and solved by the lexer hack. My argument is that even if you could make a reasonable parser for C-like languages, it'd be useless as a structural editor because jumping from one valid state to another valid state could happen in so many ways that you'd need an infeasible number of keybindings.
FunctorSalad
quotemstr: hmm, I don't see how you'd need keybindings for every type of AST node... just tree navigation bindings
madpickle
C-M-u / C-M-d -- there ya go! :P
FunctorSalad
the interface for editing a structure would be: interface for editing the name, list of interfaces for editing the members, and so on
fledermaus
you only require about 105 bindings for that
quotemstr
madpickle: Can you give me an example?
FunctorSalad
(a struct I mean)
fledermaus
you could prepare a hardware device holding such keys
a board of keys, if you will
madpickle
quotemstr: yes
quotemstr
madpickle: Of M-), that is. C-M-u and C-M-d are quite useful.
madpickle
quotemstr: C-M-u/d/n/p are underused and underappreciated.
anyway..
quotemstr
fledermaus: Let's not return to the days of needing cardboard keyboard overlays with commands printed on them.
FunctorSalad
quotemstr: up/down while the struct is focused would go from member decl to member decl
a "down one level" key would focus on the member you're on
I don't see the prob there
just imagine there are parens around every member decl
madpickle
something like this: (let (-!-(foo bar-!-))) -- -!- is point. the first one will take you to the BODY of let; the second -!- will take you out of the variable declaration
quotemstr
FunctorSalad: How do you insert a new declaraiton without there being an invalid intermediate state?
FunctorSalad
quotemstr: holes
(like in yasnippet)
madpickle
quotemstr: M-) is difficult to explain; it's easier if you try it out. it moves out one level, then indents and moves the associated closing ) after that.
FunctorSalad
except not just for creation
quotemstr
FunctorSalad: Feel free to create such a thing.
FunctorSalad
quotemstr: :) maybe... so far I admit that I haven't fully mentally adapted to even what emacs for sexps, yet
quotemstr
madpickle: Ah, I see. I'm just used to the paredit M-)
madpickle
quotemstr: ahh, that would explain it.
FunctorSalad
but that's just a matter of practice probably
madpickle
quotemstr: which is why i said to ggole: if you like what M-) does, you'll *love* paredit :)
FunctorSalad: using the -sexp functions?
FunctorSalad
madpickle: yeah
madpickle
FunctorSalad: you gotta learn 'em. they're great in almost any decent major mode. killing entire strings; balanced brackets; etc.
FunctorSalad
already using kill-sexp, at least ;) need to get used to the up-level and down-level commands
quotemstr
I love documentation that has passages such as: "An aggregating function is one that has the following property:
f(f(x0) U f(x1) U ... U f(xn)) = f(x0 U x1 U ... U xn)"
madpickle
FunctorSalad: yeah, they're a bit difficult to get used to because of how they work. but once you understand them moving in and out of nested brackets becomes *so* easy.
quotemstr: homomorphisms?
or is it homeomorphism
(Action) shrugs.
FunctorSalad
what I was trying to say is that most languages (not C and probably not bash ;)) allow you to parse the "invisible parentheses" (like where one member ends and the next starts) without deep understanding
quotemstr
http://docs.sun.com/app/docs/doc/817-6223/chp-aggs?l=en&a=view
"Aggregate Functions"
« prev 1 2 3 4 5 6 7 8 9 10 11 12 next »