From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: "Adobe Brackets like" editing in emacs Date: Wed, 19 Mar 2014 17:42:42 +0100 Message-ID: References: <87txaukeia.fsf@uwakimon.sk.tsukuba.ac.jp> <95BBC5A0-61E9-43CC-8B4D-563A7873EB32@gmail.com> <87zjkmi2i2.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdc1bd0caf54204f4f859bc X-Trace: ger.gmane.org 1395247401 12502 80.91.229.3 (19 Mar 2014 16:43:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 16:43:21 +0000 (UTC) Cc: Ivan Andrus , "rms@gnu.org" , arthur miller , "emacs-devel@gnu.org" To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 19 17:43:30 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WQJaT-0003TP-S8 for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2014 17:43:30 +0100 Original-Received: from localhost ([::1]:42660 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQJaT-0005OB-Al for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2014 12:43:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQJaQ-0005O5-7i for emacs-devel@gnu.org; Wed, 19 Mar 2014 12:43:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQJaP-000625-0O for emacs-devel@gnu.org; Wed, 19 Mar 2014 12:43:26 -0400 Original-Received: from mail-ie0-x22c.google.com ([2607:f8b0:4001:c03::22c]:51928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQJaN-00061k-75; Wed, 19 Mar 2014 12:43:23 -0400 Original-Received: by mail-ie0-f172.google.com with SMTP id as1so9238570iec.3 for ; Wed, 19 Mar 2014 09:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cZ56/i/mRoc06XWiF2SWizbIRz4e05/U1DSWeXxyKUI=; b=FyFb8AqiJZLKOUc5uLGuURm+52dy6bnzeD5O06yAtPyLbY4OExSWxQK1TwxI2Ycr92 u5v6uvIpzXjyWcmCydtWcF3hyMN5SJeFb0Bf7SksBKaU1K/4aoxkjb2J/skNU/+3yMLF VMI7hfnvFu/DMv207lsuR+3SK04GMovTwtKaVy96Tj0pgXueH+SYTjAT7icwTv/dAok5 y8CnZT79Y07aQjW+3UfmGVGg8/wDBhnk10IdaBfFltb7qLxKMWLbM1vAVnzDbf6UiM5/ ZIxDc5ZGq7SBxiGcF0sVSQXPTOH53U1/nw+uT4qzYJWObd6DXkFwHttxegqpSbnUyleg Eprg== X-Received: by 10.50.62.104 with SMTP id x8mr26151724igr.37.1395247402379; Wed, 19 Mar 2014 09:43:22 -0700 (PDT) Original-Received: by 10.42.229.1 with HTTP; Wed, 19 Mar 2014 09:42:42 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:170553 Archived-At: --047d7bdc1bd0caf54204f4f859bc Content-Type: text/plain; charset=UTF-8 On Wed, Mar 19, 2014 at 5:37 PM, Lennart Borgman wrote: > On Wed, Mar 19, 2014 at 5:20 PM, Stephen J. Turnbull wrote: > >> Lennart Borgman writes: >> >> > Then I think Emacs must move in the direction of much tighter >> > integration with compilers and environments. Tighter integration >> > with the environments probably means allowing Emacs to be used as a >> > plugin (in the browser in this case). >> >> I don't really see that. In the great majority of cases there's about >> one file to worry about (a CSS file accessed from a > rel=stylesheet>). >> > > With media queries, of course. They are very important today. > > So careful parsing is still required (even in the case with just one CSS > file). > But on the other hand that careful parsing could be made into an advantage. I just know a few environments for hunting CSS-rules. In those I have seen no simple way to see how the different media queries apply to the element I am looking at. Quite inconvenient actually. (I assume it is coming soon, though.) --047d7bdc1bd0caf54204f4f859bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 19, 2014 at 5:37 PM, Lennart Borgman <lennart.borgman@gmail.com> wro= te:
=
On Wed, Mar 19, 2014 at 5:20 PM,= Stephen J. Turnbull <stephe= n@xemacs.org> wrote:
Lennart Borgman writes:

=C2=A0> Then I think Emacs must move in the direction of much tighter =C2=A0> integration with compilers and environments. =C2=A0Tighter integ= ration
=C2=A0> with the environments probably means allowing Emacs to be used a= s a
=C2=A0> plugin (in the browser in this case).

I don't really see that. =C2=A0In the great majority of cases the= re's about
one file to worry about (a CSS file accessed from a <link rel=3Dstyleshe= et>).

With media queries, of c= ourse. They are very important today.

So careful parsing is still re= quired (even in the case with just one CSS file).=C2=A0

But on the other hand that careful parsing could be = made into an advantage. I just know a few environments for hunting CSS-rule= s. In those I have seen no simple way to see how the different media querie= s apply to the element I am looking at. Quite inconvenient actually. (I ass= ume it is coming soon, though.)
--047d7bdc1bd0caf54204f4f859bc--